LOAD TEST REPORT · Oct 31, 2026 23:00

10,000 concurrent requests,
0 duplicate bookings

Concurrent requests against one show with 100 seats · virtual threads · Redis distributed lock + PostgreSQL partial unique index

Every run resets a dedicated show and measures from scratch.

SUCCESS 100 Exactly matches the seat count

REJECTED 9,900 Clean 409s · blocked by lock conflict

DUPLICATE 0 2+ active bookings on a single seat

p99 LATENCY

716 ms

p50 617ms · p95 711ms

BEFORE · NO LOCK FAIL

2427 duplicate bookings

Confirmed seats 2,527 / 100

Overbooking +2427%

p99 857ms

No distributed lock, no unique constraint — just "read, then insert". The gap between SELECT and INSERT is the vulnerability.

AFTER · DISTRIBUTED LOCK PASS

0 duplicate bookings

Confirmed seats 100 / 100

Overbooking 0%

p99 716ms

The Redis lock blocks almost every contender; the partial unique index stops anything that slips through.

Response time distribution (with distributed lock) 10,000 req · 0 error

0ms 192 384 576 720+ (tail)

VERIFICATION

2+ active bookings on a single seat = 0

100 confirmed = 100 seats, matched 1:1

All 9,900 rejections were clean 409s · 0 errors

p99 under lock contention 716ms · 784ms total

Conclusion Under concurrent load, overbooking is structurally impossible.

10,000 concurrent requests,0 duplicate bookings