Quorum Reads and Writes
Tune R, W, and N to trade latency for consistency. This recipe walks through the math behind quorum-based replication in Meridian and shows how to configure per-request consistency without giving up availability during partitions.
01Pick your N, R, W
Meridian replicates every key across N nodes. A write succeeds when W nodes acknowledge it. A read returns once R nodes respond. Strong consistency is guaranteed when R + W > N.
The classic balanced setup is N=3, R=2, W=2. Use N=5, R=3, W=3 if you need to survive two simultaneous node failures while still reading the latest write.
02Configure per-request
Override the cluster default on individual calls. Hot reads can use R=1 for sub-millisecond latency; a follow-up commit can use W=N for a synchronous barrier.
import { Meridian } from '@meridian/client';
const m = new Meridian({ url: process.env.MERIDIAN_URL });
// strong read: 2 of 3
const user = await m.get('user:42', { r: 2 });
// durable write: all replicas ack
await m.put('user:42', user, { w: 3, timeoutMs: 250 });
// eventual read: fastest replica wins
const cached = await m.get('feed:42', { r: 1 });03Handle partitions
When a network split prevents W replicas from acknowledging, Meridian returnsQUORUM_UNAVAILABLE. Catch it and either retry with relaxed W or surface a degraded-write banner to the caller.
Read-repair runs in the background on every quorum read, so stale replicas converge without a manual anti-entropy pass.