LavikWhy capacity and latency collide
Concurrent players determine traffic, but registered players, regions, game modes, and retained seasons determine capacity. Dropping inactive players from memory reduces cost by making the next return or event-driven reactivation more expensive.
A disk-backed serving layer needs to handle those returning players while active sessions continue. Measure bursts of profile hydration, writes from progression events, and ranking reads together; smooth average traffic understates a launch or season reset.
DESIGN FOR THIS DATA PATH
Where Lavik fits
Use Lavik for player profile hashes, cached progression views and seasonal rankings. Values grow on NVMe SSD as the registered population and retained seasons increase. Keep progression events and account balances in their authoritative workflow, and publish the serving views into Lavik.
Best for: Growing retained player context with a durable authoritative source and clear regional or seasonal boundaries.
Design decisions that determine the outcome
Separate serving context from authoritative progression
Cache or materialize profiles with explicit source versions. Keep entitlement, inventory, and balance invariants in their authoritative workflow until equivalent failure semantics are demonstrated. A read-model rebuild must not re-award rewards or double-apply events.
Partition the audience deliberately
Include game, region, and season in the key design when they change semantics. Bound profile/document size and ranking windows. Measure small hot cohorts separately from broad returning-player reads; one global board can behave very differently from many regional boards.
Design the return and rollover paths
Throttle reconstruction after a restart or event launch. Define old-season retention, expiry, and replay order. Verify the actual session and sorted-set command sequences rather than inferring framework compatibility from RESP support.
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 HSET profile:game1:eu:demo42 avatar ranger source_version 18 region eu
redis-cli HMGET profile:game1:eu:demo42 avatar source_version missing_field
redis-cli EXPIRE profile:game1:eu:demo42 1800
redis-cli DEL profile:game1:eu:demo42
redis-cli HMGET profile:game1:eu:demo42 avatar source_versionWhat 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.
Event and reconnect bursts
Replay returning-player loads alongside ongoing progression writes and social/profile reads.
Player-facing tail latency and timeout rates meet the launch budget with controlled origin traffic.
Season transition
Keep prior seasons accessible while new cohorts populate and old data expires.
Rollover fits memory/SSD headroom and does not degrade current-season read/write deadlines.
Projection rebuild
Inject duplicate and reordered events and rebuild the serving state after interruption.
Profiles and ranks agree with authoritative state; rewards and increments are not applied twice.
Begin with player context in one region. Rehearse reconnect spikes, season rollover and view rebuilds before extending the rollout to more games or regions.
Translate business scale into capacity
Value payload ≈ retained players × context bytes × game/region variants; size ranked members separately
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 →