Deployment Topology

Deployment Topology

Single instance vs cluster (Causal Cluster / Fabric) — pick by read scale + RPO.

Why it matters

A causal cluster gives you a leader + followers + read replicas — write at the leader, read at any member.

Going deeper

Topology decision matrix:

Workload profile	Recommended topology
Small DB, internal app, RTO of minutes acceptable	Single instance + backup
Mostly reads, scattered writes, must survive a node failure	Causal cluster (1 leader + 2 followers + N read replicas)
Multi-tenant / multi-DB, queries span tenants	Fabric — a routing layer that fans queries across multiple cluster databases
Write throughput exceeds a single leader's capacity	Re-shard the application (per-tenant DB, per-domain DB) rather than try to scale writes horizontally

Two operational lessons that often surface late:

1. Causal consistency tokens — after a write, pass the returned bookmark on the next read so the user sees their own write, even if the read happens on a follower that hasn't caught up.
2. Quorum sizing — a 3-node cluster tolerates 1 failure; a 5-node tolerates 2. Even numbers (4, 6) give you no extra availability over the next odd number, only extra cost.

A causal cluster is a newsroom.

There is exactly one editor-in-chief (the leader): every story they sign off becomes the canonical version. Several deputy editors (the followers) hold an up-to-date copy of every signed-off story and can answer reader queries. If the editor-in-chief is hit by a bus, one of the deputies is promoted within seconds and the paper keeps publishing.

Read scale comes for free: you can hire as many deputies as you like to handle the reading public. Write scale doesn't — there's still only one editor-in-chief. That's the deal a causal cluster makes, and it's the deal that fits 90% of production workloads.