Practice: Consistency models, transactions and consensus in plain words
Generated by Claude through GigAI (karthik446/gigai-learning-center 4c0cb514) on 2026-10-13.
Main tool: etcd · etcd is a small single-binary Raft store that runs as a three-member cluster on a laptop, so linearizable reads, revisions, quorum loss, leases and locks can all be observed directly instead of only read about. · Alternatives: ZooKeeper offers the same coordination primitives through ephemeral znodes and its own Zab protocol, with a heavier JVM footprint; Consul bundles a Raft key-value store with service discovery and health checks; CockroachDB and Spanner put consensus under full SQL transactions with serializable isolation; PostgreSQL gives rich isolation levels on a single primary without built-in consensus.
Every step links into the tool's own documentation; links were checked on 2026-10-13 · version 1
Setup (one time)
1. Install the etcd server and the etcdctl client from a release archive and confirm both report the same version.
Every later item is driven through etcdctl against a local server, and the reading guide lists exactly what must be in place first.
Explained in: Reading from etcd | etcd (etcd.io), checked 2026-10-13
Done when: Asking etcd and etcdctl for their version prints matching v3 version numbers.
2. Start the three-member demo etcd cluster on your laptop, each member with its own name, data directory and ports.
Consensus and quorum only become visible with several members; a single node hides every interesting failure.
Explained in: How to Set Up a Demo etcd Cluster | etcd (etcd.io), checked 2026-10-13
Done when: The member list shows three started members and endpoint status shows exactly one leader.
3. Open the latest documentation landing page and confirm it matches the version you installed.
Flags and behaviour differ between minor versions, so following the wrong version of the docs wastes time.
Explained in: latest | etcd (etcd.io), checked 2026-10-13
Done when: The version shown in the docs matches the version printed by your etcd binary.
Steps
1. Write your first key and value to the cluster with etcdctl put.
A write is the smallest operation that must go through the Raft leader and be accepted by a majority before it is acknowledged.
Explained in: Writing to etcd | etcd (etcd.io), checked 2026-10-13
Done when: The client prints OK and the same key can be written again with a new value.
2. Read the key back, then read a whole key prefix, and print one result in JSON output so the header and key metadata are visible.
The core object model of etcd is a flat key space where every key carries a create revision, a mod revision and a version, all under one cluster-wide revision counter.
Explained in: Reading from etcd | etcd (etcd.io), checked 2026-10-13
Done when: You can point at the cluster revision, the create revision, the mod revision and the version of your key in the output.
3. Write the same key several more times, then read it at an older revision while a second terminal keeps writing new values.
This is the subtopic on transactions and isolation levels: multi-version storage lets a reader see one consistent snapshot, which is the mechanism behind snapshot and serializable isolation and behind compare-and-swap on a revision.
Explained in: Reading from etcd | etcd (etcd.io), checked 2026-10-13
Done when: A read pinned to an old revision keeps returning the old value while an unpinned read returns the newest one.
4. Compare a linearizable read with a serializable read of one key, sending each to a single follower endpoint.
This is the consistency-model subtopic: a linearizable read is confirmed through the quorum and never goes back in time, while a serializable read is answered from the local member and may be stale, which is the etcd version of the strong-to-eventual spectrum.
Explained in: Benchmarking etcd v3 | etcd (etcd.io), checked 2026-10-13
Done when: You can state which read mode is the default, which one is faster, and which one could return an old value.
5. Stop one member of the demo cluster and write a key, then stop a second member and try both a write and the two read modes.
This is the consensus, quorums and Raft subtopic: two of three members form a majority and keep working, one of three cannot commit anything, and only the local serializable read still answers.
Explained in: How to Set Up a Demo etcd Cluster | etcd (etcd.io), checked 2026-10-13
Done when: With two members up the write succeeds, with one member up the write and the linearizable read time out and the serializable read still returns, and restarting a member restores writes.
6. Create a lease with a short time to live, attach a key to it, and let it expire without keeping it alive.
A lease is a time-bounded promise from the cluster; it is how a crashed client loses its claims without anyone cleaning up by hand.
Explained in: How to create lease | etcd (etcd.io), checked 2026-10-13
Done when: The key is readable while the lease lives and disappears on its own after the time to live passes.
7. Create a named lock in one terminal and try to acquire the same lock name from a second terminal.
A distributed lock in etcd is a leased key plus an ordering by revision, so seeing the second client wait shows what the store actually guarantees.
Explained in: How to create locks | etcd (etcd.io), checked 2026-10-13
Done when: The second terminal blocks until the first releases the lock, then prints its own lock key.
8. Configure the lock with a short session time to live, kill the holder process abruptly, and time how long the waiter takes to get the lock.
The lock is only as safe as its lease: a paused or dead holder keeps the lock until the lease runs out, and a paused holder may still believe it owns it afterwards.
Explained in: How to create locks | etcd (etcd.io), checked 2026-10-13
Done when: The waiter acquires the lock roughly one time to live after the kill, and you can explain why a paused holder is dangerous in that window.
9. Query the ownership key that the lock command printed, in JSON output, and record its create revision as a fencing token for two successive holders.
This completes the leases, locks and fencing subtopic: a downstream resource that rejects any request carrying a token lower than the highest it has seen is what makes a lease-based lock safe.
Explained in: Reading from etcd | etcd (etcd.io), checked 2026-10-13
Done when: The second holder has a strictly higher create revision than the first, and you can describe the check the protected resource must perform.
10. Reproduce the storage memory usage benchmark at laptop scale, writing down your own testing environment in the same form the page uses and loading a much smaller number of keys.
A result that names its machine, version and data shape can be rerun by anyone, and it shows how every key and revision costs memory in the index.
Explained in: Storage Memory Usage Benchmark | etcd (etcd.io), checked 2026-10-13
Done when: You have a short note with your environment, key count and measured memory that a colleague could rerun and compare with the published table.
11. Run a rolling upgrade of the three-member cluster, replacing one member binary at a time while a client keeps writing.
Production clusters are changed while serving traffic, and a rolling change only works because the quorum survives one member being down.
Explained in: Upgrading etcd clusters and applications | etcd (etcd.io), checked 2026-10-13
Done when: All three members report the new version, the cluster version has moved up, and the writing client saw no lost acknowledged writes.
12. Run the documented downgrade procedure on the same cluster to return it to the previous minor version, checking health after every member.
A production-like setup needs a tested way back, and downgrading exercises the same quorum and version-agreement rules under more constraints.
Explained in: Downgrading etcd clusters and applications | etcd (etcd.io), checked 2026-10-13
Done when: Every member reports the earlier version, endpoint health is green on all three, and the keys written before the downgrade are still readable.
Back to Consistency models, transactions and consensus in plain words