- 10,000 concurrent buyers tested on one event: hold p99 9 ms, zero server errors.
- 400,000 of 400,000 live seat updates delivered to 10,000 connected viewers.
- 3,552 requests per second sustained for two minutes on a single event.
Simulated buyers in an isolated engine harness, measured on 18 September 2026 against engine revision 8d4f28dc1. Method and raw runs are published.
Engine-side latency below is the time the event engine took to process the request, measured at the engine boundary, excluding network.
Measured workloads
| Workload | Result |
|---|---|
| 10,000 simulated concurrent buyers with think time | 390,795 requests at 3,552.7 requests per second; 0.0082% transport failures; zero server errors; engine-side availability latency p99 4 ms; engine-side hold latency p99 9 ms |
| 500-client public API read burst | 1,000 reads succeeded; combined read p95 1.19 seconds |
The mixed workload performed availability reads, occasional compact inventory reads, and one to two seat holds followed by release. Each virtual user waited 1.5 to 2.5 seconds between iterations, and 5% of iterations attempted a hold. The run ramped to 10,000 buyers over 120 seconds and held them there for a 120 second plateau, with virtual users pinned at exactly 10,000 for every sample of the plateau window. Across the 390,795 plateau requests the transport failure rate was 0.0082% and no response carried a server error status. 12,977 holds were accepted and 1,098 were refused, which is expected when seat labels are drawn at random across 12,000 seats and two buyers reach for the same seat.
Hold updates were measured in a separate socket run: 40 distinct seat holds per stage in four bursts of ten concurrent writers, with a 10 second delivery deadline. Every requested socket connected and every expected update arrived.
| Connected viewers | Hold request p95 | Update p95 | Update p99 | Received / expected |
|---|---|---|---|---|
| 100 | 10.2 ms | 26.9 ms | 27.4 ms | 4,000 / 4,000 |
| 500 | 6.4 ms | 34.1 ms | 34.6 ms | 20,000 / 20,000 |
| 1,000 | 20.6 ms | 51.1 ms | 51.9 ms | 40,000 / 40,000 |
| 2,000 | 14.4 ms | 59.4 ms | 60.9 ms | 80,000 / 80,000 |
| 5,000 | 75.8 ms | 220.4 ms | 225.6 ms | 200,000 / 200,000 |
| 10,000 | 169.6 ms | 382.9 ms | 394.0 ms | 400,000 / 400,000 |
Update latency grows with recipient count: p95 was 59.4 ms at 2,000 connected viewers and 382.9 ms at 10,000. No missing deliveries, no hold failures and no unexpected disconnects at any stage.
What this does and does not show
- The load generator and the engine ran on one workstation, so the end-to-end request percentiles carry load generator contention. The engine-side figures are the engine signal.
- The fixture is one synthetic 12,000 seat event with one ordering authority per event. Simulated buyers use think time, so 10,000 buyers is not 10,000 simultaneous bookings.
- The harness ran current event-engine code with trusted access: no public authentication, no rate limiting, no main database or queue connections, and no tenant metadata. The compact inventory response reported a byte count rather than the full inventory.
- Payments, order creation, confirmed bookings and best-available selection were outside the run.
- The 500-client read burst used the deployed development service and a small existing fixture, so it exercised real public routes and database access, with a 138 byte compact inventory response.
- Local throughput does not override platform limits. This is workload-specific evidence, not a production capacity ceiling.
Renderer and concurrency evidence
The 200,000-seat renderer benchmark measures browser chart readiness and interaction, a separate scenario from this 12,000 seat event-engine workload. The two results are not combinable into a claim about 10,000 buyers on a very large event.