The three cliffs of live commerce at scale
Up to roughly 2,000 concurrent viewers, almost any architecture works. Past 10,000, three specific failure modes show up reliably. Encoder backpressure when an audience surge outpaces ingest capacity. Chat fan-out melting because every message must reach every viewer. And — the one nobody warns you about — inventory race conditions when a flash drop produces a thousand near-simultaneous buy taps on the same SKU.
The latency budget
Conversion is a step function, not a curve. End-to-end checkout-from-stream — from "tap buy" to "order confirmed" — has to land under 1.5 seconds. Past 2 seconds, conversion drops 40%+. The budget breaks down roughly:
| Stage | Budget | Notes |
|---|---|---|
| Tap → API request | ~150ms | Mobile network jitter dominates |
| Inventory check + reservation | ~300ms | Single-flight is critical here |
| Payment authorization | ~600ms | Stripe/Adyen adds the floor |
| Order confirmation broadcast | ~250ms | Back to viewer + chat |
| Buffer for spikes | ~200ms | Headroom, not theoretical |
Single-flight inventory reservation
Optimistic locking falls over under burst load. The pattern that actually scales is single-flight reservation: a Redis-based lock per SKU with a short TTL, behind which only one reservation request runs at a time. Latecomers either join the same reservation or queue. The lock TTL has to be short — under 200ms — or the queue collapses into a stampede.
Chat is a fan-out problem
38K concurrent viewers can produce 800K messages per minute during a peak drop. Chat must be stateless on the message path. The pattern: receive on the API, validate in 5ms, fan out via a pub/sub layer (we've used both Redis Streams and Cloudflare Durable Objects depending on regional split). Persist asynchronously for moderation; never block on persistence.
- No database write on the message path. Persist async for moderation only.
- Per-room sharding with consistent hashing — same room, same shard.
- Server-sent events (not WebSocket) for read-only viewers; cuts connection memory ~3x.
Stream protocol: HLS is still the right default
LL-HLS and WebRTC promise sub-second latency. They also raise operational complexity sharply — encoder farm sizing, edge POP coverage, fallback paths. Below 50K concurrent, CDN-backed HLS with 4-second segments delivers a 6–10s glass-to-glass latency that's acceptable for most live commerce formats. Above that, the math changes. Below it, the engineering cost rarely justifies the protocol switch.
“We migrated from HLS to LL-HLS chasing latency. We measured the actual conversion lift afterward: 1.2%. Not nothing, but not the 8% we projected. Lesson: instrument first, switch protocols second.”
What we ship in week one
Every live commerce engagement at LNOKS starts with three week-one milestones: load test the inventory reservation path to 5x projected peak, instrument end-to-end latency from the viewer device, and confirm the chat fan-out can handle 10x the projected message rate. If any of those three fails, the architecture changes before product work starts.