Podium, a Redis-backed leaderboard service, replaced arbitrary equal-score ordering with deterministic first-arrival tie-breaking. The post documents the full benchmarking methodology and results: four competing strategies were tested across five distinct operations, with both direct Redis microbenchmarks and end-to-end HTTP measurements. Key findings: the production tie-break design adds 5–17% latency overhead on writes, nearly negligible overhead on reads (1–3%), but increases Redis memory usage from ~99 to ~287 bytes per member. The most uncomfortable result — a 78% regression on 501-member bulk lookups — is documented openly as an optimization target rather than hidden. The post also outlines a reproducible benchmarking checklist emphasizing behavior correctness gates, server-side memory measurement, isolated data, and publishing regressions alongside wins.
Table of contents
TeneficGames / podiumQuickstartStart with the correctness contractCompare representations, not just commitsBenchmark operations separatelyMeasure Redis memory, not only Go allocationsWhat the direct comparison showedThen measure through the real APIThe uncomfortable result was the most valuableReproducibility is a featureWhat we learnedQuestions this post answers
How much more Redis memory does a deterministic tie-break leaderboard use compared to a plain sorted set?
A production deterministic tie-break design using two sorted sets, a sequence counter, and a public-ID hash uses approximately 287 Redis bytes per member, compared to about 99 bytes per member for a plain sorted-set baseline — roughly a 3x increase. The exact ratio varies with member length, Redis version, allocator, and dataset cardinality, but the capacity impact is material. Teams sizing Redis capacity for fair leaderboards track tradeoffs like this on daily.dev.
What latency overhead does adding deterministic tie-breaking add to Redis leaderboard write operations?
Deterministic tie-breaking adds approximately 11% latency overhead for insert-and-return-rank, 17% for change-score-and-return-rank, and only 5% for unchanged score submissions. Read operations are nearly unaffected: single rank lookup adds about 1% and top-50 reads add about 3%. The write cost comes from the Lua script updating two sorted sets, a hash, and a sequence counter atomically. Developers shipping leaderboard features weigh write vs. read tradeoffs like these on daily.dev.
Why is bulk rank lookup slow when using encoded members in a Redis leaderboard?
With encoded internal members, bulk rank lookups cannot query ranks using public IDs directly. Each public ID must first be resolved to an internal token, then the score, rank, and optional TTL are read. A Lua script returns aligned triples per member to preserve missing-member positions and atomic read semantics. For 501-member requests, this extra resolution work produced approximately 78% slower performance compared to the pre-tie-break implementation. Developers optimizing Redis leaderboard bulk reads find related deep-dives on daily.dev.