IRCTC Tatkal system design: one booking at ten in the morning, from the login to the PNR

Follow one IRCTC Tatkal booking at 10 AM: bots dropped, gateway copies scaled out, a rate limit, a cached search, an Aadhaar OTP, UPI, and berths from PRS.

Berths confirmed

  1. It’s ten o’clock, and Tatkal opens for tomorrow’s trains. Rajat logs in, to book two berths on the Karnataka Express to Delhi.
  2. Lakhs of logins arrive in the same second, and about half of them are bots. The bot manager, at the CDN’s edge, spots them and drops them.
  3. Rajat’s login is real, so it reaches the load balancer, which spreads the rush across identical copies of the API gateway.
  4. When traffic rises, copies are added. For Tatkal they’re added just before ten, eight becoming twenty-four, because this rush arrives in one second, faster than any autoscaler could react.
  5. It sends Rajat to Gateway 2, the least busy copy right now.
  6. The gateway asks the rate limiter first. A person taps a few times a minute; a script hammering the button gets a four twenty-nine, and goes no further.
  7. Auth checks his password and the CAPTCHA, and gives him a signed session token.
  8. The answer goes back the way it came. Rajat is logged in.
  9. He searches for his train. This time, the load balancer picks Gateway 3.
  10. Gateway 3 has never seen him, but his token proves who he is. No copy keeps him in memory, so any copy can serve him.
  11. Search answers from Redis. Lakhs of people are checking the same trains, so availability is cached, and PRS, the railways’ reservation system, is asked only on a miss.
  12. His phone shows 3A, twelve available. He picks it, and adds himself and DK.
  13. Booking starts his ticket, and asks Identity for an Aadhaar check. UIDAI, which runs Aadhaar, texts a one-time code to his linked mobile.
  14. His phone asks for the code. It comes by SMS, and fills itself in.
  15. Identity has UIDAI check it, and it matches. UIDAI only answers yes or no; it never shares his Aadhaar details.
  16. Now he pays 6,900 rupees. Payment sends a UPI request with an idempotency key, so a retry can never charge him twice.
  17. Rajat approves it in his UPI app. The bank’s signed callback, never the phone, tells Payment the money is in.
  18. Only now does Booking ask PRS for berths. Each train has a single writer, so requests for train 12627 are handled one at a time, in order.
  19. Berths are still left, so Rajat gets two: B3, 33 and 36, with a PNR.
  20. The ticket goes back the way it came, and his phone shows it.
  21. Meanwhile, Booking publishes Ticket Booked to Kafka, and Notification texts him the PNR.
  22. Bots dropped at the edge, copies added before the rush, a limit for every user, a cache for every search, and one writer per train. After half past ten, the extra copies are removed.

Sold out · waitlist

  1. It’s ten o’clock, and Tatkal opens for tomorrow’s trains. Rajat logs in, to book two berths on the Karnataka Express to Delhi.
  2. Lakhs of logins arrive in the same second, and about half of them are bots. The bot manager, at the CDN’s edge, spots them and drops them.
  3. Rajat’s login is real, so it reaches the load balancer, which spreads the rush across identical copies of the API gateway.
  4. When traffic rises, copies are added. For Tatkal they’re added just before ten, eight becoming twenty-four, because this rush arrives in one second, faster than any autoscaler could react.
  5. It sends Rajat to Gateway 2, the least busy copy right now.
  6. The gateway asks the rate limiter first. A person taps a few times a minute; a script hammering the button gets a four twenty-nine, and goes no further.
  7. Auth checks his password and the CAPTCHA, and gives him a signed session token.
  8. The answer goes back the way it came. Rajat is logged in.
  9. He searches for his train. This time, the load balancer picks Gateway 3.
  10. Gateway 3 has never seen him, but his token proves who he is. No copy keeps him in memory, so any copy can serve him.
  11. Search answers from Redis. Lakhs of people are checking the same trains, so availability is cached, and PRS, the railways’ reservation system, is asked only on a miss.
  12. His phone shows 3A, two available. He picks it, and adds himself and DK.
  13. Booking starts his ticket, and asks Identity for an Aadhaar check. UIDAI, which runs Aadhaar, texts a one-time code to his linked mobile.
  14. His phone asks for the code. It comes by SMS, and fills itself in.
  15. Identity has UIDAI check it, and it matches. UIDAI only answers yes or no; it never shares his Aadhaar details.
  16. Now he pays 6,900 rupees. Payment sends a UPI request with an idempotency key, so a retry can never charge him twice.
  17. Rajat approves it in his UPI app. The bank’s signed callback, never the phone, tells Payment the money is in.
  18. Only now does Booking ask PRS for berths. Each train has a single writer, so requests for train 12627 are handled one at a time, in order.
  19. But in the minute Rajat took to pay, the last two berths went to people ahead of him. The cache said available; PRS decides. He gets the Tatkal waitlist: seven and eight.
  20. The ticket goes back the way it came: waitlisted, seven and eight.
  21. Meanwhile, Booking publishes Ticket Booked to Kafka, and Notification texts him the PNR.
  22. If it’s still waitlisted when the chart is prepared, it’s cancelled and refunded on its own.

A server goes down

  1. It’s ten o’clock, and Tatkal opens for tomorrow’s trains. Rajat logs in, to book two berths on the Karnataka Express to Delhi.
  2. Lakhs of logins arrive in the same second, and about half of them are bots. The bot manager, at the CDN’s edge, spots them and drops them.
  3. Rajat’s login is real, so it reaches the load balancer, which spreads the rush across identical copies of the API gateway.
  4. When traffic rises, copies are added. For Tatkal they’re added just before ten, eight becoming twenty-four, because this rush arrives in one second, faster than any autoscaler could react.
  5. It sends Rajat to Gateway 2, the least busy copy right now.
  6. The gateway asks the rate limiter first. A person taps a few times a minute; a script hammering the button gets a four twenty-nine, and goes no further.
  7. Auth checks his password and the CAPTCHA, and gives him a signed session token.
  8. The answer goes back the way it came. Rajat is logged in.
  9. He searches for his train. But seconds ago, Gateway 2 crashed. The load balancer’s health check caught it, so it stops sending anyone there, and a fresh copy starts in its place.
  10. His search goes to Gateway 3 instead. His token proves who he is, so he never has to log in again.
  11. Search answers from Redis. Lakhs of people are checking the same trains, so availability is cached, and PRS, the railways’ reservation system, is asked only on a miss.
  12. His phone shows 3A, twelve available. He picks it, and adds himself and DK.
  13. Booking starts his ticket, and asks Identity for an Aadhaar check. UIDAI, which runs Aadhaar, texts a one-time code to his linked mobile.
  14. His phone asks for the code. It comes by SMS, and fills itself in.
  15. Identity has UIDAI check it, and it matches. UIDAI only answers yes or no; it never shares his Aadhaar details.
  16. Now he pays 6,900 rupees. Payment sends a UPI request with an idempotency key, so a retry can never charge him twice.
  17. Rajat approves it in his UPI app. The bank’s signed callback, never the phone, tells Payment the money is in.
  18. Only now does Booking ask PRS for berths. Each train has a single writer, so requests for train 12627 are handled one at a time, in order.
  19. Berths are still left, so Rajat gets two: B3, 33 and 36, with a PNR.
  20. The ticket goes back the way it came, and his phone shows it.
  21. Meanwhile, Booking publishes Ticket Booked to Kafka, and Notification texts him the PNR.
  22. A server died in the middle of the rush, and Rajat never noticed. The load balancer routed around it, and a new copy took its place.