Skip to content

Battle Questions · Gaming

Ten thousand simultaneous battles, decided in under 50ms

A competitive trivia platform where timing is a gameplay mechanic — so the game engine is server-authoritative, sub-50ms at p99, and treats a 500ms discrepancy as a fairness bug rather than a performance one.

10K+simultaneous battles

At a glance

Duration
43 weeks
Team size
5 people
Engagement
New build
Project type
Web application
Industry
Media & Entertainment

The situation

The challenge

In a game where timing decides the winner, a 500ms difference in when two players receive a question is not a performance problem, it is a fairness problem. On top of that, anti-cheat had to stop answer lookup and bots without punishing legitimate players for being fast.

What we did

Every timing decision moved to the server, and every battle became a small in-memory state machine rather than a database transaction.

The calls that mattered

  • Battles live in Redis, not Postgres

    Each battle is a Redis hash driven by Lua scripts for atomic operations. A relational transaction per answer would have made the database the referee, and the referee would have been the slowest participant.

  • Client timings are rejected outright

    Server-authoritative timestamps with synchronised delivery via keyspace notifications. Any protocol that trusts the client's clock is a protocol that rewards tampering with the client's clock.

  • Shadow mode instead of bans

    Statistical timing analysis flags sub-150ms responses and suspiciously low variance; confirmed cheats are matched against each other rather than told. Deterrence took the flag rate from 2.1% to 0.4%.

What changed

simultaneous battles
10K+simultaneous battles
p99 game engine latency
<50msp99 game engine latency
daily active users
75K+daily active users
cheat flag rate
0.4%cheat flag rate
  • 75K+ — 38-minute average session
  • 0.4% — down from 2.1% in the first month

10,000+ concurrent battles at sub-50ms p99, 75,000+ daily active users averaging 38-minute sessions, and a cheat rate down to 0.4% — at $0.0003 of infrastructure per battle.

Services used

  • Redis-backed game engine with atomic Lua operations
  • Server-authoritative timing and synchronised question delivery
  • Layered anti-cheat with statistical analysis and shadow mode
  • Matchmaking and Elo-adjusted accuracy tracking

What we would do differently

Every project has one of these. Publishing it is the point — a case study with no regrets in it is marketing, not evidence.

Game backends have a different performance contract from typical web APIs. Redis Lua scripts, pre-loading and server-authoritative timing are not over-engineering for a trivia game; they are the minimum viable correctness. We would reach for them on day one next time rather than proving the need first.

Services used

More work

Ready to start?

Start a project like thisWork