Loading complete guide…
System design • Case study 01
Designing a Railway Reservation Platform
A student-friendly walkthrough of the architecture, data model, seat-inventory logic, booking lifecycle, payment recovery, traffic spikes, and reliability patterns behind an IRCTC-style system.
ArchitectureDatabase designDistributed systemsInterview preparation
Important context: This is an educational reference design, not a claim about IRCTC's private production internals. The source guide explicitly notes that the real PRS internals are not fully public.
01 / At a glance
The system, visually
A request comes from a customer, passes through a gateway and purpose-built services, then reaches the right data or external provider. Reads are optimized for speed; booking writes are carefully controlled to avoid selling the same berth twice.
🔎
Read path
Search and availability
🎟️
Write path
Hold, confirm, assign berth
🔐
Consistency
Prevent double booking
⚡
Burst traffic
Queue and rate-limit spikes
High-level architecture
Conceptual components and their responsibilities
Client layer
Web / Mobile AppLogin · Search · Booking UI
↓ HTTPS
API GatewayAuth · Rate limits · Routing
Application services
Search ServiceTrain routes and schedules
Availability ServiceRead inventory by journey
Booking ServiceValidate request and create booking
Inventory ServiceAtomic hold / confirm / release
Data & integration
Cache / Read ReplicasFast, scalable read traffic
Transactional DatabaseBooking + segment inventory
Payment GatewayUPI · Cards · Net banking
Queue / Event BusAsync work and recovery
Background workers
NotificationsSMS / email / updates
Waitlist WorkerPromotion and chart events
Refund & ReconciliationRetry and settlement checks
AnalyticsReporting without slowing booking
Entry / read
Application logic
Critical booking write
Durable / external systems
Async processing
01Separate reads from writes
Search can use caches and replicas. Booking must verify and change authoritative inventory.
02Protect scarce inventory
A berth must be reserved atomically for every segment in the requested journey.
03Recover from partial failure
Payments and notifications can fail independently, so use durable states, retries, and reconciliation.
Suggested classroom sequence
First explain the problem and requirements, then the architecture, then seat inventory and booking correctness. Finish with payments, Tatkal traffic, sharding, caching, and reliability trade-offs.