An interactive study companion for Martin Kleppmann's classic on reliable, scalable, and maintainable systems.
Hotels, flights, restaurants, and concerts sell finite inventory that must never be oversold.
Reservation systems are classic OLTP with brutal correctness requirements. A double-booked hotel room destroys trust faster than a slow search page.
Guests search Elasticsearch-backed listings but commit bookings through a transactional core that decrements night-level inventory in PostgreSQL with row-level locks or serializable isolation.
Guests search by date range, location, price, amenities — fuzzy, faceted queries that SQL can do but not at Airbnb-scale relevance ranking. Index is rebuilt from listing events; stale by seconds is OK.
A night sold twice destroys trust — needs ACID, row locks, unique constraints, and serializable transactions on inventory rows. DynamoDB can work with careful conditional writes but SQL is the default for booking invariants.
Routes read-heavy search traffic separately from write-heavy booking commits. Can throttle abusive search without starving checkout.
PCI-DSS compliance, card vaulting, and dispute handling outsourced — building this in-house is a non-starter for most products.
After booking commits, emails, search index updates, analytics, and host notifications run async. Outbox pattern ensures events publish only after DB commit.
Fast expiry of abandoned cart holds with key TTL + background sweeper. Source of truth remains Postgres; Redis accelerates 'is this hold still valid?' checks.
Hold → pay → confirm spans services — no single XA transaction across Stripe and your DB. Compensating release on payment failure is mandatory.