Three machines do not mean three copies of application data
Lavik’s October 15, 2026 blog post models 300 Redis VMs against two Lavik Data VMs plus a Meta-only voter. In that vendor model, the Data hosts also run Meta members, so there are three Meta votes but only two application data copies. That is a model comparison, not proof of a production 300-to-3 migration. It also uses a separate benchmark setup: a single-server comparison without Data replicas, with Redis/Valkey persistence off in the reported comparison. The capacity-cost model and benchmark therefore use different VM setups, so read them as separate artifacts, not one unified result.
Keep the model, release and lab separate
The consolidation post is dated October 15, 2026; the 0.2.0 release announcement is dated October 22. Use matching release documentation when planning a trial. An older model, a newer binary and a different benchmark configuration should not silently become one set of promises.
Lavik’s 0.2.0 HA guide starts with three Meta voters and two Data processes on one host; losing that host stops the lab. Its separate-host layout puts the two Data processes on different hosts and the third Meta voter on another. Two votes form a Meta majority. Data replication is asynchronous, so automatic failover does not guarantee zero lost writes. The lab’s settings are separate from benchmark settings.
Write down what each machine holds
Start an evaluation sheet with four counts: physical hosts, Meta voters, application data copies and independent failure domains. Beside each host, record the state it holds and the consequence of losing it. Keep control-plane participation separate from the ability to recover customer records.
For a hypothetical review, imagine someone adds a voter-only machine to a drawing and labels the deployment “three copies.” Correct the drawing before sizing storage or discussing recovery. A useful follow-up question is which surviving machine would actually supply the application’s records after a failure.
Set acceptable lost-write and restoration-time targets before the rehearsal. Then measure representative commands, key and value distributions, retention behavior and growth with replication active. Record application latency, errors and reconnect behavior during load and failure drills. Keep trial data isolated from production. A capacity estimate cannot answer those availability questions by itself.
Make cutover and rollback part of the evidence
The 0.2.0 migration guide uses RedisShake 4.6.2 and a fresh managed target. It calls for initial copying, live-write forwarding, a final source-write pause and verification of catch-up, replicas and data before switching clients. Key counts and sampled reads alone are insufficient. Once Lavik accepts new writes, returning to the source requires reconciling those writes; the procedure does not supply automatic reverse replication.
Prepare a decision record containing the proposed topology, held state, workload, latency and recovery targets, observed evidence, unresolved questions and rollback owner. Preserve failed runs as well as successful ones. If a requirement remains untested, label it as unknown rather than treating a smaller node count as an answer.
The useful outcome is a decision about one workload and deployment. No migration, benchmark or failover was independently performed for this guide. Use the linked procedures for the full conditions and operational steps rather than treating this overview as an executable runbook.
Additional primary sources
Lavik blog: 300 Redis nodes to 3 Lavik nodes
