// the find
etcd-io/etcd
Distributed reliable key-value store for the most critical data of a distributed system
etcd is the distributed key-value store that Kubernetes uses to hold its entire cluster state. It implements Raft consensus directly, which means it trades write throughput for strong consistency guarantees — every read is linearizable by default. If you're building anything that needs distributed locking, leader election, or configuration that multiple processes must agree on, this is the reference implementation.
The Raft implementation is its own standalone module (etcd-io/raft), cleanly separated from the server code — you can embed just the consensus layer without the full server. The concurrency package ships distributed primitives (mutex, election, STM) built on top of etcd's own primitives, saving you from rolling your own. The robustness test suite is unusually serious — they run Antithesis fault injection in CI, not just unit tests. The v3 API uses gRPC with a well-typed protobuf surface; the watch stream is a single multiplexed connection rather than a poll loop.
10,000 writes/sec is the benchmark ceiling, not a floor — in practice you'll hit it faster than you expect under bursty load, and there's no sharding story. The storage backend is still bbolt (a single BoltDB file), which means compaction pauses are real and you need to tune compaction aggressively in production or the db file grows without bound. The v2 API is fully removed but some tooling and docs still reference it, which creates confusion when onboarding. Watch event history is bounded by the compaction window — if your consumer falls too far behind, it gets a compacted revision error and has to do a full re-list, which is a footgun for slow or intermittent consumers.