LavikWhy capacity and latency collide
A SKU is rarely one cached record. Markets, sellers, currencies, fulfillment regions, experiments, and content variants create many serving representations. Evicting the long tail saves DRAM by moving latency and database load onto the first shopper who needs it.
SSD-backed reads must still fit product-page and browse deadlines during a promotion. A disk tier that looks acceptable at average traffic can expose latency when shoppers suddenly spread across a wider catalog and refresh writes compete for I/O.
DESIGN FOR THIS DATA PATH
Where Lavik fits
Materialize catalog and offer snapshots in Lavik, refreshed by your existing commerce pipeline. Retain more seller, market and locale variants without storing every value in DRAM. Browsing services read prepared records; checkout keeps authoritative inventory and price checks in the commerce platform.
Best for: Large, rebuildable commerce read models where catalog coverage and variant count drive memory spend.
Design decisions that determine the outcome
Keep the purchasing authority clear
Use cached price and availability as serving snapshots with explicit versions and freshness rules. Checkout must perform the platform's authoritative price, inventory, and reservation checks. A fast key-value lookup does not implement stock reservation or a payment ledger.
Make key geometry follow the storefront
Include tenant/seller, market, locale, and snapshot version where they change the response. Bound MGET fan-out for a product grid. Store prepared representations when that reduces expensive joins, while measuring duplicated payload against the saved request work.
Make refresh idempotent
Handle duplicate and out-of-order events in the CDC consumer. Use application versions or reconciliations to prevent stale materialization, and spread expirations to avoid synchronized refill. Connect your existing CDC consumer to Lavik through its Redis-compatible interface.
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 offer:t1:eu:sku42:v5 "{\"currency\":\"EUR\",\"display_price\":9900,\"version\":5}" EX 300
redis-cli SET offer:t1:eu:sku43:v5 "{\"currency\":\"EUR\",\"display_price\":7900,\"version\":5}" EX 300
redis-cli MGET offer:t1:eu:sku42:v5 offer:t1:eu:sku43:v5 offer:t1:eu:missing:v5
redis-cli DEL offer:t1:eu:sku42:v5What 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.
Promotion traffic
Replay hot-item spikes and broad catalog discovery while refreshing offers.
Browse/product-page tail latency and origin traffic satisfy the event plan.
Freshness under update lag
Inject duplicate, delayed, and reordered catalog/price events into your consumer.
Visible versions do not regress, and stale snapshots follow the storefront's explicit policy.
Multi-market capacity
Load realistic seller, market, locale, and version combinations; measure payload duplication.
Compare complete serving cost at equal catalog coverage, freshness, and latency targets.
Launch with a catalog partition or market. Compare browse latency, source-database load and freshness through a promotion cycle before expanding coverage.
Translate business scale into capacity
Value payload ≈ SKUs × serving variants × average snapshot bytes × retained versions
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 →