LavikWhy capacity and latency collide
Audience profiles, segment snapshots, creative metadata, and campaign variants grow with reachable users and retention, not just impressions per second. A small memory hot set may not capture the next burst of identities or an expanded campaign audience.
The deadline is unforgiving: a context read that arrives after the decision is useless even if it succeeds. SSD capacity is valuable only when the qualifying workload delivers enough useful responses on time. Record late responses and fallback decisions, not just server QPS.
DESIGN FOR THIS DATA PATH
Where Lavik fits
Use Lavik for profile payloads, campaign snapshots and enrichment records on the decision path. Its billion-key SPDK benchmark delivers 652,881 GET QPS at 0.943 ms p99.9 with 320 connections. That is a concrete starting point for a load test using your own fan-out, record sizes and decision deadline.
Best for: High-cardinality, reconstructable enrichment payload with measured per-request latency headroom.
Design decisions that determine the outcome
Budget the decision, not one GET
Subtract network, fan-out, decoding, model/scoring, and downstream time from the total deadline. Use bounded batches where their semantics fit. Define what a missing or late profile means before load testing; do not hide deadline misses inside client retries.
Separate payload serving from contended counters
Profile lookups and per-event budget/frequency updates have different contention and correctness needs. Use idempotency keys and test retries for counters; keep cross-key budget enforcement explicit in the application.
Propagate change and deletion deliberately
Version audience and campaign records in application publishers, bound freshness, and test explicit invalidation across serving copies. Cache TTL is a retention tool; it does not by itself implement your application's consent, suppression, or deletion workflow.
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 audience:v2:demo42 "{\"segments\":[\"outdoor\"],\"version\":2}" EX 120
redis-cli SET campaign:v4:demo7 "{\"creative\":\"banner7\",\"version\":4}" EX 120
redis-cli MGET audience:v2:demo42 campaign:v4:demo7
redis-cli DEL audience:v2:demo42
redis-cli MGET audience:v2:demo42 audience:v2:missingWhat 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.
Deadline-constrained lookup load
Use an arrival-rate-controlled generator and the real fan-out, payload sizes, and cold-key fraction.
Useful responses before the deadline meet the target; queues and retry traffic remain bounded.
Audience expansion and churn
Grow the keyspace and rotate active cohorts while publishers update records.
Decision p99/p99.9, fallback rate, and freshness remain acceptable across transitions.
Counter and invalidation correctness
Test the exact update scripts, retries, duplicates, and deletion propagation used by the application.
Business invariants hold independently of the successful profile-read benchmark.
Set a store-service budget inside the end-to-end decision deadline. Track late responses and fallbacks, and reserve capacity for audience changes and campaign launches.
Translate business scale into capacity
Value payload ≈ retained identities × profile bytes + campaign/context snapshots
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 →