System Design Interview: Design Airbnb Get my system design playbook for FREE on newsletter signup:

• Share this post& I’ll send you some rewards for the referrals.
• Block diagrams created usingEraser.

A hotel booking system like Booking.com or Airbnb is a common system design interview question.

It looks simple, right until it breaks in the worst way.

Two users click “Book” on the last available room in the same second. Your API does aSELECTcheck, so both requests see availability, and you charge two credit cards for one room. Next, you’re dealing with refunds, angry customers, and a system that can’t be trusted.

And that’s not a bug… That’s the default outcome if you don’t design it correctly.

This is why Airbnb and Booking.com aren’t just “tables + endpoints”.

Most developers jump straight into boxes and arrows without understanding the actual problems. They miss concurrency1traps, forget double booking2, and can’t explain tradeoffs.

In this newsletter, we’ll design it the way interviews and real traffic demand: with strong consistency for inventory, fast reads for search, and clear tradeoffs for caching and scaling.

But before we design anything, let’s zoom out, define the real problem, and lay out the approach step by step.

Onward.

Find out why 150K+ engineers read The Code twice a week (Partner)

Tech moves fast, but you’re still playing catch-up?

That’s exactly why 150K+ engineers working at Google, Meta, and Apple readThe Codetwice a week.

Here’s what you get:

• Curated tech news that shapes your career- Filtered from thousands of sources so you know what’s coming 6 months early.
• Practical resources you can use immediately- Real tutorials and tools that solve actual engineering problems.
• Research papers and insights decoded- We break down complex tech so you understand what matters.

All delivered twice a week in just 2 short emails.

Sign up and get access to the Ultimate Claude code guide to ship 5X faster.

Join 150K+ Engineers

(Thanks for partnering on this post and sharing the ultimateclaude code guide.)

I want to reintroduceHayk Simonyanas a guest author.

]( At this scale, a pure monolith or a full microservices setup would be suboptimal. A single monolith simplifies transactions but becomes hard to scale and deploy independently. Full microservices with separate databases introduce distributed transactions and consistency problems that don’t exist at this traffic level. This design uses service-level separation with shared transactional data for tightly coupled domains (reservations + inventory). It maintains deployment flexibility while preserving strong consistency where it matters most. Each service owns its domain and scales independently. Hotel Service might need 10 instances for search traffic, while Reservation Service only needs 3 since booking TPS is low. ****Critical decision****: Reservation and inventory data live in the same database. This lets us use local ACID transactions instead of distributed transactions. We have service-level separation at the application layer, but shared data for tightly coupled entities. This is pragmatic. Distributed transactions add massive complexity for minimal benefit here. The alternative (separate DBs with saga patterns or 2PC) is overkill when you can keep related data together. ****Alternative:**** Split reservations and inventory into separate databases and coordinate with Saga patterns[11](#footnote-11 "11")or Two-Phase Commit[12](#footnote-12 "12")(****2PC****). 2PC provides strong consistency but adds latency, blocking, and failure complexity. A coordinator failure can stall the system. Saga patterns avoid locking but introduce eventual consistency[13](#footnote-13 "13"), compensating actions, and complex failure handling. This is risky for user-facing booking flows where “eventually consistent” means angry users. At ~17 write TPS, the added complexity is not justified… Local ACID transactions are simpler, safer, and faster. * * * ****API Design**** ------------------ RESTful APIs for all operations: #### ****Hotel APIs (Admin)**** *