Consul concepts

This topic outlines a conceptual model for understanding Consul’s underlying operations.

Catalog

Consul tracks information about registered services through its Catalog API. This API records user-defined information about the external services, such as their partitions and required health checks. It also records information that Consul assigns for its own operations, such as an ID for each service instance and the Raft indices when the instance is registered and modified.

For more information about the Consul catalog and the information it registers, refer to Catalog.

Consensus

To reconcile discrepancies in catalog information between server agents, servers use the Raft protocol to participate in a process called consensus.

In consensus, each server agent begins as a follower. Followers elect a leader, who keeps the authoritative records of cluster events as log entries in the Raft index. The server agents maintain a quorum about which node is the current leader. Quorum size depends on the number of voting servers in the cluster.

Clusters regularly hold elections to select new leaders in response to certain cluster events. To learn more about this process, refer to Consensus.

Consistency

Consul distinguishes between the global service catalog and the agent's local state. Agents forward information about services and health checks to the cluster’s leader, which replicates the authoritative catalog to other server nodes. This can result in nodes having different catalog information at a given moment, which is an intentional part of Consul’s design. To keep results consistent, Consul’s anti-entropy mechanism periodically synchronizes the local agent state with the catalog.

Refer to consistency for more information.

Consistency modes

When you query the Consul catalog, the agent forwards the request to the cluster's leader by default and then returns the most recent authoritative results. You can change a Consul agent's consistency mode to balance between accuracy and latency, depending on your networking needs. Strongly consistent results give the highest accuracy but may increase latency, while returning results from the local agent can reduce latency but may lead to stale data.

Refer to consistency modes for more information.

Gossip

Consul implements a gossip protocol called Serf for datacenter operations. Consul enables a LAN gossip pool by default, which allows it to communicate with all nodes in a datacenter to share membership information. This pool supports automatic server discovery, failure detection, and reliable event broadcasts, operating on port 8301 by default. Gossip between servers is secured by an encryption key that should rotate periodically using Consul’s HTTP API and CLI.

Refer to gossip for more information.

Reliability

Fault tolerance allows the system to continue operating even if some components fail. In Consul, the number of server agents determines the cluster’s quorum and fault tolerance. We recommend deploying Consul clusters with 3 or 5 voting server agents for optimal fault tolerance and performance. Strategies like deploying server agents across availability zones can further improve fault tolerance, while Consul Enterprise offers additional features for large-scale automated operations.

Refer to reliability for more information.