LavikWhy capacity and latency collide
Daily active users do not describe the retained dataset. Mobile devices reconnect, users keep multiple sessions, and profile documents accumulate preferences and application state. Extending retention can grow stored bytes without a corresponding increase in peak QPS.
In-memory capacity makes this retained context expensive. With disk-backed alternatives, a reconnect storm can move cold profiles directly onto the critical request path. The relevant metric is the login or resume experience at the tail, including backend fallback and retries.
DESIGN FOR THIS DATA PATH
Where Lavik fits
Put profile attributes and application session context in Lavik, while your identity service remains responsible for authentication and revocation. Keep your current key conventions and TTL policy. The capacity benefit grows with profile size, device count and the history you choose to retain.
Best for: Substantial retained user-context payload with an existing authoritative source and a bounded reconstruction path.
Design decisions that determine the outcome
Separate context from authentication authority
Decide which fields can be rebuilt or served stale and which must be rejected when unavailable. A missing cached preference can fall back to a profile service; a missing or stale revocation record must follow the authentication design's explicit failure policy.
Keep expiry and logout testable
Distinguish absolute expiry from sliding inactivity expiry. Exercise the exact SET options used for refresh, explicit DEL on logout, and concurrent device updates. Storage-level TTL alone does not implement your full session lifecycle.
Avoid turning profiles into hot locks
Bound record size and update granularity; isolate tenant and schema identifiers in keys. Keep large context updates from sharing a single contended key with tiny critical counters. Measure index memory when the dataset contains many short-lived, small sessions.
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 SET context:tenant1:session42 "{\"user\":\"demo42\",\"theme\":\"dark\"}" EX 900
redis-cli GET context:tenant1:session42
redis-cli TTL context:tenant1:session42
redis-cli DEL context:tenant1:session42
redis-cli GET context:tenant1:session42What 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.
Resume storms
Replay returning-user access after idle periods, deployment restarts, and regional traffic shifts.
Login/resume p99 and timeout rates meet the application target without overloading the authority service.
Expiry and revocation races
Test expiry, refresh, logout, and concurrent reads using the real session library.
No request is authorized by stale or missing state contrary to the defined authentication policy.
Failure and reconstruction
Exercise timeouts, connection loss, restart, and restoration from the authoritative source.
Recovery and fail-closed/fallback behavior are explicitly accepted before storing authoritative sessions.
Migrate profile reads first, then exercise expiry, logout and deletion with the application. Include sessions that are renewed while clients retry.
Translate business scale into capacity
Value payload ≈ retained sessions × context bytes + retained profiles × profile bytes
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 →