Eureka

Eureka implements a client-side discovery pattern. Each service client (consumer) embeds the Eureka client library, which is responsible for:

• Querying the Eureka server registry to obtain a list of available service instances.
• Using a load-balancing algorithm (like round-robin) to select an instance.
• Making direct HTTP/REST calls to the chosen instance. This pattern decentralizes discovery logic but requires a client library in each service.

For high availability, Eureka servers can be deployed in a peer-to-peer cluster. Servers replicate service instance registrations among themselves.

• Each server is a peer to others; there is no master node.
• Registrations are replicated to all peer nodes.
• If a server fails, others continue to operate, preserving the registry state. This architecture provides resilience without a single point of failure for the registry itself.

Service instances register with Eureka on startup and must renew a lease to stay registered.

• Registration: An instance sends a POST request to the Eureka server with its metadata (host, port, health indicator).
• Renewal (Heartbeat): Every 30 seconds (default), the instance sends a renewal request. This heartbeat signals the instance is healthy.
• Eviction: If a server doesn't receive a renewal within 90 seconds (default), it evicts the instance from the registry, treating it as unavailable.

A critical resilience feature that protects the registry in a network partition scenario. If a significant number of instances (e.g., >15%) fail to renew their leases within a window, Eureka assumes a network issue and enters self-preservation mode.

• It stops evicting instances that have expired.
• The registry data is frozen, potentially serving stale instances.
• This prevents a cascading failure where all services are deregistered due to a transient network problem.
• The mode exits once renewals return to the expected threshold.

Eureka supports deployment across multiple zones (like AWS Availability Zones) and regions for geographic redundancy.

• Service instances are registered with a zone metadata attribute.
• The Eureka client can be configured to prefer discovering services within the same zone to minimize latency and cross-zone traffic costs.
• If instances are unavailable in the local zone, the client fails over to other zones. This supports sophisticated, cloud-aware deployment topologies.

Eureka is a foundational component of the Spring Cloud Netflix stack. Integration is seamless:

• The @EnableEurekaServer annotation turns a Spring Boot app into a Eureka server.
• The @EnableDiscoveryClient annotation (or @EnableEurekaClient) configures a service as a Eureka client.
• Spring's RestTemplate or WebClient can be automatically configured for client-side load balancing using Ribbon (or Spring Cloud LoadBalancer) integrated with Eureka service discovery.

A service registry is a centralized or decentralized database that tracks the network locations and metadata of available agents or services in a distributed system. It is the foundational component that discovery mechanisms query.

• Acts as the 'phone book' for a microservices architecture.
• Stores entries with key attributes: service name, host, port, health status, and metadata.
• Can be AP-based (high availability, like Eureka) or CP-based (strong consistency, like etcd).

Service discovery is the process by which an agent or client dynamically finds the network endpoint of another agent or service it needs to communicate with. It relies on a service registry.

• Two primary patterns exist:
  • Client-Side Discovery: The consumer queries the registry directly and selects an instance (Eureka's native pattern).
  • Server-Side Discovery: A router/load balancer queries the registry on the client's behalf.
• Eliminates hard-coded hostnames and ports, enabling dynamic scaling and fault tolerance.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It abstracts service discovery, load balancing, and security into a network of proxies.

• Implements server-side discovery transparently. The mesh's data plane (e.g., Envoy Proxy) handles registry queries.
• Tools like Istio and Linkerd can integrate with registries like Eureka or Consul, or manage their own service catalog.
• Represents an evolution from library-based (Eureka client) to platform-based discovery.

A health check is a probe to verify an agent's operational status. A heartbeat is a periodic signal to indicate liveness. Both are critical for registry accuracy.

• Eureka clients send heartbeats (renewals) every 30 seconds by default.
• If heartbeats stop, the server waits a configurable period (e.g., 90s) before evicting the instance.
• Additional application-level health checks (/health endpoints) can provide deeper status beyond simple process liveness.