Service Registration & Discovery

Service discovery is a critical component in microservices architecture, enabling services to find and communicate with each other dynamically without hard-coded addresses.

Core Concepts

Service Registry Architecture

A service registry maintains a catalog of available services and their instances: Key Information Stored:

IP addresses and ports
Service names and versions
Health status
Metadata (region, tags, capabilities)

Implementation Comparison

Eureka
ZooKeeper
Nacos

Spring Cloud Eureka

Origin: Netflix (now maintained by Spring)CAP Model: AP (Availability + Partition Tolerance)Architecture: Client-Server with peer-to-peer replication

Server Capabilities

Service Registration

Stores service metadata in a unified registry. Clients register on startup.

Registry Table

Provides service lists to clients. Clients cache locally and refresh every 30 seconds.

Service Eviction

Removes instances that haven’t sent heartbeats for 90 seconds (if not in self-preservation).

Self-Preservation

Protects registry during network instability. Doesn’t remove instances if 85% fail heartbeats within 15 minutes.

Client Operations

Operation	Interval	Description
Register	On startup	Sends service info (IP, port, metadata)
Renew (Heartbeat)	Every 30s	HTTP request to confirm health
Fetch Registry	Every 30s	Updates local service cache
Cancel	On shutdown	Gracefully deregisters service

Workflow

Server startup

Eureka Server starts and waits for registrations

Provider registration

Service provider registers with server on startup

Heartbeat mechanism

Provider sends heartbeat every 30 seconds via HTTP

Health monitoring

Server checks if heartbeat missing for 90s:

If less than 85% healthy in 15min → Self-preservation mode
If 85% or more healthy → Evict unhealthy instance

Consumer discovery

Consumer fetches and caches service list, refreshes every 30s

Remote invocation

Consumer calls provider using cached info (default: round-robin via Ribbon)

Graceful shutdown

Provider sends deregister request on shutdown

High Availability Cluster

Cluster Architecture: Peer-to-peer replication

No master/slave distinction
All nodes are equal
Asynchronous data replication
Eventually consistent (AP model)

Resilience: If one node fails:

Clients continue working with cached service lists
Other nodes handle incoming requests
Failed node replicates latest data on recovery

Eureka 2.x Status: The 2.x branch is no longer maintained, but 1.x is actively supported. Spring Cloud uses 1.x and can easily switch to alternatives (ZooKeeper, Consul, Nacos).

Alibaba Nacos

Origin: Alibaba (Released July 2018)CAP Model: Both AP and CP (configurable!)Capabilities: Service registry + Configuration center

Architecture

Nacos combines the best features of Eureka and ZooKeeper:

Service Discovery

Supports HTTP/HTTPS registration
Compatible with RPC frameworks (Dubbo)
Replaces Eureka, ZooKeeper, Consul
Built-in UI dashboard

Configuration Management

Dynamic configuration updates
No restart required
Version control
Replaces Spring Cloud Config + Bus, Apollo

Workflow

Provider registration

Service registers with Nacos server on startup

Heartbeat

Provider sends periodic HTTP heartbeats to prove availability

Health check

Nacos evicts instances that fail to send heartbeats

Consumer subscription

Consumers subscribe with a Listener (push model - recommended)Alternative: Pull model (polling - not recommended)

Change notification

Listener automatically notifies consumer when service list changes

Remote invocation

Consumer uses updated service info to make calls

Load Balancing

Nacos uses Feign for client-side load balancing:

Strategies
Implementation

Round Robin (default)
Weighted Round Robin
IP Hash
Least Connections
Least Connections with Slow Start

// Interface + annotation approach
@FeignClient(name = "service-provider")
public interface ProviderClient {
    @GetMapping("/api/data")
    String getData();
}

Uses JDK dynamic proxy under the hood.

High Availability Cluster

Cluster Requirements:

Minimum: 3 nodes recommended
Storage: MySQL (Derby only for standalone)
Shared database for configuration sync

Scalability Advantage

Performance at Scale

Nacos can handle 100,000+ service instances without performance degradation.Why?

Efficient health check mechanisms
Optimized data structures
Better than Eureka’s full replication model
Better than ZooKeeper’s frequent notifications

Decision Matrix

When to Choose Eureka

✅ Best for:

Spring Cloud microservices
Small to medium service counts (less than 10,000 instances)
Need for high availability
Simple setup requirements

❌ Avoid when:

Need strong consistency guarantees
Massive scale (>10,000 instances)
Require configuration management

When to Choose ZooKeeper

✅ Best for:

Distributed coordination (leader election, locks)
Configuration management
Hadoop/HBase ecosystems
Strong consistency requirements

❌ Avoid when:

Availability is critical
Cannot tolerate 30-120s downtime during elections
Primary use case is service discovery

When to Choose Nacos

✅ Best for:

Large-scale deployments (10,000+ instances)
Need both service discovery AND config management
Want flexible CAP model (switch between AP/CP)
Kubernetes environments
Dubbo or Spring Cloud ecosystems

❌ Avoid when:

Team unfamiliar with Alibaba ecosystem
Simple use cases (overhead not justified)

When to Choose Consul

✅ Best for:

Service Mesh architectures
Multi-datacenter deployments
Need for built-in health checks
HashiCorp ecosystem integration

❌ Avoid when:

Using Java exclusively (Go-based, harder debugging)
Team lacks Go language expertise

Comparison Table

Feature	Eureka	ZooKeeper	Nacos	Consul
CAP Model	AP	CP	AP & CP	CP
Language	Java	Java/C	Java	Go
Health Check	Client heartbeat	Socket keep-alive	HTTP heartbeat	Multiple options
Watch Support	Long polling	Push	Push/Pull	Long polling
Scale Limit	~10K instances	Medium	100K+ instances	Large
UI Dashboard	Basic	None	Rich	Rich
Spring Cloud	Native	Supported	Supported	Supported
Config Center	No	No	Yes	Yes
K8s Integration	Limited	Limited	Excellent	Excellent
Operational Complexity	Low	Medium	Medium	Medium-High

Implementation Example

Eureka Client
Nacos Client

// Provider registration
@SpringBootApplication
@EnableEurekaClient
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
}

# application.yml
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    lease-renewal-interval-in-seconds: 30
    lease-expiration-duration-in-seconds: 90

// Provider registration
@SpringBootApplication
@EnableDiscoveryClient
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
}

# application.yml
spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
        namespace: dev
        group: DEFAULT_GROUP

Design Considerations

Client-Side Caching

Why it matters:

Reduces registry load
Improves performance
Provides fallback during registry outage

Best practices:

Cache service lists locally
Refresh periodically (30s typical)
Handle cache invalidation properly

Network Partitions

Scenarios to handle:

Registry server unreachable
Service instance unreachable
Split-brain in clustered registries

Strategies:

Client-side circuit breakers
Retry with exponential backoff
Use health checks actively

Multi-Datacenter

Considerations:

Cross-region latency
Data consistency across DCs
Failover strategies

Patterns:

Region-aware load balancing
Prefer local services
Registry per datacenter

Security

Protect your registry:

Enable authentication/authorization
Use TLS for communication
Implement rate limiting
Network segmentation

Nacos: Built-in auth Eureka: Add Spring Security

Load Balancing

Learn how to distribute traffic across discovered services

Distributed Systems

Understand broader distributed systems concepts

Java & Spring

Databases

Algorithms & Data Structures

System Design

​Core Concepts

​Service Registry Architecture

​Implementation Comparison

​Spring Cloud Eureka

​Server Capabilities

Service Registration

Registry Table

Service Eviction

Self-Preservation

​Client Operations

​Workflow

​High Availability Cluster

​Apache ZooKeeper

​Core Principles

Tree Structure

​Workflow

​Key Differences from Eureka

CAP Trade-off

Best Use Cases

​Alibaba Nacos

​Architecture

Service Discovery

Configuration Management

​Workflow

​Load Balancing

​High Availability Cluster

​Scalability Advantage

Performance at Scale

​Decision Matrix

​Comparison Table

​Implementation Example

​Design Considerations

Client-Side Caching

Network Partitions

Multi-Datacenter

Security

​Related Topics

Load Balancing

Distributed Systems

Build docs developers (and LLMs) love

Core Concepts

Service Registry Architecture

Implementation Comparison

Spring Cloud Eureka

Server Capabilities

Client Operations

Workflow

High Availability Cluster

Apache ZooKeeper

Core Principles

Workflow

Key Differences from Eureka

Alibaba Nacos

Architecture

Workflow

Load Balancing

High Availability Cluster

Scalability Advantage

Decision Matrix

Comparison Table

Implementation Example

Design Considerations

Related Topics