Guides · Global
Redis & Kafka in Booking System Design: Inventory Holds Without Double Booking
Use Redis for atomic seat counts and TTL holds, Kafka for async side effects — a practical pattern for IRCTC-style and flash-sale interviews.
When interviewers ask you to design IRCTC, bookmyshow flash sales, or any fixed-inventory checkout, two tools show up again and again: Redis for hot state and Kafka (or another log) for everything that can wait a few hundred milliseconds.
This companion guide focuses on why those choices fit booking systems — and the mistakes that make Redis locks or “just use Kafka” answers fall apart.
02What Redis Owns in a Booking Design
- Available seat / SKU counters per inventory key
- Short-lived HOLD keys with TTL during payment
- Rate-limit counters and simple session / device signals
- Cache of search results and schedule metadata (with invalidation)
03Atomic Decrement Beats Naive Locks
A common weak answer is: GET available → if > 0 → SET available-1. Under concurrency, two requests both read 1 and both “succeed.”
Prefer a single atomic operation — DECR with a floor, or a small Lua script that checks and decrements in one Redis execution. Redis is single-threaded per shard, so that script becomes your serialization point for that key.
- Key design: train:date:class:quota → integer available
- On success: set hold:{bookingId} with TTL and seat metadata
- On payment success: delete hold, write durable booking to DB
- On TTL expiry: restore counter (via expiry listener or reaper job)
04What Kafka Owns
Booking confirmation to the user should not wait for every notification consumer. Publish an event once the durable booking exists; let workers catch up.
- Payment confirmation fan-out (email, SMS, app push)
- Waitlist / RAC promotion jobs after cancellations
- Cache invalidation and search-index updates
- Fraud scoring, analytics, and audit trails
- Retryable side effects when a downstream is slow
05End-to-End Hot Path (Interview Narrative)
- User passes admission control / rate limit
- Booking API calls inventory: Redis Lua → HOLD or REJECT
- Create pending payment order (idempotent)
- Gateway callback → finalize DB booking → emit Kafka event
- Consumers send PNR message, update caches, run fraud checks
06Failure Modes Interviewers Probe
- Redis unavailable: fail closed on allocate (no silent oversell)
- Payment success but finalize crash: replay webhook with idempotency key
- Hold TTL shorter than payment UX: users lose seats unfairly — tune carefully
- Kafka consumer lag: user still has PNR; notifications delayed is acceptable
- Hot key: one popular train sells out in under a second — shard by train/date so other trains stay healthy
07Cheat Sheet Phrases That Sound Senior
- “Serialize per inventory pool, parallelize across pools.”
- “Hold with TTL, then durable confirm — never sell twice.”
- “Enqueue side effects; keep the booking critical path short.”
- “Idempotency on payment and booking finalization.”
- “Pre-scale for known spikes; admission-control the rest.”
08Final Thoughts
Redis and Kafka are not the design — they are tools that match two different jobs: decide seat ownership in microseconds, and finish everything else without blocking that decision. Nail that story and Tatkal-style questions become structured instead of scary.
Key takeaways
- Redis: atomic inventory + TTL holds on the hot path.
- Avoid GET/SET races; use atomic decrement or Lua.
- Kafka: async notifications, promotions, invalidation, retries.
- Fail closed on allocation; make payment finalization idempotent.
Frequently asked questions
Can Kafka replace Redis for seat counts?+
Not for the allocation decision itself. Logs are great for events, not for microsecond compare-and-decrement of a contested integer under Tatkal load.
Do I need Redis Cluster in the interview?+
Mention sharding hot keys by train/date so one popular train does not melt a single node. Details of Cluster vs manually sharded keys matter less than showing you thought about hot keys.
What about exactly-once payments?+
Aim for at-least-once webhooks + idempotent finalization. Exactly-once across gateway, Redis, and DB is rarely free — interviewers reward honesty about that.
Is this how IRCTC really works?+
Public details cover capacity and product rules more than locking internals. Use Redis/Kafka as a reasoned interview design, and say so explicitly.
Done reading?
Browse more field notes on careers, marketing, gold, and everyday skills — or copy this guide to share later.