Cloud Native 15 min read

What Is etcd? Features, Use Cases, and Comparison with Zookeeper

This article explains the distributed key‑value store etcd, its origin, core characteristics such as simplicity, security, speed and Raft‑based reliability, and details eight practical scenarios—including service discovery, pub/sub, load balancing, distributed locks and leader election—while also comparing it with Zookeeper.

Architecture Digest
Architecture Digest
Architecture Digest
What Is etcd? Features, Use Cases, and Comparison with Zookeeper

etcd (pronounced /ˈɛtsiːdiː/) stands for "distributed etc directory" and serves as a reliable, distributed key‑value store for critical configuration data in large distributed systems.

The official description calls it "a distributed, reliable key‑value store for the most critical data of a distributed system," emphasizing its role as a coordination service that stores a small amount of data fully in memory.

Inspired by Zookeeper and doozer, etcd offers four main advantages: simple HTTP+JSON API, optional SSL client authentication, high write throughput (about 1,000 writes per second per instance), and strong consistency via the Raft algorithm.

etcd has become popular through projects like CoreOS and Kubernetes, addressing the need for fast, transparent service registration, configuration discovery, and high‑availability clusters in cloud‑native environments.

Application scenarios:

Service discovery: registers services with TTL keys, monitors health via watchers, and enables dynamic service addition in micro‑service architectures.

Message publish/subscribe: stores configuration and metadata, uses watchers for real‑time updates, and supports distributed logging and search index coordination.

Load balancing: leverages etcd’s distributed architecture to store small, frequently accessed data such as secondary code tables and to maintain node status tables for round‑robin routing.

Distributed notification & coordination: uses watchers to implement low‑coupling heartbeat detection, system scheduling, and work progress reporting.

Distributed lock: provides atomic CompareAndSwap operations with prevExist and ordered keys via POST to implement exclusive locks and sequencing.

Distributed queue: creates FIFO queues under directories like /queue and uses a /queue/condition node to control execution based on custom conditions.

Cluster monitoring & leader election: employs TTL keys and watchers to detect node health, and uses Raft‑based CAS mechanisms to elect a leader for tasks such as full‑index building.

Why choose etcd over Zookeeper: etcd is simpler to deploy (written in Go, HTTP API), offers built‑in persistence, SSL security, and benefits from rapid development, while Zookeeper suffers from complex deployment, Java‑centric tooling, and slower evolution.

Overall, etcd is a lightweight, reliable, and secure component widely adopted by CoreOS, Kubernetes, Cloud Foundry, and other production systems, making it a valuable tool for modern cloud‑native architectures.

cloud nativeservice discoveryconfiguration managementRaftEtcddistributed key-value store
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.