LAVIK / BLOG
Explore architecture at Lavik.
FEATURED · IN DEPTH
Why keep buying servers for RAM? Lavik combines NVMe SSD capacity with throughput above Redis on DRAM. Explore the architecture, benchmarks and economics of a 300-to-3 consolidation.
Read the article
An NVMe-backed activity history can outgrow RAM while its API still returns small pages. Evaluate Redis client compatibility at the response boundary: decoding, range semantics, cancellation, and slow consumers.
A hypothetical image-processing queue shows why replay retention, pending deliveries, and physical storage need separate budgets—and how Lavik’s NVMe-backed Streams support that design.
A catalog refresh must remove obsolete fields as well as update values. Use that application contract to guide a first Lavik evaluation, with package and storage choices supporting the design.
A packed timeline cache shows how Lavik’s NVMe values and segmented Strings can support larger objects while keeping selected reads and updates local.
Our first stable release brings Redis-compatible storage on NVMe SSD, 8 KiB segments for large strings, improved collections, bundled Lavik Admin, and a more capable managed deployment.
Keep your Redis client while moving value capacity to NVMe SSD. Choose the right routing mode, initialize pooled connections consistently, and size concurrency for the application.
A growing Lavik cache needs a capacity budget per worker as well as per server. A hypothetical uneven key distribution shows why spare NVMe space and aggregate memory headroom may not admit the next key.
A storage quote becomes useful only after accounting for replicas, physical overhead, index memory, and room to rebuild. Compare configurations that meet the same operating requirements.
Minimal and Standard define different deployment prerequisites. Start with the package that answers your first evaluation question, then treat SPDK as a separate experiment.
Moving reconstructable session context to SSD changes the capacity budget. TTL visibility, index removal, physical reclamation, and authoritative login state still need separate decisions.
Growing cached objects changes more than capacity. A hypothetical payload expansion shows how Lavik shifts pressure toward response bytes, replacement writes, and storage reclamation.
A practical compatibility checklist for Lavik: verify replies, connection state, errors, and what your client does when the first attempt has no clear outcome.
A worked capacity model shows why moving values to NVMe changes the budget without removing index memory, reclamation headroom, or shared server costs.
Key ownership makes local work efficient. Multi-key commands need a separate design for scheduling, lock lifetime, command errors, and durable completion.
Lavik’s control-plane decisions distinguish a planned handoff from owner loss. Follow the state transitions that prevent stale preparation and observations from becoming authority.
Lavik treats a shutdown checkpoint as a one-use recovery accelerator. Its publication, consumption, and fallback rules are the substance of the design.
Large hashes, lists, sets, and sorted sets need more than a place to store one giant value. Lavik uses collection-specific routing and atomic graph publication.
An SSD-backed Redis interface needs more than asynchronous reads. Follow a request through connection state, admission, partition ownership, and reply backpressure.
Lavik tracks native replication by history and logical flow. Understand what an acknowledgement proves, what a restart discards, and why failover needs additional evidence.
A function library must become consistent across workers, survive restart, and travel through replication. Lavik stages complete catalogs before making them visible.
Follow the ownership, append, read, and reclamation decisions behind a value store that can grow beyond DRAM capacity.
Lavik