Understanding the Architecture of Airbnb
Welcome to New Learnings Today...!
Architecture of Airbnb
My Understanding of Airbnb System Design
Today I explored the system design of Airbnb to understand what happens behind the simple experience of searching for a property, checking its availability, booking it, and making a payment.
At first, I thought it was mainly:
Search → Select → Book → Pay
But when I started looking at it from a system-design perspective, I realized that there are many problems to solve behind the scenes — especially high traffic, search, availability, concurrency, double booking, payments, databases, security and 24/7 availability.
1. Two Main Types of Users
The first thing I understood is that there are mainly two categories of users:
Guest
A guest can:
- Search for properties
- Apply filters
- Check availability
- Book a property
- Make payments
- Give reviews
Host / Owner
A host can:
- Add a property
- Upload property images
- Set prices
- Manage availability
- Manage bookings
So the system has to support two different types of users with different responsibilities.
2. Overall Architecture
At a high level, I understand the architecture like this:
USERSGuest / Host|↓Load Balancer|↓API Gateway|┌───────────────┼────────────────┐↓ ↓ ↓Search Availability UserService Service Service| | |↓ ↓ ↓Search Index Booking DB User DB| |↓ ↓Cache Booking Service|┌───────────┼───────────┐↓ ↓ ↓Payment Notification ReviewService Service Service|↓Payment GatewayMedia / Image Service|↓Object Storage|↓CDN
The important thing I learned is that a large system doesn't need to put everything into one application or one database.
Different services can handle different responsibilities.
3. 📈 What Happens When Thousands of Users Search?
This was one of the questions that helped me understand scalability.
Imagine it is a holiday weekend and thousands of people are searching for properties at the same time.
We shouldn't send all requests to one server.
Instead:
Thousands of Users|↓Load Balancer/ | \↓ ↓ ↓Server Server Server1 2 3
The Load Balancer distributes requests among multiple servers.
If traffic increases further, we can add more servers.
This is called horizontal scaling.
So instead of:
"Make one server extremely powerful"
we can think:
"Add more servers and distribute the workload."
4. 🔍 Search Should Be Fast and Flexible
Search is one of the most important parts of Airbnb.
A guest might search:
"2 bedroom apartment in Hyderabad"
The system may need to consider:
- Location
- Dates
- Number of guests
- Price
- Property type
- Amenities
- Rating
But users don't always type perfectly.
For example:
Mountain
could accidentally become:
Montain
The search system should still try to understand what the user means.
This is where concepts such as:
- Fuzzy search
- Typo tolerance
- Search indexing
- Filtering
- Location-based search
become useful.
A technology such as Elasticsearch/OpenSearch can be used as a dedicated search engine/index for this type of workload.
5. ⚡ Caching
Suppose thousands of users are searching for popular locations.
If every request directly goes to the database, it can create unnecessary load.
A cache can help:
User↓Search Service↓Cache↓Cache Hit → Return result quickly
If the data isn't available in the cache:
Cache Miss↓Search Index / Database
A technology such as Redis can be used as a caching layer.
However, I also learned that we have to be careful when caching availability information because stale data should never cause an incorrect booking.
6. 📅 Availability Is Different From Search
Finding a property doesn't mean that the property can actually be booked.
Suppose:
Aug 20 → AvailableAug 21 → AvailableAug 22 → BookedAug 23 → Available
A guest wants:
Aug 20 → Aug 23
The property should not be confirmed because Aug 22 is already booked.
So I understood an important difference:
Search Service:
"Which properties might match the user's request?"
Availability Service:
"Can this particular property actually be booked for these dates?"
7. 🔒 The Double-Booking Problem
This is one of the most important problems I learned.
Suppose there is only one apartment available.
Two guests try to book it almost simultaneously:
Guest A ──────→ Property P1↑Guest B ──────→ Property P1
Both requests could check availability before either booking is completed.
Without proper concurrency control:
Guest A → ConfirmedGuest B → Confirmed❌ Same property booked twice
This is a concurrency and consistency problem.
8. 🔐 Pessimistic Locking
One solution I learned about is pessimistic locking.
The simplified idea is:
Check Availability↓Acquire Lock↓Reserve Dates↓Complete Booking↓Release Lock
But we shouldn't unnecessarily block unrelated bookings.
For example:
Guest A → Aug 20–25Guest B → Aug 26–30
These bookings don't overlap, so they shouldn't unnecessarily block each other.
But:
Guest A → Aug 20–25Guest B → Aug 22–24
These overlap, so concurrency control is required.
This helped me understand why locking granularity matters.
9. 🗄️ Which Databases Should We Use?
Another important thing I learned is that we don't necessarily need one database for everything.
Different data has different requirements.
This is often called polyglot persistence.
Relational Database
For important transactional information, a relational database such as PostgreSQL or MySQL is a natural choice.
For example:
UsersHostsPropertiesBookingsReservationsPaymentsReviews
Why?
Because these areas involve:
- Structured data
- Relationships
- Transactions
- Consistency
Especially for bookings and payments, correctness is extremely important.
Search Index
For searching properties:
Elasticsearch / OpenSearch
can be used.
It is useful for:
- Fast search
- Filters
- Location
- Fuzzy matching
- Ranking
- Typo tolerance
The search index should not be treated as the final source of truth for whether a booking is allowed.
Redis Cache
Redis can be used for:
- Frequently accessed data
- Temporary data
- Caching search results
- Session-related information
- Other low-latency use cases
But availability data needs special care because stale information can be dangerous during booking.
Object Storage
Property images and videos can be stored in object storage rather than directly inside the relational database.
For example:
Property DB|| image reference↓Object Storage|↓Images / Videos|↓CDN|↓User
Examples include cloud object-storage services such as Amazon S3.
The database stores the metadata/reference, while object storage contains the actual large files.
10. 💳 Payment and Duplicate Payments
Another important problem is:
What if the guest clicks Pay twice?
For example:
Request 1 → ₹3000Request 2 → ₹3000
We don't want:
₹6000 ❌
for one booking.
This is where idempotency becomes important.
The system should be able to recognize that the same payment request has already been processed.
This is especially important in payment systems because a small software issue can become a real financial problem.
11. 🔔 Booking Confirmation and Notifications
After a successful booking:
Booking↓Payment successful↓Booking Confirmed↓Notification
The user can receive:
- Push notification
- SMS
These notifications can be processed asynchronously:
Booking Service↓Message Queue↓Notification Service↓Email / SMS / Push
This connects with what I previously learned about asynchronous messaging while studying WhatsApp.
12. 🖼️ Images and Media
Airbnb properties can contain many high-quality images.
Loading every image immediately isn't efficient.
So I understood two related concepts:
Object Storage
Store the actual large media files separately.
Lazy Loading
Don't load everything immediately.
Open Property↓Load important content↓User scrolls↓Load more images
This reduces unnecessary bandwidth and can improve the user experience.
A CDN can also help deliver frequently accessed images faster.
13. 🔐 Authentication and Security
Airbnb handles:
- User accounts
- Personal information
- Bookings
- Payments
So secure authentication and authorization are essential.
The system needs to ensure:
The right user can access the right resources.
For example, a guest shouldn't be able to modify another host's property.
Security also needs to be considered for:
- Passwords
- Tokens/sessions
- APIs
- Payment communication
- Personal information
14. 🌐 24/7 Availability
A service like Airbnb should ideally be available around the clock.
If one server fails:
Server 1 → ❌Server 2 → ✅Server 3 → ✅
the load balancer can continue sending traffic to healthy servers.
This leads to concepts such as:
- Redundancy
- Fault tolerance
- Health checks
- Load balancing
- Monitoring
- Failure recovery
The goal is to avoid a single point of failure.
15. ⭐ What I Think Are the Most Important Airbnb Concepts
After learning all of this, these are the concepts I want to remember:
AIRBNB|┌────────────────┼────────────────┐↓ ↓ ↓SEARCH AVAILABILITY BOOKING| | |Fuzzy Search Concurrency TransactionsSearch Index Locking ConsistencyCaching Dates Idempotency| | |└────────────────┼────────────────┘↓PAYMENT|↓NOTIFICATION
The most important problems:
Search
→ How can thousands of users search quickly?
Availability
→ Is the property actually available?
Concurrency
→ What if two users book simultaneously?
Locking
→ How do we prevent conflicting bookings?
Payment
→ How do we prevent duplicate charges?
Scalability
→ How do we handle holiday traffic?
Storage
→ Where do we store millions of images?
Security
→ How do we protect users and payments?
Availability
→ How do we keep the service running 24/7?
🧠 My Key Takeaway
Once I started asking these questions, the purpose of concepts like load balancing, caching, search indexes, databases, locking, transactions, idempotency, object storage, CDNs and fault tolerance became much clearer to me.
Airbnb:
Search → Availability → Reserve → Pay → Confirm
Main challenges: search, scalability, concurrency, consistency, double booking and payments.
I'm still at the beginning of my System Design learning journey, but I'm starting to enjoy looking at applications I use every day and asking:
"What is actually happening behind the screen?"
@Ramisetty Pavani
Comments
Post a Comment