etcd — Dependencies#

Module info#

• Module: go.etcd.io/etcd/v3 (root workspace module)
• Go version: 1.26 (toolchain go1.26.1 — cutting-edge)
• Direct dependencies (root go.mod): 21 (includes internal sibling modules)
• Indirect dependencies (root go.sum entries): 214 lines (~107 unique modules, each appears twice)
• Workspace structure: 13 modules in a Go workspace; each has its own go.mod with independent dependency sets

Note on counting: Because etcd is a multi-module workspace, the meaningful dependency count is per-module. The root go.mod is a convenience aggregation. The heaviest module is server/ with ~35 direct dependencies.

Dependency categories#

Core infrastructure#

Networking / RPC#

Data / Storage#

Observability#

Security#

CLI / Terminal#

Testing#

Stdlib reliance#

etcd makes heavy use of the Go standard library. In the server/ module:

• context (101 files): Ubiquitous for cancellation and deadline propagation across gRPC calls and background goroutines.
• time (130 files): Critical for election timeouts, heartbeat intervals, lease TTLs, and session management.
• sync (67 files): Mutex, RWMutex, WaitGroup, Once throughout the server for concurrent state management.
• fmt / errors: Standard error construction; etcd avoids pkg/errors and instead uses stdlib errors + fmt.Errorf %w.
• net/http (45 files): Direct HTTP handler for metrics, health checks, and gRPC-gateway.
• io / bytes: WAL encoding/decoding and snapshot streaming.
• encoding/json (28 files): Serialization for config, watch events, and cluster info.
• path / os: File system access for WAL and snapshot storage.

The project achieves a healthy balance: stdlib handles concurrency, errors, and I/O; third-party handles logging (zap), RPC (grpc/protobuf), and storage (bbolt).

Shared dependencies#

These dependencies are widely used across Go projects and create natural book connection points:

Vendoring#

No vendor directory. etcd uses the module proxy and go.sum checksums for reproducibility. This is the modern approach for projects with strong CI infrastructure; the go.sum file with 214 entries provides integrity guarantees without the disk bloat of vendoring.

Notable dependency decisions#

1. Two protobuf libraries in parallel: etcd imports both google.golang.org/protobuf (modern) and github.com/gogo/protobuf (high-performance). The gogo variant is used for Raft log entries where serialization is on the critical path; the Google variant is used for the API layer. This pragmatic split prioritizes performance in the hot path.

2. Raft as an external module (go.etcd.io/raft/v3): The consensus algorithm — etcd’s most distinctive component — is versioned independently from the server. This enables other projects to embed Raft without taking a dependency on the etcd server. The import count (raftpb 54 times, raft/v3 22 times) shows deep integration.

3. bbolt as the sole storage backend: Unlike databases that abstract over multiple storage engines, etcd commits entirely to bbolt (the maintained fork of BoltDB). The MVCC layer is built on top of bbolt’s B-tree, not behind a pluggable interface. This simplicity-over-flexibility choice reflects etcd’s correctness-first philosophy.

4. OpenTelemetry stack (not Jaeger directly): etcd uses OTel’s vendor-neutral API for tracing, exporting via OTLP. This is a deliberate ecosystem alignment choice — consumers can route traces to any backend without modifying etcd.

5. k8s.io/utils in the cache module: The presence of a Kubernetes utility package in the new client-side cache module directly acknowledges Kubernetes as the primary consumer. This is unusual: most libraries avoid dependencies on their own consumers.

6. go.etcd.io/gofail: etcd maintains its own fault-injection library and uses it in server code. This is a sophisticated testing dependency that enables controlled failure injection in production code paths, underscoring the project’s commitment to robustness testing.

7. Minimal client dependency surface: The client/v3 module has only 9 direct external dependencies (zap, testify, grpc, protobuf, semver, humanize, prometheus, grpc-middleware). This disciplined surface means embedding the etcd client in a Go application adds a manageable transitive dependency tree.