etcd.

Phase 5 built Raft (5.5-5.6) as an algorithm. This phase asks a different question for six articles running: what does it actually take to turn that algorithm into a system people build real infrastructure on? etcd — CoreOS's (now part of the CNCF) distributed key-value store — is the cleanest place to start, because it's a comparatively thin, direct wrapping of Raft into a genuinely useful storage API, and because it's the system underlying Kubernetes (article 8.5 gives that specific relationship its own full treatment). This article covers etcd's data model, its watch mechanism (arguably its single most distinctive feature beyond "Raft plus a KV store"), leases, and the linearizable-vs-serializable read distinction that directly cashes out article 3.4's lease theory into a real, documented API choice.

Raft as the replication core, barely modified

etcd's consensus layer is close to a textbook implementation of the Raft algorithm this series built in detail across articles 5.5-5.6 — leader election via RequestVote, log replication via AppendEntries, the same safety guarantees (Election Safety, Log Matching, Leader Completeness, State Machine Safety). This is a deliberate design choice worth noting explicitly: etcd's engineering effort is concentrated almost entirely in the storage and API layers built on top of Raft, not in modifying the consensus algorithm itself — a useful confirmation that a well-understood, well-tested classical algorithm (Phase 5) is often exactly the right foundation for production systems, rather than something that needs to be replaced with a more exotic modern-Paxos-family variant (Phase 7) by default.

MVCC: the storage layer underneath the KV API

etcd stores data using Multi-Version Concurrency Control — every write creates a new, immutable revision rather than overwriting the previous value in place, and etcd retains (subject to configurable compaction) the full history of revisions for every key. This isn't just an implementation detail; it's the structural foundation that makes etcd's most distinctive feature, watches, possible at all.

Watches: streaming changes from a point in history

A client can watch a key or key range starting from a specific revision, and etcd streams every subsequent change to that range as it's committed through Raft — a live, ordered feed of modifications, not just point-in-time reads. Because of MVCC's revision history, a client can even specify a past revision to start watching from, catching up on everything that happened since a specific point rather than only seeing changes from "now" forward — directly useful for a client that was disconnected and needs to know exactly what it missed, without racing a full re-read of current state against new incoming changes.

Leases: TTL-based coordination primitives

etcd's lease mechanism directly generalizes article 3.4's lease concept from a read-optimization technique into a first-class, client-facing coordination primitive: a client attaches a lease (with a time-to-live) to one or more keys, and must periodically renew it (a heartbeat, echoing article 2.4's failure-detection pattern) to keep those keys alive. If the client stops renewing — because it crashed, or lost network connectivity — the lease expires and etcd automatically deletes the associated keys. This is exactly the mechanism Kubernetes uses for leader election among controller replicas and for service liveness registration (a service "holds" a lease key; if it dies, the key disappears and other components notice via a watch) — a direct, practical application of article 3.4's clock-skew-aware safety margins to real cluster coordination.

Linearizable vs. serializable reads: article 3.4's trade-off, as an actual API flag

etcd exposes exactly the read-consistency trade-off article 3.4 built up theoretically, as a literal client-facing option: a linearizable read (the default) goes through the full Raft-backed guarantee — the leader confirms its leadership is still current (via a round of heartbeats, or the lease-based optimization article 3.4 covered) before answering, guaranteeing the absolute latest committed value. A serializable read instead answers directly from whichever node received the request, without that confirmation round-trip — faster and cheaper, but able to return slightly stale data if that node is a follower that hasn't yet caught up to the very latest committed entry.

FAQ

Takeaways

• etcd wraps a close-to-textbook Raft implementation (Phase 5) with minimal modification — its real engineering investment is in the storage/API layers on top, not the consensus algorithm itself.
• MVCC (immutable, versioned revisions per key) is the structural foundation that makes etcd's watch mechanism possible — a live, precisely-resumable feed of changes, not just point-in-time polling.
• Leases generalize article 3.4's theoretical lease concept into a first-class, client-facing TTL coordination primitive — the mechanism behind Kubernetes leader election and liveness registration.
• Linearizable vs. serializable reads is article 3.4's read-consistency trade-off exposed directly as an API choice — a satisfying, concrete payoff for that earlier theoretical article.
• Opens Phase 8 by demonstrating the pattern this phase will repeat: a well-understood classical algorithm (Raft, Zab) wrapped in real storage/API engineering is usually the actual production answer, more often than a specialized Phase 7 variant.

References & further reading

• etcd documentation — API Reference — watches, leases, and the linearizable/serializable read modes described directly.
• Ongaro & Ousterhout — In Search of an Understandable Consensus Algorithm (Raft, 2014) — the algorithm etcd implements; full treatment in articles 5.5-5.6.
• cvam.sight — Consensus 3.4: Leases and Linearizable Reads — the theory this article's read-mode API directly implements.