Coordinating multi-key work across Lavik partitions
Key ownership makes local work efficient. Multi-key commands need a separate design for scheduling, lock lifetime, command errors, and durable completion.
LAVIK / BLOG
Architecture
Explore architecture at Lavik.
Failover needs intent, authority, and evidence
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.
Fast restart begins with knowing when an index is stale
Lavik treats a shutdown checkpoint as a one-use recovery accelerator. Its publication, consumption, and fallback rules are the substance of the design.
How grouped collections change the cost of large Redis values
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.
How Lavik keeps requests moving while storage waits
An SSD-backed Redis interface needs more than asynchronous reads. Follow a request through connection state, admission, partition ownership, and reply backpressure.
Replication progress is more than one offset
Lavik tracks native replication by history and logical flow. Understand what an acknowledgement proves, what a restart discards, and why failover needs additional evidence.
Why a Lua function catalog is a storage problem
A function library must become consistent across workers, survive restart, and travel through replication. Lavik stages complete catalogs before making them visible.
Why Lavik separates its memory index from SSD values
Follow the ownership, append, read, and reclamation decisions behind a value store that can grow beyond DRAM capacity.