LavikWhy capacity and latency collide
A single top-100 widget can conceal millions of retained members and thousands of concurrent boards. Keeping previous seasons and regional cohorts online multiplies state even when only a small result window is displayed.
Moving that state to disk changes the economics, but point-read QPS says little about rank updates, range retrieval, or a heavily contended board. Tail latency must be measured during score bursts and retention cleanup, not only with an idle dataset.
DESIGN FOR THIS DATA PATH
Where Lavik fits
Use ZADD, ZINCRBY and rank/range reads to build the same leaderboard patterns your Redis application uses. Lavik 0.2.0 groups large collections so operations can work on relevant portions of the stored object. Size by members, boards and retained seasons; measure rank updates and range reads with your actual board sizes.
Best for: A growing portfolio of retained boards with clear cohort boundaries and replayable source events.
Design decisions that determine the outcome
Partition by product meaning
Use season, game, region, or cohort boundaries where the ranking contract permits them. A single hot sorted-set key remains a contention target; adding workers does not automatically distribute one board. Global ranking across separate boards needs application logic.
Define score and retry semantics
Choose between absolute ZADD scores and incremental ZINCRBY updates. Retrying an increment can apply it twice unless the application provides deduplication. Preserve tie ordering, rank direction, and the treatment of disconnected players.
Bound ranges and retention work
Page through bounded ranking windows. Decide whether seasons expire as complete keys or require explicit member pruning, and measure cleanup alongside writes. Keep a replayable score source if ranked state must be reconstructed.
Try this command pattern
Redis-compatible commandsStart Lavik 0.2.0 with the quick start, then use these example keys to try the basic operations. Each command links to its options and return values.
Show example commands
redis-cli ZADD board:season7:eu 100 alice 120 bob 90 carol
redis-cli ZINCRBY board:season7:eu 30 alice
redis-cli ZREVRANGE board:season7:eu 0 1 WITHSCORES
redis-cli ZREVRANK board:season7:eu alice
redis-cli EXPIRE board:season7:eu 3600What should decide the migration?
Write down the application budgets before replaying traffic. Validate these criteria in your own system; published benchmarks are a starting point.
Score bursts on hot boards
Use real board-size distributions and concentration of updates during live events.
Score-update and top-N p99/p99.9 fit the product deadlines with bounded client queues.
Rank and replay correctness
Compare ties, rank direction, pagination, duplicate events, and restart reconstruction.
Ranks match the existing contract and replay does not double-apply score changes.
Season rollover
Retain old boards while creating new cohorts and expiring or pruning old state.
Usable capacity and memory stay within budget without disrupting live board latency.
Benchmark sorted-set operations with your member counts and score-update distribution. The GET/SET reports explain the storage foundation; leaderboard sizing should use ZSET traffic.
Translate business scale into capacity
Retained members ≈ members per board × cohorts × seasons; measure bytes per member
lower value-capacity cost
At a 20:1 DRAM/NVMe SSD price per GiB, the same value capacity costs 95% less in media. Plan the complete budget with your actual prices, index memory and replicas.
Calculate your capacity cost →