---

Spring Cloud Service Discovery Interview Questions and Answers

Introduction

In a microservices architecture, services are constantly starting, stopping, scaling, and moving between hosts.

For example:

• Payment Service may run on 10 instances
• Customer Service may scale from 2 to 20 pods
• Kubernetes may recreate failed containers
• Cloud platforms assign dynamic IP addresses

Hardcoding service URLs becomes impossible.

Service Discovery solves this problem by allowing services to dynamically register themselves and discover other services at runtime.

Spring Cloud commonly supports:

• Netflix Eureka
• HashiCorp Consul
• Kubernetes Service Discovery

---

Service Discovery Architecture

flowchart LR

CustomerService --> EurekaServer

PaymentService --> EurekaServer

LoanService --> EurekaServer

NotificationService --> EurekaServer

CustomerService --> PaymentService

CustomerService --> LoanService

---

Q1. What is Service Discovery?

Answer

Service Discovery is the mechanism that allows microservices to locate and communicate with each other without using hardcoded IP addresses or URLs.

Instead of calling

http://192.168.10.12:8081

a service calls

http://payment-service

The Discovery Server resolves the service name to a running instance.

Benefits

• Dynamic discovery
• High availability
• Automatic scaling
• Fault tolerance

---

Q2. What is Eureka?

Eureka is Netflix's Service Registry that is widely used with Spring Cloud.

Components

• Eureka Server
• Eureka Client

Responsibilities

• Register services
• Discover services
• Maintain registry
• Perform health checks

Eureka Architecture

flowchart TD

EurekaServer --> CustomerService

EurekaServer --> PaymentService

EurekaServer --> LoanService

CustomerService --> PaymentService

---

Q3. What is Eureka Server?

Eureka Server maintains the registry of all running services.

Dependency

<dependency>

<groupId>

org.springframework.cloud

</groupId>

<artifactId>

spring-cloud-starter-netflix-eureka-server

</artifactId>

</dependency>

Enable Server

@EnableEurekaServer

@SpringBootApplication

public class

DiscoveryServer{

}

The Eureka dashboard displays all registered services.

---

Q4. What is Eureka Client?

Each microservice registers itself with Eureka.

Dependency

<dependency>

<artifactId>

spring-cloud-starter-netflix-eureka-client

</artifactId>

</dependency>

Configuration

eureka:

  client:

    service-url:

      defaultZone:

        http://localhost:8761/eureka

The service automatically registers when it starts.

---

Q5. How does Service Registration work?

Startup Process

1. Service starts.
2. Reads configuration.
3. Connects to Eureka.
4. Registers itself.
5. Sends heartbeats periodically.

Registration Flow

sequenceDiagram
Payment Service->>Eureka Server: Register
Eureka Server-->>Payment Service: Registration Success
Payment Service->>Eureka Server: Heartbeat
Payment Service->>Eureka Server: Heartbeat
Payment Service->>Eureka Server: Heartbeat

---

Q6. What are Heartbeats?

Heartbeats inform Eureka that the service is alive.

If heartbeats stop,

the service is removed from the registry after the lease expires.

Heartbeat Flow

flowchart LR

Service --> Heartbeat

Heartbeat --> Eureka

Heartbeat --> Eureka

Heartbeat --> Eureka

NoHeartbeat --> RemoveInstance

This prevents requests from being routed to unavailable services.

---

Q7. How does Service Discovery work?

When Service A wants to call Payment Service:

1. Query Eureka.
2. Get available instances.
3. Select one instance.
4. Send request.

Discovery Flow

sequenceDiagram
Customer Service->>Eureka: Find Payment Service
Eureka-->>Customer Service: payment-service:8082
Customer Service->>Payment Service: HTTP Request
Payment Service-->>Customer Service: Response

No hardcoded URLs are required.

---

Q8. How does Load Balancing work?

If multiple instances exist,

Spring Cloud LoadBalancer selects one.

Example

Payment Service

↓

8081

↓

8082

↓

8083

Load Balancing

flowchart LR

CustomerService --> LoadBalancer

LoadBalancer --> Payment8081

LoadBalancer --> Payment8082

LoadBalancer --> Payment8083

This distributes traffic across all healthy instances.

---

Q9. Eureka vs Kubernetes Service Discovery

Eureka	Kubernetes
Application-level discovery	Infrastructure-level discovery
JVM ecosystem	Container ecosystem
Service registry	Kubernetes Services
Heartbeats	Pod health checks
Suitable for VMs	Native for Kubernetes

Today, Kubernetes Service Discovery is often preferred for cloud-native deployments.

---

Q10. Service Discovery Best Practices

Register Every Service

All microservices should register automatically.

---

Avoid Hardcoded URLs

Always use service names.

---

Enable Health Checks

Remove unhealthy instances quickly.

---

Use Load Balancing

Distribute traffic evenly.

---

Monitor Discovery Server

Monitor registrations, heartbeats, and instance health.

---

Banking Example

flowchart TD

CustomerService --> Eureka

PaymentService --> Eureka

LoanService --> Eureka

NotificationService --> Eureka

CustomerService --> LoadBalancer

LoadBalancer --> PaymentService

LoadBalancer --> PaymentServiceReplica

Customer Service automatically discovers healthy Payment Service instances.

---

Common Interview Questions

• What is Service Discovery?
• Why is Eureka needed?
• What is Eureka Server?
• What is Eureka Client?
• How does service registration work?
• What are heartbeats?
• How does service discovery work?
• How does load balancing work?
• Eureka vs Kubernetes?
• Service Discovery best practices?

---

Quick Revision

Topic	Summary
Service Discovery	Dynamic service lookup
Eureka Server	Service registry
Eureka Client	Registers services
Registration	Startup registration
Heartbeat	Health signal
Discovery	Locate service instances
Load Balancer	Select healthy instance
Consul	Alternative registry
Kubernetes	Native service discovery
High Availability	Multiple service instances

---

Service Discovery Lifecycle

sequenceDiagram
Service->>Eureka Server: Register
Eureka Server-->>Service: Success
Client Service->>Eureka Server: Lookup Payment Service
Eureka Server-->>Client Service: Available Instances
Client Service->>LoadBalancer: Select Instance
LoadBalancer->>Payment Service: Request
Payment Service-->>Client Service: Response

---

Production Example – Banking Payment Platform

A banking platform contains multiple microservices:

• Customer Service
• Account Service
• Payment Service
• Loan Service
• Notification Service

Deployment

• Three Payment Service instances run behind a load balancer.
• All services register with Eureka during startup.
• Customer Service requests the Payment Service by service name, not IP address.
• Spring Cloud LoadBalancer distributes traffic across healthy instances.
• If one Payment Service instance crashes, heartbeats stop and Eureka removes it from the registry.
• New requests are automatically routed to the remaining healthy instances.

flowchart LR

CustomerService --> EurekaServer

PaymentService1 --> EurekaServer

PaymentService2 --> EurekaServer

PaymentService3 --> EurekaServer

CustomerService --> SpringCloudLoadBalancer

SpringCloudLoadBalancer --> PaymentService1

SpringCloudLoadBalancer --> PaymentService2

SpringCloudLoadBalancer --> PaymentService3

This architecture enables dynamic scaling, fault tolerance, and seamless service communication without configuration changes.

---

Key Takeaways

• Service Discovery enables microservices to locate each other dynamically without hardcoded network addresses.
• Eureka Server acts as the central service registry, while Eureka Clients automatically register themselves during startup.
• Services periodically send heartbeats to indicate they are healthy; failed instances are removed from the registry.
• Spring Cloud LoadBalancer distributes requests across multiple healthy service instances.
• Service Discovery improves scalability, resilience, and operational flexibility in distributed systems.
• In containerized environments, Kubernetes Service Discovery is commonly used instead of Eureka because it is built into the orchestration platform.
• Avoid hardcoded URLs and always communicate using logical service names.
• A properly configured Service Discovery mechanism is fundamental to building reliable and scalable Spring Cloud microservices.