Discovery, architecture, and quorum | Consul: discovery, mesh, and operations

Concept and mechanism

Consul locates services where instances appear, disappear, and change addresses. The catalog maintains registrations and known state while consumers query endpoints through interfaces such as DNS or API. Discovery does not encrypt connections or by itself confirm business outcomes. Service mesh adds proxies and policies to the data path; network automation can use catalog changes to reconcile infrastructure. Draw these responsibilities separately. Servers maintain state and consensus; client agents communicate local state and participate in membership without becoming Raft voters. Consul Dataplane supports workloads on compatible platforms and should not be confused with a consensus server.

Guided application

In a fictional banking design, three or five servers are a starting point to assess against requirements and documentation. Five stable voters need three communicating votes; three need two. Moving from three to four raises quorum but still tolerates only one failure. Do not count client agents in that calculation. The leader coordinates state changes rather than forwarding every application payment. Across datacenters, each location maintains its own catalog; federation does not mean a complete copy of every service at every location. The PM should request dependency diagrams, failure domains, and recovery evidence including the effect of remote unavailability.

IN PRACTICE

Five voters, two unavailable: another shutdown removes the required majority.

Common pitfalls

Clients as votes; catalog as proxy; more servers as linear write scaling.

Related topics: Deployment and bootstrap · Registration, health checks, and DNS · Mesh, identity, and intentions

Take this idea with you

Distinguish control state, application traffic, and voting majority.

Create account

Reference: Consul architecture · Historical Consul Associate (003), retired 2026-07-15; technical references inspected 2026-09-30