When to Use Ephemeral vs Persistent Nacos Instances to Prevent Outages

During a pre‑holiday release, a payment service failure was traced to a misconfiguration: the payment-service was registered in Nacos with ephemeral=false, turning it into a persistent instance. A node with a memory leak blocked heartbeats for over 30 seconds, but because the instance was persistent, Nacos did not remove it, causing the entire payment chain to collapse.

Fundamental Difference Between Service Registry and Configuration Center

Nacos provides both a service registry and a configuration center, each designed for different goals. The registry prioritises high availability (AP) for service discovery, tolerating brief inconsistencies, while the configuration centre requires strong consistency (CP) to ensure configurations are never lost and updates are synchronised across all nodes.

In short, a registry instance is a live service node, whereas a configuration instance is a static configuration file.

Nature : Registry – running service node (e.g., user-service); Config centre – static config data unit (e.g., redis-dev.yml).

Core role : Registry – provides service discovery; Config centre – centralises configuration with dynamic updates.

Creation : Registry – client auto‑registers on startup; Config centre – manually created via console/API or pushed by code.

Lifecycle dependency : Registry – tied to the node’s runtime (node crash = instance invalid); Config centre – persists until manually deleted.

Service Registry: Default Temporary Instances

The registry’s core requirement is real‑time awareness of service availability. Nacos therefore offers two modes: temporary (ephemeral) and persistent instances.

Temporary Instances

Temporary instances are Nacos’s default mode. When services like Spring Cloud or Dubbo start, they register as temporary instances unless explicitly configured otherwise. The mechanism relies on heartbeat signals to verify health.

Heartbeat: client sends a heartbeat every 5 seconds; if the server misses 15 seconds it marks the instance unhealthy, and after 30 seconds it removes the instance.

Storage: instance data lives only in server memory; after a Nacos restart all temporary instances disappear and must re‑register.

Failure behaviour: if a node crashes, loses network, or blocks heartbeats (e.g., due to GC), the instance is automatically removed, preventing routing to an invalid node.

Persistent Instances

Persistent instances are the opposite; they are intended for long‑running, rarely changing foundational services such as MySQL, Redis, or Elasticsearch. The server actively probes the service and persists instance data.

Health‑check: no client heartbeat required; Nacos actively probes (TCP, HTTP, or custom protocols).

Storage: instance information is persisted to Nacos’s database (Derby by default, MySQL in production), surviving server restarts.

Failure behaviour: a crashed instance is marked unhealthy but not deleted, allowing operators to see the faulty node in the console and recover it.

In a Spring Cloud project, switching the instance type is as simple as adding a line in application.yml:

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.1.100:8848
        ephemeral: false  # should be true (default) for dynamic services

Configuration Center: Default Persistent

All configuration instances in Nacos’s configuration centre are persistent; there is no concept of temporary configuration. The centre’s purpose is to centrally manage configuration and prevent loss.

Storage: every configuration (whether created via console or API) is persisted to a database (e.g., MySQL), surviving server restarts or crashes.

Lifecycle: configurations are only removed or overwritten manually; they do not disappear when a client disconnects.

Dynamic updates: clients poll for changes (default every 30 seconds, configurable) and receive updates within about a second, but this is not the same as temporary existence.

Key Takeaways

Service Registry: use temporary (ephemeral) instances for dynamic business services (payment, order) and persistent instances for static infrastructure components (MySQL, Redis).

Configuration Center: all configurations are persistent by default; dynamic updates do not imply temporary storage.