IRCTC System Design Interview: Tatkal and Train Booking at Scale
When Tatkal booking opens at exactly 10 AM, a fixed, tiny pool of train seats meets a rush of people all trying to grab them in the same instant. IRCTC has recorded 37,410 tickets booked in a single minute, and books close to 14 lakh tickets a day for about 66 million registered users, on a reservation system that must never sell the same berth twice.
Designing IRCTC is the fixed-inventory, fixed-time-spike problem at national scale. Every train has a bounded number of seats, split across quotas like general and Tatkal, and the Tatkal quota opens at a fixed minute, 10 AM for air-conditioned classes and 11 AM for others, so a huge crowd hits a scarce pool at exactly the same moment. The system must sell each berth once and only once under that pressure, handle waitlist and reservation-against-cancellation states, and hold off bots trying to grab seats faster than people. IRCTC and the railways body that runs the reservation backend publish capacity and record numbers but not the internal seat-locking design, so this walkthrough reasons about the fixed-inventory contention from first principles and is clear about what is stated versus inferred.
Asked at: Commonly asked at IRCTC and railway-technology teams, and the general forms, meaning design a ticket-booking system, a seat-reservation system, or a flash-sale-style fixed-inventory system, show up at Amazon, Google, and most product companies for SDE2 and SDE3 rounds. IRCTC is a favorite in the Indian market because the Tatkal spike is a vivid, concrete version of the fixed-inventory contention problem that everyone has experienced.
Why this question is asked
Train booking concentrates several hard problems. The inventory is fixed and scarce: a train has a set number of berths per class, and a seat sold twice is a real person with no place to sit, so overbooking is unacceptable and strong correctness under concurrency is required. The demand is a fixed-time megaspike: Tatkal opens at a known minute, so a mass of users all try to claim the same small pool at once, which reactive scaling cannot absorb after the fact. And there is an adversarial dimension, since bots and agents try to grab seats faster than humans, which IRCTC actively fights. Interviewers use IRCTC to check whether you can design a fixed-inventory booking system that never double-sells under extreme concurrency, provision for a predictable spike, and model waitlist and reservation-against-cancellation as real states, while being honest that the exact internal mechanism is not public and reasoning from first principles.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- User searches trains between two stations on a date and sees availability by class and quota
- User books a ticket against a specific quota (general, Tatkal, ladies, and others), paying online
- The system allocates a specific berth from a fixed pool and issues a booking with a PNR number
- When confirmed berths run out, bookings enter reservation-against-cancellation and then waitlist states
- On cancellations and at chart preparation, waitlisted and RAC bookings are promoted toward confirmation
- Tatkal quota opens at a fixed time (10 AM for air-conditioned classes, 11 AM for others) with its own pool
- User can cancel a ticket and get the applicable refund, and check PNR status
- Defend the booking window against bots and agents so genuine users get a fair chance
Non-functional requirements
- Never sell the same berth twice, even under the Tatkal-open concurrency spike
- Absorb a fixed-time megaspike, since a mass of users hit a scarce pool at exactly 10 or 11 AM
- Strong consistency on seat allocation and payment; a booking is either fully done or fully released
- Very high availability during the Tatkal window, since downtime at the open is highly visible
- Fast availability search, which is read-heavy and spikes with the booking rush
- Scale to national volume: close to 14 lakh tickets a day and tens of thousands in the peak minute
- Fairness controls that keep bots from crowding out genuine users
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Peak bookings per minute
37,410 (observed record)
IRCTC reported an observed record of 37,410 tickets booked in a single minute on 16 August 2025, in the 10 AM window. Records like this cluster right at Tatkal open, which is the defining load event.
Stated system capacity
~32,000 tickets/min (2025)
The railways stated a current booking capacity of about 32,000 tickets per minute in 2025, with roughly 4 lakh enquiries per minute. Note that observed records can slightly exceed a round-number stated capacity, so separate observed peaks from the capacity ceiling.
Planned capacity
target 1.5 lakh tickets/min
The railways announced an upgrade targeting about 1.5 lakh tickets per minute and 40 lakh enquiries per minute, roughly a tenfold enquiry increase, on a modernized system. The trajectory: 2,000 per minute before 2014, 7,200 in 2014, 15,000 in 2015, about 32,000 in 2025.
Daily bookings
~13.9 lakh/day (FY24-25)
IRCTC reported booking about 13.88 lakh tickets a day in FY24-25, with online now around 86 to 89 percent of reserved tickets. Its single-day record was about 18.40 lakh tickets.
Registered users
~66M
IRCTC reported about 66 million registered users as of late 2023. The pool of people who can join the Tatkal rush.
Tatkal-hour record
~1.85 lakh in one hour
IRCTC reported about 1,85,513 tickets booked in the 10 to 11 AM Tatkal hour on 21 March 2024. The hour after open is when the fixed pools are claimed.
High-level architecture
Design IRCTC around two facts: the seat inventory is fixed, and the Tatkal demand arrives at a fixed minute. An important note first: IRCTC is the customer-facing booking and e-commerce layer, while the underlying reservation system is built and run by the railways' technology body, and neither publishes the internal seat-locking design, so the correctness core below is reasoned from first principles as the classic fixed-inventory contention problem, and the capacity, record, quota, waitlist, and anti-bot facts are the parts that are stated publicly. The read path is availability search. A user searches trains between two stations on a date, and the system returns availability by class and by quota. This is read-heavy and it spikes with the booking rush, so it is served from fast, cacheable stores, and it is deliberately separated from the booking path, because search traffic far outnumbers actual bookings and must not slow down the allocation of scarce seats. The railways stated capacity is described in two numbers precisely because of this split: bookings per minute and, much larger, enquiries per minute. The correctness core is seat allocation from a fixed pool. Each train has a bounded number of berths per class per date, and these are further divided into quotas, general, Tatkal, ladies, premium Tatkal, and others, so the real unit of inventory is a pool for a given train, class, date, and quota. Selling a berth from a pool must be atomic: two simultaneous bookings can never both take the last seat. The standard way to guarantee this, since IRCTC does not publish its mechanism, is to serialize allocation on each pool, using an atomic decrement or a lock or a queue per pool, so that within one pool bookings are effectively ordered, while different pools proceed in parallel. A successful allocation issues a booking with a PNR number, and payment is captured so the booking is either fully done or fully released. The scarcity means most of the design pressure is on this atomic allocation under load. The Tatkal spike shapes the whole system. Because Tatkal opens at a fixed minute on a scarce pool, the load is a near-instant vertical spike that reactive autoscaling cannot catch, so capacity is provisioned ahead of the open, and the railways have raised stated capacity over the years from 2,000 to about 32,000 tickets a minute, targeting 1.5 lakh. When confirmed berths run out, bookings do not simply fail; they enter reservation-against-cancellation and then waitlist states, which are first-class inventory states, and on cancellations and at chart preparation, now done about 8 hours before departure, waitlisted and RAC bookings are promoted toward confirmation in order. Finally, because the reward for speed attracts bots, IRCTC layers on fairness controls: it reported deactivating crore-scale suspicious accounts, adding one-time-password authentication for Tatkal, and barring agents from the first 30 minutes of the Tatkal window.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Availability search
The read path that returns train and seat availability by class and quota for a route and date. Read-heavy and spiky, served from fast, cacheable stores, and kept separate from the booking path so that search volume does not slow down the allocation of scarce seats. Enquiry capacity is stated separately from and far above booking capacity.
Seat inventory and quota manager
The source of truth for the fixed pool of berths per train, class, and date, divided into quotas. The real inventory unit is a pool for a train, class, date, and quota. This is where scarcity lives, and where allocation must be strictly correct.
Booking and allocation service
The correctness core that allocates a specific berth from a pool atomically, so the same berth is never sold twice, and issues a booking with a PNR. Since the internal mechanism is not published, it is described as serialized per-pool allocation, an atomic decrement or lock or queue per pool, which is the standard fixed-inventory approach.
Payment and PNR
Captures payment for a booking idempotently and ties it to a PNR number, so a booking is either fully completed or fully released, and a retry never double-charges or double-books. PNRs are issued per booking.
Waitlist and RAC engine
Manages the reservation-against-cancellation and waitlist states that bookings enter when confirmed berths run out, and promotes them toward confirmation, in order, on cancellations and at chart preparation, which now happens about 8 hours before departure. These are genuine inventory states, not just a sold-out flag.
Capacity and spike provisioning
The provisioning that readies the system for the fixed-time Tatkal open, since a near-instant spike cannot be absorbed by reacting after it starts. The railways raised stated booking capacity from 2,000 per minute before 2014 to about 32,000 in 2025, targeting 1.5 lakh, precisely to meet this peak.
Fairness and bot defense
The controls that keep bots and agents from crowding out genuine users during Tatkal. IRCTC reported deactivating crore-scale suspicious accounts, adding one-time-password authentication for Tatkal from mid-2025, and barring agents from the first 30 minutes of the Tatkal window.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
trainstrain_id (PK)numberrouteclassesrun_daysThe train and its classes and route. Static-ish reference data behind availability search.
seat_inventorytrain_iddateclassquotatotal_berthsavailable_berthsThe fixed pool of berths for a train, class, date, and quota. available_berths must be decremented atomically so two bookings never both take the last seat. This is the scarcest, most contended data in the system.
bookingspnr (PK)train_iddateclassquotastate (confirmed|rac|waitlist|cancelled)berthspayment_idcreated_atA booking and its state. state moves through confirmed, reservation-against-cancellation, waitlist, and cancelled. The PNR ties the booking together. Strong consistency required.
passengerspassenger_id (PK)pnr (FK)nameageberth_nostatusThe travelers on a booking, each with an allocated berth or a waitlist or RAC status. Status changes as promotions happen.
waitlist_queuepnrquotapositioncreated_atThe ordered queue of waitlisted and RAC bookings per pool. Promotion on cancellation and at chart preparation walks this in order, moving waitlist toward RAC toward confirmed.
paymentspayment_id (PK)pnr (FK)amount_paisestatusidempotency_keyPayment for a booking, idempotent so a retry during the rush never double-charges. Tied to the PNR, and released if the booking fails to confirm.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
The Tatkal fixed-time megaspike
The defining load event is Tatkal open. Tatkal is a same-day-before-departure quota that opens at a fixed minute, 10 AM for air-conditioned classes and 11 AM for others, on a small, fixed pool of seats. Because the time is known and the pool is scarce, a mass of users all try to book in the same instant, producing a near-vertical spike: IRCTC's records, such as 37,410 tickets in a single minute and about 1,85,513 in the 10 to 11 AM hour, cluster exactly at open. Reactive autoscaling cannot help here, because by the time metrics show the surge, the pool is already being claimed, so capacity must be ready before the minute arrives. The railways have publicly raised stated booking capacity over the years, from 2,000 a minute before 2014 to about 32,000 in 2025, with a target of 1.5 lakh, which is a capacity-planning response to exactly this predictable peak. The interview point is that a predictable, fixed-time spike on scarce inventory is met with pre-provisioned capacity and a very efficient allocation path, not with reactive scaling.
Never selling the same berth twice
The hardest requirement is correctness under concurrency: a berth sold to two people is a real failure. The inventory is a fixed pool for a given train, class, date, and quota, and at Tatkal open, many bookings hit the same pool at once. IRCTC does not publish how it prevents double-allocation, so this is the place to reason from first principles about the classic fixed-inventory contention problem. The core idea is that allocation from a single pool must be serialized so that, in effect, bookings against that pool are ordered and each berth is handed out once. In practice that means an atomic operation on the pool's available count, a decrement guarded by a lock or a conditional update, or a queue that funnels requests for one pool through a single point, so two requests cannot both succeed on the last seat. Crucially, different pools, a different train or class or quota, are independent and can proceed in parallel, so the serialization is per pool, not global, which is what makes the system scale while staying correct. The same discipline as a flash sale on a fixed stock, applied per seat pool.
Waitlist and reservation-against-cancellation as real states
When the confirmed berths in a pool run out, a booking does not simply fail. Indian Railways models two further inventory states. Reservation-against-cancellation gives a shared berth with a guarantee to board, and waitlist gives no berth yet but a position in line. These are first-class states, not just a sold-out flag, and they have their own ordered queues per pool. As confirmed passengers cancel, and again at chart preparation, now done about 8 hours before departure, the system promotes bookings up the ladder in order: waitlist moves toward reservation-against-cancellation, which moves toward confirmed. This makes the design more than binary available-or-sold-out; it is a small state machine per pool with an ordered promotion process that must itself be correct under concurrency, since promotions and fresh cancellations interleave. Modeling these states and the promotion cascade is a distinctive part of the train-booking problem that a simple ticketing design would miss.
Separating search from booking
Far more people check availability than actually book, and both spike together at Tatkal open, so the read path and the write path have very different scale and very different correctness needs. Availability search is read-heavy, tolerant of being a moment stale, and best served from fast, cacheable stores that can be scaled out widely. Seat allocation is a strongly consistent, contended write on scarce inventory. Keeping them separate means the flood of availability checks does not slow down the precious allocation path, and it is why the railways quote two different capacity numbers, a booking capacity and a much larger enquiry capacity of around 4 lakh a minute. The general lesson is to split a system along its consistency and scale seams: cache and scale the reads, protect and serialize the critical writes, and never let cheap reads contend with expensive, correctness-critical writes.
Defending the window against bots
Because a Tatkal seat is valuable and the contest is decided in seconds, there is strong incentive to automate booking, and bots and agents can grab seats faster than people, which crowds out genuine users. IRCTC has made this an explicit design constraint and published its countermeasures: it reported deactivating crore-scale suspicious user accounts and blocking many suspicious email domains, adding one-time-password authentication for Tatkal bookings from mid-2025 so a booking needs a real phone in hand, and barring travel agents from the first 30 minutes of the Tatkal window so individuals get first access. The design tension is fairness versus friction: every check that slows a bot also slows a real user, so the controls aim to raise the cost of automation, phone-based authentication, account trust, timing rules, without making a genuine booking painfully slow. Treating bot defense and fairness as part of the system design, not an afterthought, is a distinctive and publicly-stated aspect of IRCTC.
The customer layer, the reservation backend, and modernization
IRCTC is the customer-facing booking and e-commerce layer, the website and app that users interact with, while the underlying passenger reservation system is built and operated by the railways' technology body. That separation matters: the reservation backend is where berths are actually allocated across the network through regional reservation centers, and IRCTC sits in front of it for online booking, payments, and the user experience. The reservation core is described officially as a decades-old, mainframe-era system now being replaced by a modern, cloud-based platform, which is the context for the capacity jump the railways have announced, toward 1.5 lakh tickets and 40 lakh enquiries a minute. For an interview, the useful framing is that a national booking system is really two layers, a scalable customer front and a strongly consistent reservation core, and that modernizing the core is what unlocks higher capacity, while the internal allocation design remains unpublished and is reasoned about rather than quoted.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
A fixed-time Tatkal open versus a rolling or staggered release
Opening Tatkal at one fixed minute creates the worst-case spike, and staggering releases across time would flatten the load. But a single, known, equal-for-everyone open time is simpler and is seen as fair, since everyone gets the same shot at the same instant. The railways accept the self-imposed spike in exchange for that transparency and fairness, and respond with pre-provisioned capacity rather than by smoothing demand.
Strong consistency on seat allocation versus eventual consistency for scale
Eventual consistency would make the inventory easier to scale, but for seats it is unacceptable, because a berth allocated twice is a real person without a place. So allocation from each pool is strongly consistent and serialized, at the cost of contention on hot pools during the spike. The system scales by making the serialization per pool, so independent trains, classes, and quotas proceed in parallel, keeping correctness where it is non-negotiable while still scaling out.
Modeling waitlist and RAC as states versus a simple sold-out flag
A binary available-or-sold-out model is far simpler, but it would throw away demand and give users nothing when berths run out. Reservation-against-cancellation and waitlist capture that demand, let cancellations flow to the next in line, and give users a real chance as chart preparation approaches. The cost is a per-pool state machine and an ordered promotion process that must stay correct as cancellations and promotions interleave, accepted because it greatly improves how scarce capacity is used.
Separating enquiry capacity from booking capacity versus one path
Serving availability checks and bookings through one path would be simpler, but availability reads vastly outnumber bookings and would starve the critical allocation path during the rush. Splitting them, and provisioning enquiry capacity far higher than booking capacity, lets cheap reads scale on cacheable stores while the scarce, strongly-consistent allocation path is protected. The cost is running two paths and keeping availability acceptably fresh, which is worth it under the spike.
Bot defenses versus friction for genuine users
Leaving the booking window open is frictionless for real users but lets bots dominate a seconds-long contest. Adding one-time-password authentication for Tatkal, purging suspicious accounts, and timing rules for agents raises the cost of automation so genuine users get a fair chance. The cost is some added friction for everyone, which the railways accept and tune, because unchecked bots make the window unfair and unusable for the people it is meant to serve.
How IRCTC actually does it
IRCTC and the railways publish capacity, record, and policy figures but not the internal reservation architecture, so this walkthrough quotes the stated facts and reasons about the seat-allocation core from first principles. IRCTC is the customer-facing e-ticketing layer, while the passenger reservation system is built and run by the railways' technology body, CRIS, which is described officially as replacing a decades-old, mainframe-era system with a modern cloud-based platform. Tatkal is a fixed-time quota that opens at 10 AM for air-conditioned classes and 11 AM for others, on a scarce pool, and IRCTC's observed records cluster at open: about 37,410 tickets in a single minute on 16 August 2025, about 1,85,513 in the 10 to 11 AM hour on 21 March 2024, and a single-day record around 18.40 lakh. The railways stated a current booking capacity of about 32,000 tickets a minute and roughly 4 lakh enquiries a minute in 2025, up from 2,000 a minute before 2014, 7,200 in 2014, and 15,000 in 2015, and announced an upgrade targeting about 1.5 lakh tickets and 40 lakh enquiries a minute. IRCTC reported booking about 13.88 lakh tickets a day in FY24-25, online now around 86 to 89 percent of reserved tickets, for about 66 million registered users. Reservation-against-cancellation and waitlist are genuine inventory states, with promotion on cancellation and at chart preparation, now about 8 hours before departure. On fairness, IRCTC reported deactivating crore-scale suspicious accounts, blocking many suspicious email domains, adding one-time-password authentication for Tatkal from mid-2025, and barring agents from the first 30 minutes of the Tatkal window. Three accuracy notes for the interview. First, separate observed records from stated capacity: 37,410 in a minute is an observed peak, while about 32,000 a minute was the stated capacity, and observed peaks can exceed a conservative round-number ceiling. Second, older concurrent-user figures such as 1.2 lakh or 3 lakh sessions are from the 2014 to 2015 era and should not be presented as current. Third, the internal mechanism that prevents double-booking is not published, so the serialized per-pool allocation described here is the standard fixed-inventory pattern reasoned from first principles, not an IRCTC statement.
Sources
- DD News (government), IRCTC's upgraded system to handle over 1.5 lakh bookings and 40 lakh enquiries per minute: current 32,000 per minute capacity, CRIS, and the modernization
- PIB (Government of India), Next Generation e-Ticketing capable of booking 7,200 tickets per minute: the 2014 capacity and concurrency figures
- IRCTC sets new records: 37,410 tickets in a single minute and 18.40 lakh in a day, plus the crore-scale account deactivation and online share
- Travel And Tour World, IRCTC record bookings, anti-bot ID deactivation, one-time-password Tatkal authentication, and the 8-hour chart preparation
- IRCTC official Tatkal booking rules: the 10 AM air-conditioned and 11 AM non-air-conditioned windows, one-day-advance, and agent restrictions
- Factly, IRCTC capacity growth over the years: from 2,000 to 7,200 to 15,000 tickets per minute, traced to PIB and Parliament figures
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Cache Stampede Prevention
foundation / caching strategies
Rate Limiting for Resilience
advanced / reliability resilience
Idempotency
foundation / core fundamentals
Database Sharding
foundation / database fundamentals
Load Balancing
foundation / core fundamentals
Cache-Aside Pattern
foundation / caching strategies
High Availability
advanced / reliability resilience