IRCTC’s redesign: what may have changed behind the scenes to handle 10x scale

IRCTC’s recent redesign caught my attention, but not because of the new UI.

As someone learning system design, I was more curious about what may have changed behind the scenes.

The public numbers are quite interesting:

Earlier capacity:

• Around 32,000 ticket bookings per minute
• Around 4 lakh enquiries per minute

New target capacity:

• Over 1.5 lakh ticket bookings per minute
• Over 40 lakh enquiries per minute

That means booking throughput is expected to grow by almost 5x, and enquiry throughput by around 10x.

Of course, I do not know IRCTC’s internal architecture. This is my learning-based guess on what they may have improved to reach this kind of scale.

---

IRCTC Redesign - System Design Case Study - infographic - By Vinay C

---

1. Separating read traffic from booking traffic

The biggest jump is in enquiries, not bookings.

That tells me the new system is probably designed with a clear split between read-heavy flows and write-critical flows.

Read-heavy flows include train search, fare lookup, seat availability, PNR status, and route details. These can be scaled using caches, replicas, indexes, and precomputed views.

Booking is different. It needs stronger correctness because the system cannot sell the same seat twice.

A scalable design would avoid sending every enquiry to the core reservation system. The booking path and enquiry path should not compete for the same resources during peak load.

2. Heavy caching for common searches

A huge number of users search the same popular routes, dates, trains, and classes.

For example, many users may check availability for the same train on the same journey date. It makes little sense to compute everything from scratch for every request.

IRCTC may have improved caching across:

• train routes
• station metadata
• fare details
• availability snapshots
• PNR status
• popular source-destination searches

Some data can be cached for hours. Some data, like availability, may only be cached for a few seconds. But even a short-lived cache can reduce massive pressure when lakhs of users are checking the same thing.

The key idea is simple: final booking must be accurate, but search results can often tolerate very small delays in freshness.

3. Precomputed views for fare and availability

At this scale, live computation can become expensive.

Instead of calculating fare, quota, route, class, and availability every time a user searches, the system can maintain precomputed read models.

A search request can then read from a prepared view instead of touching multiple backend systems.

Something like:

User search → Read API → Precomputed availability/fare view → Response

This would be much faster than calculating everything live during peak hours.

This pattern is useful in many systems, not just railway booking. Whenever the same query is repeated by millions of users, precomputation becomes a serious advantage.

4. Protecting the actual seat-allocation system

This is probably the hardest part.

Showing availability is one thing. Actually reserving a seat is another.

During Tatkal, thousands of users may fight for the same train, class, and quota within seconds. The system has to make sure that:

• the same seat is not sold twice
• waitlist and RAC order stays correct
• failed payments release seats properly
• duplicate clicks do not create duplicate bookings
• retries do not corrupt booking state

This likely requires better locking, optimistic concurrency, idempotency keys, and short-lived seat holds.

In system-design terms, this is a scarce-inventory problem. The bottleneck is not only CPU or servers. The bottleneck is correctness under extreme contention.

5. Better booking state machine

Railway booking is not a single-step transaction.

A user selects a train, enters passenger details, attempts payment, receives confirmation, and gets a PNR. Many things can fail in between.

A clean booking state machine is essential.

For example:

INITIATED → SEAT_HELD → PAYMENT_PENDING → PAYMENT_SUCCESS → PNR_CONFIRMED

And failure paths like:

PAYMENT_FAILED → HOLD_RELEASED PAYMENT_TIMEOUT → HOLD_RELEASED PAYMENT_SUCCESS_BUT_CONFIRM_FAILED → RECONCILIATION

This kind of design helps the system recover from messy real-world cases, especially when payment gateways are slow or callbacks arrive late.

6. Moving non-critical work outside the booking path

One big performance improvement could come from reducing what happens synchronously during booking.

The critical path should focus on:

• holding the seat
• completing payment
• confirming the PNR

Other work can happen later:

• SMS
• email
• invoice generation
• analytics
• recommendation updates
• user history updates

A booking system slows down when every small task is part of the main transaction.

A better design publishes events after confirmation and lets other services process them asynchronously.

Booking confirmed → event queue → notification, invoice, analytics, audit

This keeps the main booking flow lean.

7. Traffic shaping during Tatkal

Tatkal is not normal traffic. It is a flash crowd.

A system may handle average traffic well and still collapse during Tatkal because everyone arrives at the same second.

That is where traffic shaping matters.

Possible techniques include:

• rate limiting
• waiting rooms
• queue tokens
• per-user throttling
• bot detection
• device/session checks
• stronger login verification
• limiting duplicate attempts

The goal is not just to block bad traffic. The goal is to protect the booking core so it can process valid requests steadily.

Sometimes the best way to scale is to not allow every request to reach the most expensive service at once.

8. Stronger authentication as a scale-control layer

The recent Tatkal-related authentication changes are interesting from a system-design point of view.

Authentication is usually discussed as a security feature, but in a high-demand booking system, it also helps with capacity.

If bots, duplicate accounts, and scripted retries are reduced, the backend can spend more capacity on real users.

So Aadhaar/OTP-style checks are not only about identity. They can also reduce fake demand, inventory hoarding, and retry storms.

Security and scale are connected more than we usually think.

9. Independent scaling of services

A modern version of this system would likely split major responsibilities:

• authentication
• search
• fare
• availability
• booking orchestration
• seat inventory
• payment
• PNR
• cancellation
• refund
• notification
• analytics

This does not mean “microservices for the sake of microservices.”

The real benefit is independent scaling.

During Tatkal, the availability service may need huge read capacity. The booking service may need strict consistency. The notification service can lag a bit. Analytics can be delayed.

If all of these are tightly coupled, one slow part can affect the entire system.

10. Graceful degradation during peak load

At peak time, not every feature deserves equal priority.

During extreme load, the system should preserve the most important flows:

• login
• search
• availability
• booking
• payment
• PNR confirmation

Less important features can be slowed down or disabled temporarily:

• recommendations
• banners
• non-critical filters
• analytics freshness
• promotional content
• some profile features

This is a very practical lesson in reliability.

A good system does not fail completely. It sheds non-critical work and keeps the core journey alive.

Final thought

The IRCTC redesign is a great system-design case study because it is not just about handling more users.

It is about handling different kinds of load:

• Enquiry scale is a read-scaling problem.
• Booking scale is a consistency problem.
• Tatkal scale is a traffic-shaping problem.
• Payment scale is a state-machine and reconciliation problem.

The numbers make the problem more interesting.

Going from 32,000 bookings/minute to 1.5 lakh+ bookings/minute is not just “add more servers.”

Going from 4 lakh enquiries/minute to 40 lakh+ enquiries/minute is not just “make APIs faster.”

At that scale, the real work is in separating workloads, caching smartly, protecting the critical path, shaping traffic, and designing for failure.

Again, this is only my guess from a learner’s point of view. But that is exactly why this redesign is worth studying.