Skip to main content

Leaderless Replication: Simplicity Through Redundancy

⚙️ What Is Leaderless Replication?​

Leaderless replication is a distributed database strategy where no single node coordinates all writes. Instead, any node in the system can handle read or write requests independently.

It’s famously used in systems like Amazon’s Dynamo, Cassandra, and Riak — systems designed for high availability, even under network partitions.

📥 How Writes Work​

When a client wants to write data:

  1. It sends the write to N nodes (where N is the replication factor).
  2. The write is considered successful once W nodes acknowledge it.
  3. If some nodes are unavailable, the write may still proceed using a technique called hinted handoff — where another node temporarily stores the write on behalf of the unreachable one.

This makes the system highly available, even during network failures or node outages.

📤 How Reads Work​

When a client wants to read data:

  1. It queries R replicas.
  2. If all replicas agree on the value — the read is successful.
  3. If there's a conflict (some replicas have different versions), the system uses read repair or returns multiple versions ("siblings") for the client to resolve.

🔧 Tunable Consistency​

Leaderless replication allows you to trade between consistency and availability using three tunable parameters:

  • N: Number of replicas
  • W: Number of write acknowledgments required
  • R: Number of replicas to read from

To ensure strong consistency, choose values such that:

W + R > N

But you can tune for availability instead:

  • W = 1, R = 1 → Fast and available, but eventually consistent
  • W = N, R = N → Stronger consistency, but slower and less resilient

🧠 Conflict Resolution: The Simple Way, Last Write Wins (LWW)​

Since any node can accept writes, conflicts can happen. One simple way to resolve them?

Add a monotonic integer version field to each record.

{
  "user_id": 123,
  "email": "a@example.com",
  "version": 42
}

When reading from multiple replicas, just pick the record with the highest version. This lets you reconcile changes through read repair..

¹ You can also use timestamps (e.g., updated_at), but they rely on synchronized clocks. See footnote for comparison.

🔁 Read Repair​

Read repair is a clever consistency mechanism used in leaderless systems.

If a read operation detects that some replicas are stale, it writes the latest value back to them automatically — during the read!

For example:

  • A client reads from 3 nodes.
  • Two return version = 42, one returns version = 37.
  • The client or coordinator writes version = 42 back to the stale node.

This ensures data converges over time, without requiring background repair jobs or strict coordination.

Benefits:

  • Keeps replicas in sync as a side effect of reads
  • Reduces future inconsistency for frequently read keys

Limitations:

  • Cold (unread) replicas can remain stale
  • Background processes like anti-entropy or Merkle tree-based repair may still be needed

🔽 Footnote: Timestamps vs Integers for Versioning​

FactorTimestamps (updated_at)Integers (version)
Human-readable✅ Yes❌ No
Requires clock sync❌ Yes✅ No
Monotonicity guaranteed❌ No (needs NTP)✅ Yes (if app-enforced)
Deterministic resolution⚠️ Maybe✅ Always
Implementation overhead✅ Simple⚠️ Requires version tracking

👉 Use integers when you need reliable, deterministic resolution. 👉 Use timestamps when simplicity is more important than precision.

🔄 Beyond LWW: Enter CRDTs​

For more complex state (e.g., counters, sets, collaborative edits), conflict resolution isn't just about which value is "newer" — it's about merging changes meaningfully.

CRDTs (Conflict-free Replicated Data Types) are data structures designed to converge automatically, no matter the order of operations or the number of replicas.

Examples:

  • G-Counter: Merge-only incrementing counter
  • OR-Set: Add/remove elements with guaranteed convergence
  • RGA/WOOT: For collaborative text editing

They require more design up front but eliminate entire classes of bugs in collaborative, replicated, or offline-first systems. Check out the full article on CRDTs here

🧠 Takeaway​

Leaderless replication is a powerful technique when:

  • Availability and partition tolerance are critical
  • Writes can’t afford to be bottlenecked by a central leader
  • You’re willing to handle consistency at the application level

It trades strict order for flexibility, and lets real-world systems keep running — even when things go wrong.

Comments

No comments yet. Be the first!