Designing IRCTC: the whole course, in one system

1 Putting it all together

IRCTC (Indian Railway Catering and Tourism Corporation) runs the online booking system for Indian Railways. It is one of the most demanding systems on Earth, and it stresses almost every idea from this subject simultaneously. Before we draw a single box, let's frame why each tool we learned is forced into the design.

The five forces that shape the design

The tension at the heart of it: speed vs. correctness

Recall the CAP theorem (Session 8): under a network partition you can't have both perfect consistency and full availability. IRCTC is unusual because different parts of it want different things:

• Search & availability display can be slightly stale — "approximately 12 seats left" is fine. This part leans toward availability (AP).
• The actual seat allocation & payment must be exactly right — you cannot "approximately" sell a seat. This part demands strong consistency (CP).

Recognising that one system can mix consistency models per-component is the single most important insight of this whole case study. Keep it in your back pocket.

2 End-to-end architecture

Let's build the full picture. We'll go left-to-right, from the user's phone to the database and back, and at each box explain why it's there, referencing the session that taught the idea.

The request's journey, top to bottom

Component by component

1. Clients & the edge (CDN + DNS)

Users arrive from the mobile app, the website, or third-party travel agents (which hit the API directly). Static, rarely-changing content — JavaScript bundles, CSS, station logos, schedule PDFs — is served by a CDN (Content Delivery Network): edge servers physically close to users (Session 6). GeoDNS points each user at the nearest healthy region. This keeps slow, repetitive downloads off the core servers entirely.

2. Load balancer + API gateway

All dynamic traffic hits a load balancer (Session 3–4) that spreads requests across many identical application servers so no single machine is overwhelmed. In front of (or merged with) it sits an API gateway that handles cross-cutting concerns: TLS termination, authentication, rate limiting (crucial for Tatkal — Session 5), and routing each request to the right microservice.

3. Stateless microservices

Instead of one giant program, the logic is split into focused microservices, each independently deployable and scalable:

The golden rule: keep services stateless (no user data stored in the server's local memory). Any server can handle any request, so the load balancer can freely add/remove machines. State lives in the cache and database, not the app server.

4. Cache layer (Redis cluster)

A distributed in-memory cache such as Redis sits between services and the database (Sessions 6–7). It stores hot, repeated data so reads don't pound the DB:

• Train schedules & route info (changes rarely → long TTL).
• Search results / fare lookups (short TTL, e.g. a few seconds).
• Approximate seat-availability counters (very short TTL or event-updated).
• Sessions, rate-limit counters, and Tatkal queue tokens.

5. Database — sharded and replicated

This is the heart. We need a relational database (e.g. PostgreSQL/MySQL) for transactional correctness on bookings and payments — recall ACID transactions from Session 8. One database can't hold the load, so we apply two orthogonal techniques learned in Sessions 9–12:

• Sharding (horizontal partitioning): split data across many DB servers. A natural shard key is train_id (or train_id + journey_date) so that all seats for one train on one day live together — letting a single booking transaction stay inside one shard.
• Replication: each shard has a primary (handles writes) and one or more replicas (handle reads + take over on failure). This gives durability, read-scaling, and failover.

6. Queues & the notification pipeline

Slow or non-critical work is pushed onto a message queue (e.g. Kafka/RabbitMQ — Session 14/15) and processed asynchronously. After a booking commits, we drop a "ticket booked" event on the queue; downstream consumers send the SMS, email the e-ticket, update analytics, and notify waitlist logic — none of which the user has to wait for.

The full component diagram

                 ┌─────────────┐
   📱 Clients ──▶ │  CDN + DNS  │  (static assets, GeoDNS)
 (app/web/agent) └──────┬──────┘
                        │ dynamic requests
                        ▼
              ┌────────────────────┐
              │  Load Balancer +   │  TLS, auth, rate-limit
              │   API Gateway      │  (Sessions 3–5)
              └─────────┬──────────┘
        ┌───────────────┼───────────────┬───────────────┐
        ▼               ▼               ▼               ▼
   ┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
   │ Search  │    │ Booking  │    │ Payment  │    │  Auth /  │   ◀ stateless
   │ Service │    │ Service  │    │ Service  │    │  User    │     microservices
   └────┬────┘    └────┬─────┘    └────┬─────┘    └────┬─────┘
        │   reads      │ read+write    │                │
        ▼              ▼               │                ▼
   ┌──────────────────────────┐       │          ┌──────────┐
   │     Redis cache cluster   │◀──────┘          │ sessions │
   │  (schedules, availability)│                  └──────────┘
   └────────────┬──────────────┘
                │ on miss / for writes
                ▼
   ┌─────────────────────────────────────────────┐
   │           Sharded SQL database                │
   │  shard key = train_id (+ journey_date)        │
   │                                               │
   │  Shard A         Shard B         Shard C      │
   │  ┌────────┐      ┌────────┐      ┌────────┐   │
   │  │primary │      │primary │      │primary │   │ ◀ writes
   │  └───┬────┘      └───┬────┘      └───┬────┘   │
   │   replicas        replicas        replicas    │ ◀ reads + failover
   └───────────────────────┬───────────────────────┘
                            │ "booking confirmed" event
                            ▼
                  ┌───────────────────┐
                  │  Message queue    │  (Kafka / RabbitMQ)
                  └─────────┬─────────┘
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
          📨 SMS        ✉️ Email     📊 Analytics
        (async notification consumers)

# Simplified booking flow (pseudocode)
def book_seat(train_id, date, seat, user):
    shard = route_to_shard(train_id)        # sharding: all seats for this train live here
    with shard.transaction():            # strong consistency on the write path
        row = SELECT status FROM seats
              WHERE train_id=train_id AND date=date AND seat=seat
              FOR UPDATE               # row lock: nobody else can grab S7 now
        if row.status != "AVAILABLE":
            raise SeatTaken                # the loser is told politely
        UPDATE seats SET status="HELD", held_by=user
        pnr = create_pnr(...)
    enqueue("start_payment", pnr)         # payment kicked off; queue + idempotency
    return pnr

3 The hard parts revisited

A clean diagram doesn't make a system work — the details do. Here are the four genuinely hard problems in IRCTC, the design decision for each, and the trade-off you accept.

Hard part A — Double-booking (concurrency control)

The nightmare: two users buy the same berth. This is a classic race condition (Session 13). The fix is concurrency control — making sure that for any one seat, bookings are effectively serialised. Two families of approaches:

-- PESSIMISTIC: take the lock up front (good under Tatkal contention)
BEGIN;
SELECT status FROM seats
  WHERE train_id=12951 AND date='2025-12-25' AND seat='S7'
  FOR UPDATE;                 -- row locked; the other txn blocks here
UPDATE seats SET status='HELD' WHERE ...;
COMMIT;

-- OPTIMISTIC: no lock; detect the clash at write time
UPDATE seats SET status='HELD', version=version+1
  WHERE seat='S7' AND status='AVAILABLE' AND version=42;
-- if 0 rows updated → someone beat us → retry or report "seat gone"

Hard part B — Tatkal traffic spikes

At the Tatkal window, traffic jumps maybe 10–50× in seconds. You cannot keep that many servers running 24/7. The toolkit:

• Autoscaling + pre-warming: scale out app servers before the known window (you know exactly when it opens — pre-provision capacity).
• Rate limiting & throttling (Session 5) at the gateway: cap requests per user/IP to stop bots and protect the core.
• A virtual waiting room / queue: admit users in controlled batches instead of letting all of them hit the booking DB at once — turning a stampede into an orderly line.
• Load shedding: if overwhelmed, reject excess requests fast with a clear message rather than letting everything slow to a crawl (a slow system that serves no one is worse than a fast "try again").
• Cache & CAPTCHA the read-heavy parts so only genuine booking writes reach the DB.

Hard part C — Payment consistency

The scary scenario: money leaves the user's account but no ticket is issued — or a ticket is issued but the payment failed. The booking and the payment live in different systems (your DB vs. an external payment gateway), so a single ACID transaction can't span both. The tools:

• Idempotency keys: every payment attempt carries a unique key so retries don't charge twice. Critical, because mobile networks drop and clients retry constantly.
• The Saga pattern (Session 14): model the booking as a sequence of steps, each with a compensating action. If payment fails after the seat was HELD, the compensation releases the seat. If the ticket can't be issued after payment succeeded, the compensation triggers a refund.
• An outbox + reconciliation: record intended actions durably and have a background job reconcile against the gateway, so nothing is silently lost.

Hard part D — Search / availability caching

Search is read-heavy and must be fast, so we cache aggressively. But availability changes as seats sell — so the cache goes stale. The design decision is to accept staleness on the display, but never on the commit:

• Show a cached, slightly-stale count ("~12 available", short TTL). Cheap and fast.
• Re-check the true availability inside the strongly-consistent transaction at booking time (Section 2's FOR UPDATE). The cache can lie; the transaction cannot.
• Use cache invalidation / event-driven updates: when a seat is booked, publish an event so caches refresh sooner.

4 Scaling, reliability & interview tips

Capacity estimation (back-of-the-envelope)

Interviewers love this. You won't be exact — they want to see structured reasoning. A worked pass for IRCTC:

Bottleneck analysis

Always ask "what breaks first?" For IRCTC the answer is almost always the write path to the booking database during Tatkal — because writes need consistency and can't just be cached. Mitigations, in order of leverage:

Failure handling & reliability

• No single point of failure (SPOF): redundant load balancers, multiple app instances, replica DBs that can be promoted on primary failure (automatic failover, Session 12).
• Replication for durability: a committed booking exists on a primary and replicas, so one disk dying never loses a ticket.
• Circuit breakers & timeouts: if the payment gateway is down, fail fast and stop hammering it — don't let one slow dependency take down everything.
• Graceful degradation: if search is struggling, serve cached/stale results rather than erroring. Read features can survive even if some write features are paused.
• Idempotency everywhere on the write path so retries are safe.
• Monitoring & alerting: watch latency, error rate, queue depth, lock waits — you can't fix what you can't see.

How to present this in a system-design interview

The biggest mistake is diving into a database schema in minute one. Use this order — it's the same order this page followed, which is no accident:

★ Putting it all together & course finale

You just designed one of the hardest real-world systems there is — and in doing so you used every major idea from this subject. Here's the one-paragraph story that ties this capstone together:

Quick self-check

📚 References & Further Reading

Class material

• 📄 Original course notes / handout (source sheet) — open the shared class material for this session.
• Class handout: "[SST-2028] HLD Capstone".

Papers, docs & deep dives

• 📄 The System Design Primer — an end-to-end reference for the full architecture, with worked case studies.
• 📄 Martin Kleppmann — Designing Data-Intensive Applications (DDIA) — the definitive book on replication, partitioning, consistency, and transactions.
• 📄 AWS Well-Architected Framework — reliability, performance, and operational-excellence pillars for production systems.
• 📄 Microservices.io — The Saga Pattern — the canonical reference for the booking/payment consistency story.