- 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 test setup, measured on 18 September 2026. Method and raw runs are published.
Server-side latency below is processing time on the SeatLayer side, 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; server-side availability latency p99 4 ms; server-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 sent as concurrent hold requests, 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
- This was a local benchmark: the load generator shared a machine with the service, so end-to-end request percentiles include that contention. The server-side figures are the ones to read.
- The fixture is one synthetic 12,000 seat event. When two buyers compete for a seat, exactly one competing request wins. Simulated buyers use think time, so 10,000 buyers is not 10,000 simultaneous bookings.
- The test measures seat inventory on its own, with trusted access: no public authentication and no rate limiting. 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 was run against a non-production SeatLayer environment with a small existing fixture, so it exercised real public routes, 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 workload. The two results are not combinable into a claim about 10,000 buyers on a very large event.