Eureka in Microservices Architecture (Netflix)

What is Eureka?

• Eureka is a service registry used in microservices architecture.

• It allows microservices to register themselves and discover other services for inter-service
communication.

• It is essential for communication between microservices.

Why Use Eureka?

1. Service Registration: Each microservice registers itself with Eureka by providing metadata
(like hostname, port, etc.).

2. Service Discovery: Microservices use Eureka to discover the addresses of other services they
need to communicate with.

3. Heartbeat Monitoring: Eureka monitors the health of each registered service through
periodic heartbeat messages.

4. Fault Tolerance: If a service does not send a heartbeat for a set period, Eureka removes it
from the registry.

How Eureka Works?

1. Eureka Server: The central registry where all services are registered.

2. Eureka Clients:

o These are the microservices that register with the Eureka Server.

o They periodically renew their registration by sending heartbeat messages.

o If a service stops sending heartbeats, it is considered down, and Eureka removes it

from the registry.

Steps for Using Eureka in a Spring Boot Project:

1. Add Dependencies (Gradle):

groovy

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'

2. Start the Eureka Server:

o Configure your Spring Boot application to act as a Eureka Server.

o When it runs, it starts listening on a specific port (default is http://localhost:8761/).

 3. Start Eureka Clients (Microservices):

o Each microservice should register with the Eureka Server on startup.

o You can view all registered services on the Eureka Dashboard (available at
http://localhost:8761).

Eureka Server Communication Workflow (From the Diagram):

• Multiple Eureka Servers (e.g., in different regions or zones like us-east-1c, us-east-1d)
replicate data with each other.

• Application Clients register with one of the Eureka Servers and periodically fetch the registry
to communicate with other services.

• Services communicate with each other using the addresses retrieved from the Eureka
registry.
Server Application:

Client Application:
API Gateway in Microservices Architecture
What is an API Gateway?

• An API Gateway acts as a single entry point for all client requests in a microservices system.

• Instead of having clients interact with multiple services directly, the API Gateway routes,
manages, and aggregates requests to the appropriate backend services.

• It simplifies the system for both the client and the developers, making it easier to manage
and scale.

Why Use an API Gateway?

1. Single Entry Point:

o The client only interacts with one endpoint (API Gateway), rather than multiple
endpoints for each service.

o This makes communication between the frontend (web app, mobile app) and
backend services less complex.

2. Routing Requests:

o The gateway routes incoming requests to the appropriate microservice, based on

the type of request.

o Example:

▪ Requests to /users go to the user service.

▪ Requests to /products go to the product service.

3. Aggregation:

o If the client request requires data from multiple services, the gateway collects
responses from these services and returns a combined response to the client.

o Example: A product detail page might need product information, reviews, and user
details.

4. Transformation:

o The gateway can transform requests and responses (e.g., converting data formats or
adding/removing headers) to ensure smooth communication between clients and
services.

How API Gateways Work:

1. The Client Sends a Request:

o A web or mobile app sends a request to the API Gateway.

2. API Gateway Routes the Request:

 o It determines which backend service should handle the request based on:

▪ URL path (e.g., /users, /orders).

▪ HTTP method (e.g., GET, POST).

▪ Headers (e.g., X-Region).

▪ Query parameters (e.g., /search?type=product).

3. The Service Processes the Request:

o The API Gateway forwards the request to the correct service (e.g., user accounts,
orders).

o It collects the service’s response or aggregates data from multiple services if

needed.

4. The Gateway Returns the Response to the Client:

o After receiving the responses from services, it sends the final response back to the
client.

API Gateway Features:

1. Path-Based Routing:

o Routes requests based on the URL path.

o Example:

▪ /users/** → User service

▪ /products/** → Product service

2. Method-Based Routing:

o Routes requests based on the HTTP method (GET, POST, PUT, DELETE).

o Example:

▪ GET /orders → Fetch orders

▪ POST /orders → Create a new order

3. Header-Based Routing:

o Uses HTTP headers to route requests.

o Example:

▪ Header X-Region: Asia → Route to an Asia-specific service.

4. Parameter-Based Routing:

o Routes based on query parameters in the URL.

o Example:
 ▪ /search?type=product → Product search service

▪ /search?type=user → User search service

Benefits of Using an API Gateway

• Simplifies Client Interaction: Clients only need to know about one endpoint instead of
multiple.

• Centralized Authentication & Authorization: The gateway can enforce security policies (like
authentication) at a single point.

• Load Balancing: Distributes traffic across multiple instances of services.

• Fault Handling & Caching: The gateway can manage timeouts, retries, and cache responses
to improve performance.

• Service Versioning: Supports multiple versions of APIs and routes traffic accordingly.

Example Scenario of an API Gateway

Imagine an online store with the following services:

• User Account Service: Handles user registrations and profiles.

• Product Service: Provides product details.

• Order Service: Manages customer orders.

Without an API Gateway:

• The client (web app or mobile app) must directly interact with each service, which can be
complex.

With an API Gateway:

1. The client only communicates with the API Gateway.

2. The API Gateway determines which service should handle each request.

3. If a request needs data from multiple services (like user and product details), the gateway
gathers the data and sends a combined response to the client.
What is Zuul?
• Zuul is an API Gateway developed by Netflix as part of its microservices ecosystem.

• It acts as a reverse proxy and routing layer, directing client requests to the appropriate
backend services.

• Zuul simplifies communication between external clients (like web apps or mobile apps) and
multiple microservices.

Key Features of Zuul:

1. Routing:

o Routes requests to the correct service based on paths, methods, headers, or query
parameters.

o Example: /api/products routes to the product service.

2. Load Balancing:

o Works with Ribbon (another Netflix library) to distribute incoming traffic across
multiple instances of a service.

3. Authentication and Security:

o Can enforce authentication rules and filter requests to ensure security.

4. Filters for Custom Logic:

o Supports pre-filters (executed before routing), post-filters (executed after routing),

and error filters (in case of failures) to customize request handling.

5. Fault Tolerance:

o Works with Hystrix (Netflix’s circuit breaker) to provide fault tolerance by handling
failed requests gracefully.

How Zuul Works:

1. Client sends a request to Zuul.

2. Zuul routes the request to the appropriate microservice.

3. Optional filters are applied before and after the request.

4. Response is returned to the client through Zuul.