Guides · Global
IRCTC System Design Interview: Architecture, Tatkal Spike & Seat Allocation
Design IRCTC for SDE interviews — requirements, scale estimates, read vs write split, atomic seat holds, payments, bots, and Tatkal spike handling.
“Design IRCTC” is one of the most common system design prompts in Indian SDE interviews — and for good reason. It packs fixed inventory, a fixed-time traffic spike (Tatkal), payments, waitlists, and bot pressure into one familiar product.
This guide is an interview-ready walkthrough: clarify requirements, estimate scale, split read vs write paths, and reason about seat allocation without claiming to reverse-engineer IRCTC’s private internals.
02Problem Statement
Design a highly scalable system where users can search trains, check availability, book tickets, and pay — especially under peak load like Tatkal opening.
- Huge traffic in a short window
- Limited seats per train / class / quota / date
- Prevent fraud and bots
- Ensure fairness across users
- Stay highly available during the rush
03Scale Estimates (Interview Numbers)
Show your math early. Exact public figures change over years — what matters is order of magnitude and that search traffic dwarfs bookings.
- Normal days: millions of users; festival / peak days far higher
- Tatkal open (~10:00 AM AC / ~11:00 AM non-AC): massive concurrent hit on scarce pools
- Read-heavy: search + availability enquiries >> write-heavy bookings
- Availability target often discussed as ~99.9%+ during booking windows
- Databases typically discussed as sharded + read replicas in interview designs
04Functional Requirements
- User registration and login
- Search trains and check availability by class / quota
- Select train, class, quota, and passengers
- Book ticket with atomic seat allocation
- Make payment and get confirmation (PNR)
- Cancel ticket and handle refunds / waitlist promotion
- PNR status and chart-related state changes (RAC / WL)
05Non-Functional Requirements
- High availability during Tatkal open
- Scalability to millions of concurrent users
- Low latency on search and booking APIs
- Strong consistency on seat assignment — no double booking
- Security and fair-usage controls against bots / agents
- Fault tolerance: payment timeouts, partial failures, retries
06High-Level Architecture
Sketch two paths first: a cacheable read path for search/availability, and a carefully serialized write path for inventory allocation.
- CDN + API gateway + rate limiting / admission control in front
- Stateless search / booking API services behind a load balancer
- Inventory service as the single serialization point per seat pool
- Redis (or in-memory inventory) for hot seat counts + short holds
- Primary DB (sharded) for durable bookings / PNR / payments metadata
- Kafka (or similar) for async payment confirmations, notifications, waitlist promotion
- Payment gateway integration with idempotent callbacks
07Seat Allocation & Inventory
The real inventory unit is usually: train + date + class + quota. Selling the last seat in a pool must be atomic.
- Keep authoritative available count in memory (Redis) for the hot path
- Use an atomic compare-and-decrement (e.g. Redis Lua) — not GET then SET
- On success, create a temporary HOLD with TTL for the payment window
- On payment success: finalize booking + issue PNR
- On timeout / failure: release hold, restore count, optionally promote waitlist
- Assign specific berths lazily after count success if needed
08Payment Flow
- Booking service creates a hold + pending payment order (idempotent keys)
- User pays via gateway; webhook / redirect confirms status
- Only paid + allocated seats become confirmed PNRs
- Retries must be safe: same payment intent never double-charges or double-books
- Failed payments release inventory within TTL
09Scaling for Tatkal
- Pre-scale capacity before 10:00 — reactive autoscaling is too late for a vertical spike
- Admission control / virtual waiting room to flatten the burst
- Cache train schedules and availability aggressively; invalidate on booking events
- Shard inventory keys so different trains/dates do not contend on one lock
- Decouple notifications and charting work via queues
10Security, Bots & Fair Usage
- Auth, CAPTCHA / device signals, and rate limits per user / IP / device
- OTP or step-up checks on sensitive booking windows (as IRCTC has publicly moved toward)
- Agent / API restrictions during the first minutes of Tatkal where applicable
- Detect suspicious booking velocity and recycle bad actors
11Failure Handling
- Payment gateway down: expire holds, show clear retry UX, never orphan seats forever
- Redis blip: fail closed on booking (prefer unavailable over oversell)
- Duplicate webhooks: idempotency keys on payment and booking finalization
- Partial multi-passenger booking: all-or-nothing transaction boundaries
- Monitoring: booking success rate, hold expiry rate, p99 latency, queue lag
12How to Present This in an Interview
- Minute 0–5: requirements + NFRs + scale estimates
- Minute 5–15: high-level boxes and read/write split
- Deep dive: inventory atomicity, holds, payments, Tatkal spike plan
- Close with bots, waitlist/RAC, and failure modes
- Always say what you would measure and what you would simplify for MVP
13Final Thoughts
A strong IRCTC answer is not a laundry list of buzzwords. It is a clear story: scarce seats, atomic allocation, payment holds, pre-provisioned spikes, and fairness under bots — told with tradeoffs an interviewer can follow.
Key takeaways
- Split search (read-heavy) from booking (correctness-critical).
- Serialize seat pools atomically; use holds with TTL around payment.
- Pre-scale and rate-limit for Tatkal — do not rely on reactive scaling alone.
- Design for no double booking first; then add waitlist, bots, and recovery.
Frequently asked questions
Why is IRCTC a favorite interview question in India?+
Everyone understands the product, and Tatkal makes concurrency, fairness, and spike handling concrete. It maps cleanly to flash-sale and fixed-inventory problems asked globally too.
Would you put seat counts only in Postgres?+
For an interview MVP you can start with DB transactions, then explain why hot Tatkal pools usually move to in-memory atomic counters (Redis/Lua) with durable finalization in the DB.
How do you avoid double booking?+
Make allocation atomic per inventory key, finalize only after payment (or a strict two-phase hold), and make payment callbacks idempotent so retries cannot confirm twice.
Where do Kafka and Redis fit?+
Redis for hot inventory and short-lived holds; Kafka (or similar) for async side effects — notifications, analytics, waitlist promotion, cache invalidation — so the booking path stays lean.
Done reading?
Browse more field notes on careers, marketing, gold, and everyday skills — or copy this guide to share later.