Design a Reservation System

Understanding the problem

After video, "design a booking system" is the shape Amazon reaches for most. The prompt shows up in many forms. You might reserve a seat at an event, book an appointment slot, or pull a unit of a SKU off the warehouse shelf for an order. Underneath, the plumbing never changes: a finite pool of inventory, and many people wanting the same piece of it at the same moment. The system must never hand one unit to two customers. We will design event ticketing here, because it pushes the hard part the hardest, but the model carries straight over to appointments and stock.

The problem turns on one thing, contention. A popular concert puts 50,000 seats on sale at a single instant, and a few hundred thousand fans hammer the buy button in the first minute. So you have a small, fixed supply and a sudden flood of buyers all aiming at the same rows. Browsing the catalog is enormous but easy, while the booking write is tiny in volume and hard to get right, because correctness under that flood is the entire exercise. Miss that the danger lives in double-booking and you've solved the wrong problem. Raw scale is the decoy.

The Amazon angle

Amazon picks this prompt because it is a real team's Tuesday, not a textbook abstraction. Inventory and order systems are the daily grind across huge swaths of the company, so your interviewer has probably watched a design like yours break in production. Two things shape how it lands. The no-run code editor in the round before this one drills the same reflex this round wants: reason through the failure case before you trust the happy path. And the rubric puts reliability and resiliency above raw scale. So spend your words on why two people can never buy seat 14C, even when a node dies mid-write, rather than on bookings per second. That is Dive Deep showing up in a design round, and the Leadership Principles get scored inside every round, this one included.

Functional requirements

Propose a tight scope and let the interviewer redirect. The core is short. A user browses available inventory, holds a piece of it while they pay, and confirms the booking. The hold is the heart of the design, so name it now even though it looks like an implementation detail.

Non-functional requirements

Reason through each one and attach a target, because the booking side and the browse side want opposite things. Correctness on the booking write is absolute. We need strong consistency on inventory, so a confirmed seat is gone for everyone the instant it sells. Double-selling one seat is the failure this design exists to prevent, and we will accept rejecting a valid request before we accept selling the same unit twice. Availability has to survive the on-sale spike, when a few hundred thousand requests arrive in a minute against fifty thousand seats. And the booking path must be safe to retry, since a buyer on a flaky phone will tap "confirm" three times and must still be charged once.

The browse side gets to relax. Showing a seat as available that someone grabbed two seconds ago is fine, because the hold step will catch it and the customer simply picks again. So reads can be eventually consistent and served from caches, while writes go through one authoritative path. We design along that seam, where reads are huge and forgiving and the write is tiny and unforgiving.

• ~50K Seats / hot event. The fixed, finite supply.
• ~200K Buyers in minute 1. All aimed at the same rows.
• Strong Consistency on writes. No seat sold twice, ever.
• ~100:1 Browse : book. Why reads ride a cache.

The set-up

Core entities

Pin down what the system actually moves around before sketching a single box. Four stand out:

The important split is between the inventory and everything else. A Seat row and its status are the contended core that must stay correct. So they belong in a store that can do an atomic conditional write: an update that only lands if the row still looks the way you expect. A relational database fits cleanly, and Postgres is the name everyone in the room knows. Partition the seat table by event_id. Then all of one event's seats, and all of its contention, live on one shard, the single slice of the database holding that event's rows. Booking rows are append-only history and can sit in the same database. The seat map a browser renders is read constantly and barely changes during a sale. That is exactly what a cache is for, and it never needs to touch the write path.

Amazon-internally you would reach for DynamoDB with conditional updates here, and we will use that mechanism in the deep dives. Both stores give you the same primitive, a write that fails unless a condition holds, and that one primitive holds the design together.

API

The interface is small, and the shape of it already tells the consistency story. Browsing is a plain read. Holding and confirming are the two writes, split apart on purpose so payment can happen in between without holding a database lock open for thirty seconds.

High-level design

Move through the requirements one by one, standing up the simplest thing that works before any optimizing. Flag each weak spot as it surfaces and save the polish for later. The design falls into two halves along a read/write seam. One side is a forgiving browse path that an edge cache mostly answers. The other is a narrow, strongly consistent write path where holds and bookings happen. The diagram uses color to mark each component's role: blue for people, violet for our services, and green for storage. There is no queue on the booking path, because a hold is a single fast write the database arbitrates directly. The walkthrough tags each component the same way.

1) Browse. The User calls GET /events/{id}/seats and the Seat-map cache answers nearly every time. A seat map for one event is small, a few thousand to fifty thousand rows of "id and status," so it caches in full and serves in a millisecond. We deliberately let this be slightly stale. Say the cache shows a seat as open that someone grabbed a second ago. No harm is done: the hold step is the real check and will reject the stale pick. The flood of browsers never reaches the Inventory DB, which keeps the database's scarce write capacity for the one operation that needs it. The thing we are punting on is how the cache learns about changes fast enough to feel live, which is the read-scaling deep dive.

2) Hold. This is the request that matters, and it runs the moment a user clicks a seat. The client calls POST /events/{id}/holds, and the Booking service attempts a conditional write against the Inventory DB. It flips the seat from available to held and stamps it with this user and an expiry a few minutes out. The catch: it only lands if the seat is still available. If the row already moved, the write fails and the user is told to pick again. One winner per seat falls straight out of letting the database arbitrate. The database serializes writes to a single row, so exactly one of the racing requests sees available and the rest see held. The hold buys the buyer time to pay without anyone locking a database row for the length of a checkout. The weak spot we are punting on is the hold that never resolves, the buyer who closes the tab mid-payment. The expiring-holds deep dive reclaims it.

3) Confirm. With a live hold, the user submits payment and the client calls POST /bookings. The Booking service asks the Payment service to charge the card, and only on success does it flip the seat from held to booked and write the durable Booking row. Splitting hold from confirm is what lets payment, which is slow and external, sit between two fast database writes instead of inside one long transaction. The buyer on a spotty connection will mash "confirm" more than once, so this endpoint has to charge exactly one time no matter how many duplicate requests arrive. Making the booking write idempotent, meaning safe to run twice with the same result, is its own deep dive.

4) Release. A hold ends one of three ways. The user confirms and it becomes a booking, the user cancels and DELETE /holds/{id} frees the seat at once, or the user vanishes and the timer runs out. The first two are easy. Abandonment is the interesting case, because nobody is around to clean up. So the Expiry sweeper is a background job that finds holds whose expiresAt has passed and flips those seats back to available. Without it, every abandoned checkout would silently shrink the supply until a sold-out-looking event still had empty seats. That sweeper, and the cheaper trick that often replaces it, is the expiring-holds deep dive.

Technology choices

So far every box names a kind of thing. In the room you commit to a specific tool for each and back it up, since Amazon interviewers test the concrete pick and lean on failure cases. What happens when a node dies mid-hold, or the sweeper falls behind? Each entry below gives the pick, the reason for that kind of tool, and how the design responds when it breaks.

• The Booking service runs as stateless servers behind a load balancer. No server holds a hold or a booking in its own memory, so any box can serve any request and a dying one just drops out of rotation mid-spike. All the truth lives in the inventory store below, which is what makes correctness the database's job and not the fleet's. The servers stay boring on purpose.
• The Inventory DB is DynamoDB (or Aurora/Postgres if you prefer SQL). It has to support a conditional write, an update that only commits when the row still matches an expected value. That single primitive is how we guarantee one winner per seat. Partition the data by event_id so one event's contention lands on one partition and never spreads. The follow-up writes itself: what if that partition is a single hot event everyone wants at once? A few thousand writes a second to one partition is within a tuned store's reach. The deep dives below cut the contention further so no single row carries the whole storm.
• The Seat-map cache is Redis, an in-memory store that answers reads in well under a millisecond. The seat map for one event is tiny and read by everyone, so caching it in one piece keeps the browse flood off the database entirely. When a hold or booking changes a seat, the booking service invalidates that event's cached map so the next reader refetches. The mechanism that keeps it from going badly stale is the read-scaling deep dive.
• The Expiry sweeper reclaims abandoned holds, and there are two honest ways to build it. The simple one is a scheduled job that periodically scans for expiresAt < now and frees those seats. The cheaper one writes the expiry as a TTL, a time-to-live the store itself watches, so the database expires the hold for you with no job to run. Either way the failure question is "what if the sweeper dies?" The answer is that holds are reclaimed lazily on read too, so a stale hold blocks nobody for long even if the sweep is late.
• The Payment service is an external dependency we treat as a slow, fallible black box. Charging is the one step that talks to the outside world, so it gets wrapped in retries with an idempotency key. A charge that times out is reconciled later rather than blindly retried into a double-charge. The booking write only commits after the charge confirms, which keeps a failed payment from ever producing a booked seat.

The shape underneath is simple. One store carries all the truth and arbitrates every contended write, while a cache absorbs the reads and a background timer cleans up after people who walked away. The brand matters less than the defense. Whether you say DynamoDB or Postgres, what they want is "a store with a conditional write and a per-event partition key." The interviewer is probing whether you know why the category fits, well past which product name you memorized.

Potential deep dives

The bulk of the signal shows up in these deep dives. The interviewer fixes on one or two and bears down, and on a reservation system that is almost always concurrency first. The list below is what Amazon goes to most often, each weighed against the tiers an interviewer scores you on.

1) How do we stop two people from booking the same seat?

This is the core problem, so size the race before solving it. At the on-sale instant, picture a few hundred buyers all clicking the same front-row seat in the same handful of milliseconds. Every one of their requests reads the seat as available at nearly the same time. If the system lets all of them write, every one of them thinks they won, and you have sold one seat many times over. The fix has to make the read-then-write a single indivisible step, so exactly one request can flip the seat and the rest are told no.

The conditional write is enough for one seat at a time. The reason interviewers push further is the group booking, four friends who want four adjacent seats as all-or-nothing, which a single-row conditional update can't express on its own.

The Amazon angle

This is where Amazon's reliability-first rubric bites hardest, and where a Bar Raiser likes to camp out. Get to the conditional write and the transaction, then keep going past where most people stop. What happens if the node holding the lock dies after the write but before the response? The buyer never hears back and retries, so the idempotency story in deep dive three has to catch it. That dead-node walk is Dive Deep showing up inside the design, scored as heavily as the architecture itself. Skip the question and your resilient design is just a nice drawing.

The handling contention lesson covers optimistic concurrency and row locking in full.

2) How do we reclaim holds when buyers walk away?

Holds exist so a buyer can pay without racing a clock, but most checkouts that start never finish. Suppose a hold lasts five minutes and a third of buyers abandon mid-payment. On a 50,000-seat event that is tens of thousands of seats locked up at any moment by people who left. If those holds never expire, the event looks sold out while seats sit empty, which is both lost revenue and a furious customer staring at a full map. So a hold has to carry an expiry, and something has to act on it.

The Amazon angle

Lazy reclaim keeps the system correct even when the background job is dead, and that resilience is exactly what Amazon's rubric rewards over raw scale: a design that degrades gracefully beats one that needs every component healthy to stay correct. There is a quieter Customer Obsession thread too, the Leadership Principle Amazon calls its north star. Too short a hold frustrates a buyer who is genuinely typing in a card; too long hides seats from everyone else. Frame the expiry window as a customer tradeoff, not a magic constant. The number is a promise to the buyer, and the behavioral-scored half of the round picks up on whether you say so.

3) How do we charge exactly once when the client retries?

Confirmation is the dangerous write, because it spends real money and travels over a network that drops responses. A buyer taps "confirm," then their phone loses signal before the response comes back. The app retries, and now two identical POST /bookings requests hit the server. The first may have already charged the card and booked the seat. Without protection the second charges again and the customer is billed twice for one seat, which is the worst possible outcome for a booking system. The write has to be idempotent, meaning running it twice produces the same single result as running it once.

The Amazon angle

Amazon runs on orders and charges, so it probes idempotency on purpose: it is the line between someone who has shipped a payment-adjacent service and someone who has only drawn boxes. Volunteer the idempotency key before anyone asks for it. Then trace the retry race: two identical requests, the conditional insert that lets one win, the stored result the loser returns. That is Dive Deep and Ownership together, owning the failure mode all the way to the customer's bank statement. It also ties straight back to the no-run coding rounds, where Amazon already made you argue correctness instead of running the code.

The async processing lesson covers idempotency keys and exactly-once semantics in more depth.

4) How do we serve the browse flood without touching inventory?

Now the easy-but-large side. For every person who books, a hundred or more are browsing the seat map and refreshing it. At a few hundred thousand concurrent browsers on a hot on-sale, that is a wall of reads that would bury the inventory database if each one hit it. The requirements give us room here: browse reads are allowed to be a little stale, since the hold step is the real arbiter. So we can serve them from copies and never risk correctness.

The Amazon angle

Name exactly which reads may be stale and why that is safe. Browse may be stale because the hold is the source of truth; the hold and the booking may never be stale, full stop. Name that split and keep all the read scaling on the forgiving side of it. Consistency is a per-operation choice, not a system-wide dial, and Amazon expects a senior engineer to protect the write path while turning the read path loose to scale. Put the boundary in the wrong place and you either throttle reads you never needed to or you sell a seat twice.

The scaling reads lesson generalizes replicas, caching tiers, and request coalescing beyond booking.

What is expected at each level

That's a lot of surface area. Here's how much you need to land, by the level you're interviewing for. Remember that at Amazon the design round mostly decides your level rather than the hire, and a weak one is the common reason a strong loop gets down-leveled.

L4 (SDE I)

Mostly breadth, roughly 80/20 breadth to depth. New-grad loops often skip system design entirely. If you get a lighter version, aim for a working end-to-end skeleton: a browse read, a hold, a confirm, and an inventory store. You should know that two people must not book the same seat and gesture at a database check stopping it, even if you don't reach the full conditional-write argument. The bar: a complete flow you can explain, with the interviewer helping you find the race.

L5 (SDE II)

Breadth, then real depth, roughly 60/40. This is the band where the design round most decides your level. You should reach the conditional write for one-winner-per-seat on your own, separate holds from confirms, add expiring holds, and make the booking idempotent without being walked there. Raise the contention problem and the read/write asymmetry before the interviewer does, and defend the inventory store's partition key. The bar: a near-optimal design where you found the concurrency bottleneck yourself and closed it.

L6+ (SDE III / Senior)

Expect breadth that keeps widening with real depth underneath, roughly a 40/60 split. Expect questions on the dead-node-mid-write failure and on group bookings across multiple seats and shards. Expect them on multi-region inventory and how you keep one authoritative copy of a seat's status. And expect them on how the system degrades when the sweeper or a replica fails. You're carrying the conversation and reasoning about how the design behaves once things go wrong, long after the easy path stops being interesting. The bar: you lead, and the interviewer adjusts your course rather than taking the wheel, with each failure mode answered on the design's own terms.