RailSaanjh / simulation evidence
Same bookings.
Far fewer PRS requests.
One opening rush. Two access models. See how controlled admission changes the number of attempts reaching the Passenger Reservation System (PRS), without changing available inventory.
90% aggressive · extreme stress test
New queue offers · R: 400/s / Active + offered slots · C: 3,000 / Aggressive travellers: 90%
94.19%
fewer PRS request attempts
10,000 successful bookings in each model
Both bars use the direct model’s total as 100%. Counts include retryable buffer rejections.
- Fewer attempts reaching PRS
- 365,477
- PRS requests / booking · direct → queue
- 38.80 → 2.25
- Queue-side PRS buffer rejections
- 0
90% aggressive · extreme stress test: 94.19% fewer PRS requests, 10,000 bookings in each model.
Same admission. Increasing retry pressure.
Retries rise. Queue-controlled PRS traffic stays flat.
Only Aggressive travellers changes below. R stays at 400/s and C at 3,000. The growing reduction comes from more direct-booking attempts—not from fewer queue-controlled bookings.
PRS request attempts
Hover to inspect. Click or tap to pin a point. Use arrow keys when the graph is focused; Escape clears the tooltip.
Aggressive travellers (%)
- Direct · 90% aggressive
- 388,009
- Queue-controlled
- 22,532
- Fewer PRS requests
- 94.19%
R 400/s · C 3,000 · 10,000 bookings in each model. Lines connect the four recorded scenarios; intermediate values are not measured.
70% and 90% are adversarial stress assumptions, not measured shares of real Tatkal users. Waiting-room joins and polls still require resources; they do not disappear.
The settings behind every result
Use these values in the request lab. All rows filled 10,000 berths in both models within the 180-second experiment window.
| Scenario | New offers · R /s | Active + offered · C | Aggressive travellers | Direct requests | Queue requests | Queue rejections | Reduction |
|---|---|---|---|---|---|---|---|
| Request-efficient admission | 100 | 1,000 | 10% | 87,158 | 20,840 | 0 | 76.09% |
| Conservative admission | 400 | 3,000 | 10% | 87,158 | 22,532 | 0 | 74.15% |
| Balanced admission | 800 | 6,000 | 10% | 87,158 | 24,574 | 0 | 71.81% |
| Higher admission | 1,000 | 8,000 | 10% | 87,158 | 25,887 | 0 | 70.30% |
| Retry storm · balanced admission | 800 | 6,000 | 40% | 126,431 | 24,574 | 0 | 80.56% |
| Excessive admission · stress test | 2,000 | 16,000 | 10% | 87,158 | 49,881 | 18,077 | 42.77% |
| 40% aggressive · fixed admission | 400 | 3,000 | 40% | 126,431 | 22,532 | 0 | 82.18% |
| 70% aggressive · stress test | 400 | 3,000 | 70% | 262,557 | 22,532 | 0 | 91.42% |
| 90% aggressive · extreme stress test (selected) | 400 | 3,000 | 90% | 388,009 | 22,532 | 0 | 94.19% |
R is the maximum new turn offers per second, not completed claims. C limits offered turns awaiting a claim plus claimed turns still booking. Neither setting reserves a berth.
Shared experiment settings
Both models use these infrastructure and payment assumptions. The offer no-show and claim-window settings apply only to the queue flow.
- Unique travellers
- 20,000
- Available berths
- 10,000
- PRS processing capacity
- 2,000 calls/s
- Payment duration
- 5 s
- Retry frequency multiplier
- 20×
- Payment decline probability
- 3%
- Queue offer no-show probability
- 2%
- Failure injection
- None · healthy services
- Scenario seed
- 42
- Simulation duration
- 180 s maximum
- Offer claim window
- 60 s
- Claimed booking window
- 120 s
What these numbers mean—and what they don’t
PRS requests are attempts at the origin boundary. They include requests rejected by the finite PRS buffer, not just successfully processed operations. They are not a measurement of CPU, database work, infrastructure cost or all system traffic.
Reduction (%) = (direct requests − queue requests) / direct requests × 100Each synthetic booking needs two successful PRS operations: a quote and an allocation. Both modes use the same FIFO backend with a two-second request buffer. Direct clients retry rejected attempts; queue clients join and poll outside PRS, then claim a controlled turn. Offered turns never hold inventory.
The engine advances in 0.25-second steps. The configured 20× retry multiplier is limited by that resolution to at most four retry attempts per second per traveller. Identity checks, permits, payments and inventory are modelled—not real integrations.
Scope of the claim: these are deterministic seed-42 results from request-flow-1.1, not averages or confidence intervals. “Up to” refers to the largest reduction among the nine published scenarios. It is not a guarantee for other settings. The comparison is against a synthetic direct-access baseline, not a reproduction of IRCTC’s private architecture.
Results focus on request attempts per completed booking, not speed. A lower request count can involve a longer wait. Validate production throughput, fairness, latency and resilience separately with real load testing.
The lab opens with its own defaults. Copy the shared settings and your chosen scenario above to reproduce a result.