#24Build a coordination service (ZooKeeper / etcd style)
stub
Raft alone isn't enough. Build the service layer on top of Raft that the rest of your infrastructure depends on: a hierarchical namespace, watches, ephemeral nodes, leases, and the recipe library (locks, leader election, queues) that everyone reimplements badly. Internalize why Kubernetes, Kafka, and Consul all run on something shaped like this.

Build a coordination service (ZooKeeper / etcd style). Raft alone isn't enough. Build the service layer on top of Raft that the rest of your infrastructure depends on: a hierarchical namespace, watches, ephemeral nodes, leases, and the recipe library (locks, leader election, queues) that everyone reimplements badly. Internalize why Kubernetes, Kafka, and Consul all run on something shaped like this.

This problem is a stub. Suggested approaches haven't been authored yet — ask the staff engineer in the right panel for any stage and they'll generate one tuned to your draft.
Reading: Burrows — The Chubby lock service for loosely-coupled distributed systems (OSDI 2006) · Hunt et al. — ZooKeeper: wait-free coordination for Internet-scale systems (USENIX ATC 2010) · Junqueira & Reed — ZAB: A simple totally ordered broadcast protocol (LADIS 2008) · etcd docs — Architecture, gRPC API, watch implementation · ZooKeeper recipes (zookeeper.apache.org/doc/current/recipes.html) · Reed, Junqueira — Apache ZooKeeper (book chapter)
the hierarchical namespace as the API (znodes / keys)
watches: edge-triggered notifications + the missed-update window
ephemeral nodes / leased keys (TTL bound to session)
session and heartbeat — the liveness contract
ZAB (ZooKeeper Atomic Broadcast) vs Raft — same shape, different details
lease-based leader election recipe
distributed lock recipe (and the fencing-token requirement)
membership / discovery recipe
linearizable reads via 'sync' (ZooKeeper) or ReadIndex (etcd)
the configuration-store specialization (etcd) vs general coordination (ZK)
No scenes authored for this problem yet.