RECIPE / CONSISTENCY

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.