Design AirBnB

9. Caching and read performance

1. Listing Details (Redis):

• Key: listing:{id}.
• Value: The full listing details as JSON.
• TTL: 1 hour.
• Strategy: Cache-aside, which means the service checks Redis first, and on a miss it reads the database and saves the result in Redis. When a host updates a listing, the Listing Service deletes the key.
• Limit: A read replica can be a moment behind the primary. A read just after the delete could therefore save the old value again. The 1 hour TTL limits how long such a value can last, and the Booking Service never relies on cached prices.

2. Image Caching (CDN):

• Images are large, at about 2 MB for an original. Serving them from API servers would use up our bandwidth and keep the servers busy.
• The photos are stored in S3, and the CDN caches them on servers close to users.
• The browser also keeps a local copy, using Cache-Control: max-age=31536000, which means one year. Because of this long lifetime, a changed photo gets a new file name, so the browser never shows the old one.

3. Search Availability:

• We rely on the speed of Elasticsearch. We do not cache full search results, because the combinations of location, dates and guests vary too much for the same search to repeat often.

10. Storage, indexing and media

Primary Storage (Postgres):

• Stores the authoritative state of bookings and listings.
• Uses read replicas to handle the traffic of guests viewing listings. Booking decisions never read from a replica, because a replica can be slightly behind.

Search Index (Elasticsearch):

• Uses geospatial indexing, an index built for finding "points inside an area" or "points within a radius". The general idea is to divide the map into smaller and smaller regions, so that a query skips most of the world. Geohash and quadtree are two well-known forms of this idea. Current versions of Elasticsearch store geo_point fields in a similar structure called a BKD tree.
• The index is eventually consistent, and it runs 1 to 5 seconds behind the database. This is acceptable, because if a user tries to book a home that was just taken, the transaction in Flow 2 catches it.

Media:

• A host uploads an image in three steps: the API generates a presigned S3 URL, the client uploads directly to S3, and the file is stored without passing through our servers.
• S3 then triggers a Lambda function, a small piece of code that runs only when an event occurs. It creates resized versions (thumbnail, mobile and desktop) and updates the listing's record in the database.

11. Scaling strategies

Database Sharding:

Sharding means splitting one table across several database machines.

• By our own estimates, this is not urgent. As a rule of thumb, a single Postgres machine comfortably holds about 1 TB. With 100 GB of listings and about 36 GB of new bookings a year, we would not reach that size for many years. A rate of 12 writes per second at peak is also far below the limit of one machine.
• We plan for sharding anyway, for two reasons: one machine failure should not stop every booking in the world, and real growth may exceed these rough numbers.
• Shard Key: listing_id.
• All data for Listing 101, both its details and its bookings, lives on the same shard. This keeps the locking transaction on one machine, so it stays fast and simple.
• What it costs: Questions that are not about one listing become harder. "All listings of this host" and "all trips of this guest" would have to ask every shard. We therefore keep two small lookup tables, one keyed by host_id and one keyed by guest_id, which list the matching IDs. The Users table is not sharded by listing, so the database cannot enforce links between users and bookings across machines. The services must check those links themselves.

Search Scaling:

• Elasticsearch is a distributed system, so we can split the index into parts.
• Strategy: Partition the index by geographic region, for example index-us-east and index-europe. Most searches name a location, so most queries touch only one region. A search near a border queries both neighboring regions.

Handling "Hot" Listings:

A hot listing is one that many guests try to book at the same moment.

• If a listing suddenly becomes very popular, many requests could queue for the same SELECT ... FOR UPDATE lock.
• Improvement: The temporary hold in Redis from Flow 2, Step 2 handles this. While one guest is checking out, the others see "Someone is booking this" at once. They never reach the database, which saves its connections for the attempts that can succeed.

12. Reliability, failure handling and backpressure

Idempotency:

An operation is idempotent if repeating it has the same effect as doing it once.

• This is crucial for payments.
• The client generates one idempotency_key for a booking attempt, and it reuses that key for every retry.
• The Booking Service checks whether it has already processed this key. If it has, it returns the stored result. The unique index on the Bookings table also stops two simultaneous retries from creating two rows.
• The same key goes to the payment provider. Together, these two checks prevent a double charge when the network times out.

Backpressure:

Backpressure means slowing down the intake of work when the part that processes it is full.

• Kafka provides this for the search index. If Elasticsearch slows down, the Indexer Service reads events more slowly and the events wait in Kafka. The cost is more lag in search results, and no event is lost.

Circuit Breakers:

A circuit breaker stops calling a service that is failing, and it returns a fallback answer instead.

• If Elasticsearch fails, the Search Service detects the timeouts and stops sending it queries for a short time.
• Fallback: It shows a list of popular homes from Redis. This list cannot filter by the guest's dates, but the booking check in Flow 2 still protects against a double booking. We do not fall back to Postgres, because 6,000 QPS of search traffic could then overload the database that bookings depend on.

Graceful Degradation:

Graceful degradation means continuing with reduced features instead of failing completely.

• If the Payment Service is down, guests can still search and view listings. Only the booking request fails, with a clear error, and the dates are released. This is the benefit of keeping search and booking separate.

13. Security, privacy and abuse

Security:

• HTTPS is used everywhere.
• PCI-DSS: This is the security standard for handling card data. We avoid most of its requirements by never touching raw card numbers. A form from the provider, such as Stripe Elements, collects the card details and gives us a token instead, which is called tokenization.
• Identity: The Booking Service reads the guest's identity from the login token, so one user cannot make a booking for another.

Privacy:

• Location Fuzzing: We store the exact location, but until a booking is confirmed, the API returns only an approximate one, a point within 500 m of the home. This protects the safety of hosts. We choose this point once and store it. If we chose a new random point for each request, someone could average many responses and find the real address.

Abuse:

• Rate Limiting: We limit calls to /v1/listings/search to prevent scraping, the automatic copying of our data. We use a token bucket stored in Redis: each client has a bucket of tokens that refills at a fixed rate, each request uses one token, and a request with no token left is rejected.
• Fraud: Background workers analyze booking patterns, such as one guest booking 5 houses for the same night, and flag them for manual review.

14. Bottlenecks and next steps

Bottleneck: Index Synchronization Lag

• Issue: A user books a home, and the database is updated. For up to about 5 seconds, search still shows the home as available.
• Mitigation: This lag can be made smaller, but it cannot be removed while the index is a separate system. We rely on the database check at the end of Flow 2 to catch it, and we monitor the lag so that we notice if it grows.

Bottleneck: Global Search

• Issue: Searching "anywhere in the world" without a location is expensive, because the query must visit every regional part of the index.
• Mitigation: This design asks users to select a region, such as "Europe", or it shows curated lists that are prepared in advance and stored in Redis.

The complete picture

Every diagram above shows one part of the system. This one shows all of them together: the search path, the booking path, the index synchronization and the media path, with the caches, queues, data stores and scaling strategy of each one marked. Notice that search reaches the Postgres primary only indirectly, through read replicas and the index synchronization, and that only the booking path makes booking decisions there.

Summary

Say this first. Airbnb is a read-heavy marketplace where search and booking want opposite things. Search wants speed and can accept data that is a few seconds old, so it runs on Elasticsearch. Booking must never sell the same night twice, so it runs as short, locked transactions on Postgres, with no lock held during payment. Almost every other decision in this design follows from that one split.

The decisions that mattered

The numbers that forced them

What breaks first

1. Index lag. A home that was just booked stays visible in search for a few seconds. The database check catches it at checkout, so a guest can get as far as pressing Book and then be rejected. That is the accepted trade-off, not a bug.
2. A hot listing. Many guests try to book the same home at once. The Redis temporary hold turns most of those attempts into an instant "someone is booking this" instead of a queue on the database.
3. Elasticsearch itself. The circuit breaker falls back to a list of popular homes from Redis. Reduced discovery is better than an error page.

If the interviewer pushes

• "What if two guests book the same night at the same instant?" One of them gets the row lock first and commits a PENDING row. The other waits, then its overlap check finds that row, so its transaction rolls back. That guest receives a 409 and goes back to search.
• "Why not hold the lock in Redis instead?" Redis replicates its data asynchronously, so a failover can lose a key. That is acceptable for a first filter and not acceptable for the final decision. If a hold is lost, the PENDING row in Postgres still protects the dates. A system selling concert tickets might do more of this work in Redis, because there the contention is the main problem.
• "How do you avoid double charging on a retry?" The client generates an idempotency key before the first attempt. The Booking Service returns the stored result for a repeated key, and the payment provider receives the same key, so it does not charge again.
• "What if the service crashes after the payment but before it confirms?" The PENDING row is already durable, and it expires after 5 minutes. A background job finds it, asks the provider about the charge, and refunds it.
• "Where does this design fail?" Searching the whole world with no location. There is no cheap way to rank every listing on earth, which is why this design asks for a region first.