Case study · 03 / Gaming

Skybound Arena — a backend that survived launch day.

GoRedisKafkaAWSClickHouse

The problem

The studio had built the game in nine months and had never run a load test. Marketing promised 6× the expected concurrency on launch day — matchmaking, presence and economy services that had to hold without a single incident ticket.

What we did

We built the backend as independent Go services behind a gateway: matchmaking as a reservation system, presence on Redis streams, and a currency-ledger economy that's auditable to the cent. Kafka carries every game event into ClickHouse for product analytics.

Launch readiness was treated as an engineering discipline: load-tested to 150% of the promised spike, a load-shedding path that degrades gracefully (queue the player, never drop them), and a runbook rehearsed the week before with the studio on the call.

Impact

Launch day absorbed the spike with zero incidents. The telemetry pipeline then told product exactly where players quit — matchmaking p95 held at 28ms, and the studio shipped its first live-ops event on time.

100k players Gateway Matchmaking · presence · ledger Kafka events ClickHouse analytics
Wk 1–6Backend built while the game finished Wk 7Load-tested to 150% of the promised spike Launch104k concurrent, zero incidents

Tradeoff we made: queue instead of drop. Under extreme load players wait with honest status copy rather than being kicked — it needed real queue UX, not just a backend flag.

matchmaking-svc · prod
concurrent players104,208 · launch peak absorbed
matchmaking p9528 ms · SLO 60 ms
presence (redis streams)0 lag · 0 dropped
economy ledgeraudited to the cent · 0 drift
incidents0 · runbook never paged
0launch incidents 28msp95 matchmaking
All work Next: Meridian