TicketLedger is written documentation-first: ten numbered architecture documents — problem statement through booking-failure recovery — covering lifecycle state machines, sequence flows, schema, API contracts, and failure modes, all before the implementation. The repo is meant to be read.

The core guarantee is zero double-bookings, enforced with SELECT FOR UPDATE under strict lock ordering. That choice has a measurable cost, and the docs own it: hot-seat throughput is analytically bounded at ~200 ops/sec per row by lock-commit latency. Correctness is priced in, not assumed.

Java 21 virtual threads park roughly a million connections per JVM at about 1 KB each, which isolates the 20-connection HikariCP pool as the single deliberate bottleneck. Payments are exactly-once through idempotent Stripe webhook processing, and background jobs release held seats on a five-minute timer.