Secunderabad / Hyderabad
Backup data center for regional fault tolerance. This demo models a controlled takeover with health-check-driven routing.
RailSaanjh ARCHITECTURE LAB
Booking prototypeTATKAL / REQUEST FLOW EXPERIMENT
One rush. Two ways through.
Follow requests from arrival to a ticket. Give both systems the same infrastructure and see what changes.
8 seconds visualise pre-opening registration. At 0s the same cohort competes for one train / class / Tatkal quota. Observation window: 3 minutes (180 seconds).
Live architecture overview
User request → ticket confirmationTravellerApp / web requestGeo-route
Edge shieldRate limit + WAFToken bucket
AI risk gateBot & anomaly scoreEnsemble score
Waiting roomFair admissionSeeded shuffle + FIFO
Regional PRSQuote + allocationIdempotency + locks
PaymentAuthorise & reconcileSaga pattern
ConfirmationPNR / ticket issuedExactly-once outcome
Regional request routing
Illustrative demo data · select a regionRequests shown here follow the Direct booking method.
RequestsEdge entry
Request routeBackup route
Secunderabad / HyderabadDisaster recovery
ACTIVE DATA CENTER
HEALTHYNew Delhi
Northern Region
Demo requests / min4,82,000
Edge → region p9542 ms
Cluster load88%
- Train affinity
- Rajdhani · Shatabdi · Vande Bharat
- Routing key
- train region → quota → service partition
Run the experiment to animate regional traffic
Gurugram + Secunderabad
RailTel Tier-III facilities shown as supporting enterprise cloud and recovery capacity.
Failover algorithm
Active health probes → circuit breaker → DNS / traffic-manager shift → idempotent request replay.
Architecture labels are a public-source-informed educational model, not a claim about live IRCTC routing. Sources: Chennai data center · RailTel data center services · India outline, Wikimedia Commons (CC BY-SA 3.0; restyled).
Direct booking
01
Identity / intent02,000 unique travellers
02
Request race00 rejected requests
03
Fare quote0One PRS operation
04
Mock payment05s baseline delay
05
PRS allocation0One PRS operation
Ticket issued0600 berths remain
PRS requests0
Requests rejected0
Successful bookings0
Idempotent single bookingQueue-controlled
01
Identity / intent02,000 unique travellers
02
Waiting room00 joins restored
03
Offer → claim00 permits claimed
04
Fare quote0One PRS operation
05
Mock payment05s baseline delay
06
PRS allocation0One PRS operation
Ticket issued0600 berths remain
PRS requests0
Slots occupied0 / 320
Successful bookings0
Queue never holds a berthStart the experiment to compare backend demand
Infrastructure is an input. Request counts and outcomes emerge from the model.
Requests reaching PRS
Calls / simulated secondDirectQueue-controlledPRS capacity
Rejected buffer entries count as origin traffic. Successful quote and allocation calls consume capacity. Waiting-room polls stay at the edge.
Compare the outcomes
| Metric | Direct booking | Queue-controlled |
|---|---|---|
| Run status | In progress | In progress |
| Elapsed time after opening | 0.0s | 0.0s |
| Successful bookings | 0 | 0 |
| Bookings / min · elapsed average | 0.0 | 0.0 |
| PRS requests / successful booking | — | — |
| Total edge requests | 0 | 0 |
| Origin buffer rejections · retryable | 0 | 0 |
| p95 completed PRS call latency | — | — |
| p95 opening → terminal result | — | — |
| Ordinary traveller booking success | 0.0% | 0.0% |
| Aggressive traveller booking success | 0.0% | 0.0% |
| Still waiting or in progress | 0 | 0 |
| Declined / expired / sold out / refund due | 0 / 0 / 0 / 0 | 0 / 0 / 0 / 0 |
| Observed admission invariant violations | Not applicable | 0 |
Success rates use all configured travellers. p95 results include terminal outcomes only; unfinished users are reported separately. A single seed is not statistical proof of fairness.
Follow a traveller
TRAVELLER 1 Ordinary requester · queue shuffle rank 1423 / 2,000
Direct bookingARRIVING
Waiting for this traveller to arrive.
Queue-controlledARRIVING
Waiting for this traveller to arrive.
What scales with queue size?
N = unique entrantsO(1)Identity lookup & claimExpected indexed lookup and an atomic state transition. Independent of N.
O(log N)Indexed queue rankAbout 11 levels for 2,000 entrants. Exact costs depend on the data structure.
O(N)Opening cohort shuffle1,999 Fisher–Yates swaps once, then a queue cursor advances through that order.
These describe a proposed implementation. The browser engine scans travellers every 0.25s to visualise their state; its execution speed is not the production queue’s capacity.
Model assumptions & how to present the evidence
This is a local discrete-time model, version request-flow-1.1. Each synthetic traveller needs one berth and two PRS operations: quote and allocation. A shared FIFO service budget processes calls at your configured rate, with a two-second request buffer. Neither mode has a privileged payment or inventory implementation.
Direct clients retry rejected requests every 2s; aggressive clients retry at the selected multiplier, capped at four attempts/s by the 0.25s time step. Queue clients register once, restore duplicate joins, poll every 4s (aggressive clients poll faster), receive an offer, and claim after 0.5s. Offers expire after 60s; claimed permits expire after 120s. No-shows apply only to the offer flow and cost real model capacity.
The queue uses a repeatable seeded shuffle for illustration, not a cryptographic lottery. Identity uniqueness and permit checks are modelled state, not implemented production authentication or signing. Every traveller has the same seeded payment-decline outcome in both runs. Payment delay is chosen when payment starts. Sold-out signals cancel pending unauthorised payments; authorised payments without a berth become refund-due results.
Faults begin at +20s and end at +40s. PRS slowdown cuts service and queue admission rates to 25% with ideal immediate feedback. Controller outage pauses new offers only; existing permits continue. These are modelled faults, not measured recovery or distributed failover.
Results may favour either approach. More infrastructure can remove contention; a queue still imposes claim and waiting overhead. Compare multiple seeds, show pending users, and distinguish model time from wall-clock benchmarks. This experimental direct baseline does not reproduce IRCTC’s private architecture.
Out of scope: real load generation, network and CPU measurements, storage replication, distributed locks, multi-train partitioning, actual bots or identity checks, route-segment allocation, group bookings, fare variation, payment reconciliation, and real security verification. The capacity bound is an illustrative upper bound derived from assumptions; no conversion from Big-O into measured RPM is made.