WORKLOAD PATTERN

More seasons. More cohorts. A different capacity equation.

For Redis sorted-set workloads accumulating ranked members across games, communities, tenants, and time windows. Evaluate Lavik's sorted-set operations with the real board geometry and update contention.

v0.1.0-beta.1Redis / ValkeyNVMe SSD

Why 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

Lavik exposes tested sorted-set command examples through the Redis protocol and stores data through its storage engine. Treat many independent, moderately sized boards as an initial evaluation shape. Measure the complete memory footprint; the string-value benchmark does not quantify sorted-set bytes per member or rank-update throughput.

REQUEST PATHRanking / leaderboard APIRedis-compatible client
LavikDRAM · key indexNVMe SSD · value storage
Application-managed refresh / projections from: Score event log + application replay worker

Strongest evaluation fit: A growing portfolio of retained boards with clear cohort boundaries and replayable source events.

Design decisions that determine the outcome

01

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.

02

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.

03

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.

A command example executed on Lavik

Docker check passed

A functional check using example data, an isolated instance, and actual replies. It verifies the command sequence shown; it is not a performance or end-to-end correctness test of the industry workload.

Inspect actual requests and replies
> ZADD board:season7:eu 100 alice 120 bob 90 carol
3

> ZINCRBY board:season7:eu 30 alice
"130"

> ZREVRANGE board:season7:eu 0 1 WITHSCORES
["alice","130","bob","120"]

> ZREVRANK board:season7:eu alice
0

> EXPIRE board:season7:eu 3600
1
Version and verification scope

lavik 0.1.0-beta.1 · Minimal package · aarch64 · 2026-09-21

Offline container with a read-only root, temporary data, and a reset between scenarios. Examples use an authenticated local connection. TTL ranges and exact arguments are preserved in the execution receipt.

Execution receipt
Start a local instance

What 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.

Accept when

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.

Accept when

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.

Accept when

Usable capacity and memory stay within budget without disrupting live board latency.

The verified example proves a small command sequence, not million-member performance, tournament correctness, or queue/framework compatibility. Calculate sorted-set capacity from measurements instead of applying the 1 KiB string benchmark directly.

Translate business scale into capacity

Retained members ≈ members per board × cohorts × seasons; measure bytes per member

20×

lower value-capacity cost

When DRAM costs 20 times as much per GiB as NVMe SSD, the same value payload costs one twentieth as much for media capacity: 95% less. Include index memory, CPU, replicas, storage amplification, and recovery headroom in the complete deployment.

Calculate with your capacity prices