Tatkal API architecture: every call behind one Tatkal ticket
Every call behind one Tatkal ticket: a login past the rate limit, a cached search, the Aadhaar OTP, UPI's signed callback, then berths from PRS or a waitlist.
Berths confirmed
Here’s one Tatkal booking, call by call. At ten, the app sends Rajat’s login, and the load balancer hands it to Gateway 2.
The gateway checks the rate limit first: a count per user, in Redis. A script past the limit gets a four twenty-nine.
Then Auth checks his password and the CAPTCHA, and signs a session token.
The app gets the token. Rajat is logged in.
He searches for his train. This time the load balancer picks Gateway 3, which checks his token and asks Search.
Search answers from the Redis cache, so PRS is asked only on a miss: 3A, twelve available.
He books two berths, with an idempotency key. Gateway 1 passes it to Booking, which asks Identity for an Aadhaar check.
UIDAI texts a code to his linked mobile, and the app is told: enter the OTP.
Rajat sends the code. It lands on Gateway 3, and that’s fine: any copy can serve him.
Booking has Identity check it with UIDAI, which answers only yes or no, never his Aadhaar details.
Verified. Booking asks Payment to charge 6,900 rupees, under the same key, so a retry can never charge him twice.
Payment sends a UPI request. Rajat approves it, and the bank’s signed callback, never the phone, says paid.
Only now does Booking ask PRS for two berths. Each train has one writer, so requests for 12627 go one at a time.
Berths are left, so two are his: B3, 33 and 36, with a PNR.
The ticket goes back to the app, and Booking publishes Ticket Booked to Kafka, so the SMS follows.
Twenty-six calls: a rate limit, a token any copy can trust, a cached search, and one writer per train.
Every call, in order
Rajat → API Gateway: POST /login — { user: rajat_k91, password, captcha } · 10:00:00 · bot manager → LB → Gateway 2 (REST · HTTPS)
API Gateway → API Gateway: rate limit — Redis INCR rl:rajat_k91 → 1 this minute · past the limit: 429 (Internal RPC)