What You Will Learn

• What is Service Discovery?
• Why Service Discovery is Needed
• Static vs Dynamic Service URLs
• Service Registry
• Eureka Server
• Client-Side Discovery
• Server-Side Discovery
• Kubernetes Service Discovery
• Load Balancing
• Spring Boot Implementation
• Enterprise Architecture
• Interview Questions

---

Introduction

In Monolithic Applications:

Application

↓

Single Server

↓

Single URL

Simple.

---

Microservices Environment

Example:

User Service

Order Service

Payment Service

Inventory Service

Notification Service

Each service runs:

Multiple Instances

Across Multiple Servers

Question:

How does Order Service

find Payment Service?

---

Traditional Approach

Hardcode URL:

http://payment-service:8080

Problem:

Instance Changed

Server Restarted

Container Recreated

URL Changed

Application breaks.

---

What is Service Discovery?

Service Discovery automatically finds service locations at runtime.

Instead of:

Hardcoded URLs

Use:

Service Registry

---

Purpose of Service Discovery

Primary Goal:

Automatically Locate

Available Services

---

Without Service Discovery

flowchart LR

A[Order Service]

B[Payment Service URL]

A --> B

Hardcoded dependency.

---

Problems Without Discovery

Manual Configuration

Scaling Difficulties

Container Restarts

Cloud Challenges

---

With Service Discovery

flowchart LR

A[Order Service]

B[Service Registry]

C[Payment Service]

A --> B
B --> C

Dynamic resolution.

---

Real World Analogy

Think about:

Mobile Contacts App

You call:

Mom

instead of:

+1-XXX-XXX-XXXX

The Contacts App finds the number.

Service Registry works the same way.

---

Core Components

Service Provider

Service Consumer

Service Registry

---

Service Discovery Architecture

flowchart LR

A[Service Provider]

B[Service Registry]

C[Service Consumer]

A --> B

C --> B

---

How Service Discovery Works

Step 1:

Service Starts

---

Step 2

Registers Itself

---

Step 3

Registry Stores Metadata

---

Step 4

Consumer Requests Service Location

---

Step 5

Registry Returns Address

---

Workflow

flowchart LR

A[Service Startup]

B[Register]

C[Service Registry]

D[Consumer Lookup]

E[Service Call]

A --> B
B --> C

D --> C

C --> E

---

Service Registry

Stores:

Service Name

IP Address

Port

Health Status

---

Registry Example

PAYMENT-SERVICE

10.0.0.10:8080

UP

---

Popular Service Registries

Netflix Eureka

HashiCorp Consul

Apache Zookeeper

Kubernetes DNS

AWS Cloud Map

---

Eureka Architecture

flowchart LR

A[Order Service]

B[Eureka Server]

C[Payment Service]

D[User Service]

A --> B

C --> B

D --> B

---

Eureka Registration Flow

flowchart LR

A[Payment Service]

B[Eureka Server]

A --> B

Registers itself.

---

Eureka Lookup Flow

flowchart LR

A[Order Service]

B[Eureka Server]

C[Payment Service]

A --> B
B --> C

Discovers location dynamically.

---

Spring Eureka Dependency

<dependency>
    <groupId>
        org.springframework.cloud
    </groupId>

    <artifactId>
        spring-cloud-starter-netflix-eureka-client
    </artifactId>
</dependency>

---

Eureka Client Configuration

spring:
  application:
    name: PAYMENT-SERVICE

eureka:
  client:
    service-url:
      defaultZone:
        http://localhost:8761/eureka

---

Eureka Server Configuration

@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {
}

---

Registration Example

Service starts:

PAYMENT-SERVICE

Registry stores:

PAYMENT-SERVICE

192.168.1.10

8080

---

Client Side Discovery

Client asks registry.

Client decides:

Which Instance To Call

---

Client Side Discovery Architecture

flowchart LR

A[Order Service]

B[Eureka]

C[Payment-1]

D[Payment-2]

A --> B

A --> C
A --> D

---

Benefits

Smart Clients

Load Balancing

Flexible Routing

---

Server Side Discovery

Client calls:

Load Balancer

Load Balancer asks registry.

---

Server Side Discovery Architecture

flowchart LR

A[Client]

B[Load Balancer]

C[Registry]

D[Payment Service]

A --> B

B --> C

C --> D

---

Popular Server Side Examples

AWS ELB

Kubernetes Service

NGINX

API Gateway

---

Load Balancing

Multiple instances:

Payment-1

Payment-2

Payment-3

Traffic distributed automatically.

---

Load Balancing Flow

flowchart LR

A[Order Service]

B[Registry]

C[Payment-1]

D[Payment-2]

E[Payment-3]

A --> B

B --> C
B --> D
B --> E

---

Health Checks

Registry continuously verifies:

Service Is Alive

---

Health Check Flow

flowchart LR

A[Service]

B[Heartbeat]

C[Registry]

A --> B
B --> C

---

If Service Crashes

Heartbeat stops.

Registry marks:

DOWN

Consumers stop using it.

---

Kubernetes Service Discovery

Most modern systems use:

Kubernetes DNS

instead of Eureka.

---

Kubernetes Example

Service Name:

payment-service

Consumers call:

http://payment-service

DNS resolves automatically.

---

Kubernetes Architecture

flowchart LR

A[Order Pod]

B[Kubernetes DNS]

C[Payment Pods]

A --> B
B --> C

---

Banking Example

Fund Transfer Workflow:

Transfer Service

↓

Account Service

↓

Fraud Service

↓

Notification Service

Each discovered dynamically.

---

Banking Architecture

flowchart LR

A[Transfer Service]

B[Service Registry]

C[Account Service]

D[Fraud Service]

A --> B

B --> C
B --> D

---

Insurance Example

Claim Processing.

Services:

Policy Service

Claim Service

Payment Service

Discovery handled automatically.

---

Insurance Flow

flowchart LR

A[Claim Service]

B[Registry]

C[Policy Service]

D[Payment Service]

A --> B

B --> C
B --> D

---

Retail Example

Order Processing:

Order Service

Inventory Service

Payment Service

Shipping Service

---

Retail Architecture

flowchart LR

A[Order Service]

B[Registry]

C[Inventory]

D[Payment]

E[Shipping]

A --> B

B --> C
B --> D
B --> E

---

Service Discovery + API Gateway

Most enterprise systems use both.

---

Combined Architecture

flowchart LR

A[Client]

B[API Gateway]

C[Service Registry]

D[Services]

A --> B

B --> C

C --> D

---

Service Discovery + Load Balancer

flowchart LR

A[Client]

B[Load Balancer]

C[Registry]

D[Service Instances]

A --> B

B --> C

C --> D

---

Eureka vs Kubernetes

Feature	Eureka	Kubernetes
Service Registry	Yes	DNS
Spring Native	Excellent	Good
Cloud Native	Medium	Excellent
Popular Today	Medium	Very High

---

Service Discovery vs API Gateway

Service Discovery	API Gateway
Finds Services	Routes Requests
Internal Usage	External Usage
Dynamic Lookup	Single Entry Point

---

Enterprise Use Cases

Banking

Payments

Transfers

Fraud Detection

---

Insurance

Claims

Policies

Premium Services

---

Retail

Orders

Inventory

Shipping

---

Healthcare

Patients

Appointments

Billing

---

Travel

Flights

Hotels

Payments

---

Real Enterprise Architecture

flowchart LR

A[Mobile App]

B[Web App]

C[API Gateway]

D[Service Registry]

E[User Service]

F[Order Service]

G[Payment Service]

H[Notification Service]

A --> C
B --> C

C --> D

D --> E
D --> F
D --> G
D --> H

---

Benefits

✅ Dynamic Service Lookup

✅ No Hardcoded URLs

✅ Automatic Scaling Support

✅ Health Monitoring

✅ Load Balancing

✅ Cloud Native Friendly

✅ Reduced Configuration

---

Limitations

❌ Additional Infrastructure

❌ Registry Dependency

❌ Network Complexity

---

When To Use Service Discovery

Use when:

Microservices

Containers

Kubernetes

Cloud Native Applications

---

When NOT To Use

Avoid when:

Simple Monolith

Single Server Applications

---

Interview Questions

What is Service Discovery?

A mechanism that automatically locates service instances at runtime.

---

Why Use Service Discovery?

To avoid hardcoded service URLs.

---

What is Eureka?

A Netflix Service Registry.

---

Client Side Discovery?

Client queries registry directly.

---

Server Side Discovery?

Load balancer queries registry.

---

Kubernetes Discovery?

Uses built-in DNS.

---

Biggest Benefit?

Automatic service location.

---

Biggest Drawback?

Additional infrastructure.

---

Key Takeaways

• Service Discovery eliminates hardcoded service URLs.
• Uses a Service Registry to locate services dynamically.
• Popular implementations include Eureka, Consul, and Kubernetes DNS.
• Supports auto-scaling and fault tolerance.
• Often combined with API Gateway and Load Balancers.
• Essential for Microservices and Cloud Native Architectures.
• Widely used in Banking, Insurance, Retail, Healthcare, and Enterprise Systems.

---