How Nacos Keeps Working When Its Server Fails – 5 Must‑Know Q&A

1. Configuration read and service calls when Nacos server is unavailable

During microservice startup, the Nacos client pulls configuration data and service registration information from the Nacos server and stores them in two places: an in‑memory cache and a local file (e.g., dataId files under ~/.nacos). If the server later becomes unreachable, the client continues to serve read‑only operations—retrieving configuration values and performing remote‑service calls using the cached information. However, any write‑side operation such as registering a new instance, deregistering, or publishing a new configuration will fail because it requires a live server.

2. Mechanism for dynamic configuration updates

Nacos implements a long‑polling (also called “watch”) mechanism:

When a microservice starts, it registers the data identifiers it cares about (namespace, group, dataId) with the server.

The client then opens a persistent HTTP long‑poll request to the server. The request blocks until the server detects a change or a timeout occurs (default 30 s).

When a configuration change is committed, the server immediately wakes the pending request, pushes the new content (JSON/YAML) in the response, and the client updates its local cache and notifies the application via Listener callbacks.

The client re‑issues the long‑poll request to continue watching.

This design provides near‑real‑time propagation without requiring the client to poll at a fixed interval.

3. Where Nacos stores configuration data

Configuration is persisted in two layers:

In‑memory replica : Every node in a Nacos cluster holds a full copy of the configuration data, enabling fast read access and fault tolerance.

Database backend : Nacos supports an embedded Derby database for single‑node development or testing, and an external MySQL (or MariaDB) instance for production clusters. The database provides durability and enables cluster‑wide consistency for write operations.

When a node starts, it loads the persisted data from the database into its memory replica.

4. CAP‑theorem perspective: service discovery vs. configuration center

Service discovery (AP) – The primary requirement is high availability. During a network partition, the system must continue to accept registration and discovery requests so that services can still locate each other. Temporary inconsistencies (e.g., a subset of nodes missing the latest instance list) are tolerable because they are resolved quickly by heartbeat and retry mechanisms.

Configuration center (CP) – Strong consistency is mandatory because configuration values often contain critical business parameters (database URLs, rate‑limit thresholds, API keys, etc.). An inconsistent view could cause severe logical errors. Therefore Nacos sacrifices some availability (writes may be rejected during a partition) to guarantee that all nodes see the same configuration.

5. Why Nacos supports both Distro and Raft protocols

The two protocols address the different consistency/availability trade‑offs identified above:

Distro protocol – A leader‑less, decentralized protocol used for service discovery. All nodes are equal; any node can handle registration and lookup requests. Because there is no single leader, the system remains available even if some nodes fail, matching the AP model.

Raft protocol – A classic leader‑based consensus algorithm used for the configuration center. One node is elected as the leader; all write requests must pass through the leader and be replicated to a majority of followers before being committed. This ensures strong consistency (CP) at the cost of reduced availability during leader election or network splits.

By combining Distro for discovery and Raft for configuration, Nacos provides a unified architecture that satisfies both high‑availability and strong‑consistency requirements.