Design IRCTC tatkal booking

At 10am the tatkal window opens. (Tatkal is the quota of train seats kept for people who need to travel at short notice.) For the next ten minutes a system that spends most of its day fairly idle takes a couple of hundred times its normal traffic. Almost all of it wants the same few hundred seats, on the same few trains.

Watch one booking go all the way through.

This is not the URL shortener's problem wearing a hat. There, every request could be served, and the work was spreading load. Here most requests must fail, because there are far more people than seats. The design question is how to fail them quickly, fairly and without taking the system down on the way.

A few words come up all through this page:

• A hold is a seat taken out of inventory for a few minutes while you pay. Nobody else can buy it, and if you never pay, it goes back.
• The waiting room is a page that gives you a place in line before you are allowed to book, like the token machine at a bank counter.
• Atomic means "all at once or not at all". An atomic update checks and changes a value in one step, so nothing can sneak in between the check and the change.
• Inventory is the count of seats still for sale, one number per train, date and class.

Step 1: Understand the problem#

The interesting requirements here are about fairness and about failure, not about raw speed. Ask what a rejected user is owed, because that answer shapes the front of the system.

What you are building#

"Correctness over availability" is the same choice the CAP theorem describes: when a network fault splits the system, each part can either keep answering or stay correct, not both. Inventory stays correct, and refuses to answer if it has to.

Back of the envelope#

Before the sliders, a small version you can do in your head. One train has 400 seats and 200,000 people want them. That is 500 people per seat. If every one of them gets an answer, 499 out of every 500 answers are "no". (The back of the envelope chapter covers the method.)

The napkin below counts the whole rush across all trains together, so its default is more seats and more people than one train.

Step 2: Propose the high level design#

The API#

Three calls: get in line, hold seats, confirm after paying. Each reply uses an HTTP status code to say what happened: 201 means "created", 409 means "conflict, somebody got there first", and 202 means "accepted, but not finished yet".

{ "trainId": 12951, "date": "2026-09-02", "class": "3A" }

{
  "admissionToken": "eyJ...",
  "trainId": 12951,
  "date": "2026-09-02",
  "class": "3A",
  "seats": 2,
  "idempotencyKey": "h_91c4..."
}

{ "paymentRef": "UPI2609021000..." }

An idempotency key is a random id the app makes once, when the user taps "Book", and sends with every retry of that tap. The server remembers which keys it has already handled, so the second tap gets the first tap's answer instead of a second hold. How an idempotency key works walks through it with a live demo.

The data model#

Two tables. inventory is how many seats are left, one row per train, date and class. holds is who is sitting on some of them right now. The shard key of both is train_id, so every request for one train lands on one database machine on purpose.

The whole system on one whiteboard#

Figure 1 is the picture at the top of the page, drawn flat, with the CDN added at the edge. A CDN is a network of servers close to users that serves static files and can drop obvious bot traffic before it reaches you.

Walking Figure 1:

1. Clients arrive at the waiting room. The CDN in front has already dropped obvious bots. The fair queue hands each person a signed position.
2. Admitted users only reach the API tier. "Stateless" means any API server can answer any request, because none of them keeps anything in memory between requests, so you can add more of them freely. They are also rate limited, which the rate limiter question covers end to end.
3. "How many left?" is answered by the availability cache, on purpose approximate. A cache is a fast copy of data kept in memory so that most reads never reach the database.
4. "Hold a seat" goes to the booking service, which has exactly one owner per train.
5. The hold is committed in the inventory database with one atomic update. The inventory is sharded by train: split across many database machines, with every row for one train on the same machine.
6. Payment happens next, at a payment gateway run by someone else, which is slow.
7. On success, ticketing issues the PNR (the booking reference printed on your ticket) and sends the SMS and email. Meanwhile the hold sweeper keeps returning expired holds.

Read the numbered path as a funnel. The waiting room admits a fraction of arrivals. The availability cache answers most of the admitted requests without touching a database. Only genuine hold attempts reach the booking service, and only successful holds reach the inventory database. By the time a request costs a write, the system has already rejected most of its neighbours for almost nothing.

The two boxes worth defending are the waiting room and the booking service. The waiting room turns a stampede into a line, which is a product decision as much as a technical one. The booking service is the deliberate bottleneck: one owner per train, so that seat 14B has exactly one place in the world where it can be claimed.

Step 3: Design deep dive#

The queue is the product#

Picture a railway ticket counter where 500 people rush the window at once. The clerk is no faster for the crowd, the shouting slows everything down, and whoever has the longest arm wins. A token machine at the door fixes all three: one person at a time, everyone knows their number, and when the tickets run out the person at the door can say so to everyone still in line.

This is not a workaround. It is better for every party. The backend runs at its designed rate rather than in overload, so it stays correct and fast for the people it is serving. Users see a position that moves instead of a spinner that lies. And a queue position assigned at arrival is a far more defensible definition of fairness than "whoever's packets arrived during the one second when the server was not saturated". Turning people away early and cheaply has a name, load shedding, explained in rate limiting vs throttling vs backpressure.

Here is one user's trip, step by step.

Not selling seat 14B twice#

With 500 people per seat all aiming at one row, the way you take a seat off the count is the whole system. Contention is the word for many requests fighting over the same piece of data at the same moment.

Try the race yourself. In "Read, then write", run A, then B, then A, then B, and watch both requests win the same seat. Switch to the conditional update and try any order you like.

The first rung is the classic lost update, and the second is a pessimistic lock. The same article shows the version number trick that the version column of the inventory table is for.

The three strategies, drawn side by side:

The honest answer combines the last two. An atomic conditional update is correct and cheap, and it should be the mechanism. Serialising per train on top of it, one ordered queue per train with a single consumer, is what makes the order explainable to somebody who asks why they lost. A queue keeps its order only within one partition, which is why it is one per train: see partitions decide your parallelism. On a public system carrying this much frustration, an explainable order is a genuine requirement.

That is why the inventory table is one row per train, date and class, sharded by train_id: every request for one train lands on one database machine on purpose, and the operation on that row is one short atomic statement.

Why may search show an old number while booking may not? Because they are different promises. Search says "roughly this many seats", and a few seconds of staleness costs nothing. Booking says "this seat is yours", and staleness there sells a seat twice. Deciding consistency per feature like this is the idea in strong vs eventual consistency.

The hold that nobody paid for#

A hold takes a seat out of inventory before any money exists. That means every hold is a promise the system has to clean up after.

The hold row carries an expiry a few minutes out. A sweeper runs constantly, finds expired holds, and returns those seats to available. This job is not a background nicety: during the tatkal window it is actively returning inventory to a queue of people still waiting, so its lag is directly visible as seats that exist but nobody can buy.

Then the ambiguity you have already met on the payment rail: payment says nothing for thirty seconds. The seat is held, the money may or may not have moved, and the user is watching. The rules are identical. Never retry the payment, ask about it by transaction id. Do not release the hold while its payment is in an unknown state, because releasing a seat that was in fact paid for is far worse than holding it a few minutes longer. Resolve, then either confirm or refund.

Break it#

Move the clock and watch which box turns red.

Trade-offs#

The level bar#

One moment from this round, answered three ways. Pick the one you think is staff level before the labels appear. (What changes at senior and staff explains the gap.)

Then run the question cold, with a 45 minute timer and no notes, and score the run on the five things this question is really testing.

Interview replay#

p99 in that last answer means the time 99 out of 100 users beat, so it tracks the unlucky one in a hundred rather than the average. Percentiles, quickly explains why averages hide exactly the users who are suffering.

Checkpoint#