100 Most Frequently Asked Microservices Interview Questions & Answers
Below is a practical interview-focused guide, especially useful for Senior Java / Spring Boot / Lead Software Engineer roles. The questions progress from fundamentals to architecture, resilience, data, security, observability, deployment, and system design.
1. Microservices Fundamentals
1. What are microservices?
Microservices is an architectural style where an application is divided into small, independently deployable services, with each service responsible for a specific business capability.
Typical characteristics:
- Independent deployment
- Business-capability-oriented services
- Decentralized data ownership
- API-based communication
- Independent scaling
- Fault isolation
- Technology flexibility
2. What are the main characteristics of microservices?
The most important characteristics are:
- Independent deployability
- Loose coupling
- High cohesion
- Autonomous teams
- Independent scalability
- Decentralized data management
- Resilience and fault isolation
- Automated CI/CD
- API-based communication
- Strong observability
3. What are the advantages of microservices?
Key advantages include:
- Independent deployment
- Independent scaling
- Smaller codebases
- Faster development by autonomous teams
- Better fault isolation
- Technology flexibility
- Easier ownership of business domains
4. What are the disadvantages of microservices?
Microservices introduce significant distributed-system complexity:
- Network failures
- Distributed transactions
- Data consistency problems
- Service discovery
- Monitoring complexity
- Deployment complexity
- Increased infrastructure cost
- Debugging across services
- Version compatibility problems
Senior-level answer: Microservices don’t remove complexity—they move complexity from application code into distributed systems and infrastructure.
5. When should you use microservices?
Use microservices when you have a genuine need for:
- Independent scaling
- Independent deployment
- Multiple autonomous teams
- Complex business domains
- Different availability requirements
- Strong service boundaries
Don’t use microservices simply because they are popular.
6. When should you NOT use microservices?
A monolith may be better when:
- The team is small
- The domain is simple
- Requirements change rapidly
- Independent scaling isn’t required
- Operational maturity is low
- Deployment complexity would outweigh benefits
A modular monolith can often be a better starting point.
7. Microservices vs monolith?
| Monolith | Microservices |
|---|---|
| Single deployment | Independent deployments |
| Usually shared database | Database per service |
| Simple communication | Network communication |
| Easier debugging | Distributed tracing required |
| Simple transactions | Distributed transactions |
| Easier operations | More operational complexity |
| Scale entire application | Scale individual services |
8. What is a modular monolith?
A modular monolith is a single deployable application divided into strongly isolated business modules.
For example:
Application
├── Customer
├── Order
├── Payment
└── Shipping
Each module has clear boundaries but everything runs in one process.
It provides many microservice design benefits without distributed-system complexity.
9. What is bounded context?
A bounded context is a clearly defined boundary within which a particular domain model and terminology have a specific meaning.
For example:
Customer Management
|
+-- Customer
Order Management
|
+-- Customer
Billing
|
+-- Account Holder
The word “customer” may mean different things in different contexts.
10. What is Domain-Driven Design (DDD)?
DDD is an approach to software design that models software around business domains and business capabilities.
Important concepts include:
- Entity
- Value Object
- Aggregate
- Repository
- Domain Service
- Bounded Context
- Ubiquitous Language
DDD is particularly useful when defining microservice boundaries.
2. Microservice Design
11. How do you identify microservice boundaries?
Start with:
- Business capabilities
- Bounded contexts
- Domain ownership
- Data ownership
- Team ownership
- Change frequency
- Scaling requirements
Avoid creating services based purely on technical layers.
Bad:
UserController
UserService
UserRepository
Better:
Customer Service
Order Service
Payment Service
Shipping Service
12. What is the Single Responsibility Principle in microservices?
Each service should have a well-defined business responsibility.
However, “small service” does not mean “tiny service.”
A service should be as small as necessary but as large as useful.
13. What is loose coupling?
Loose coupling means services depend on each other’s contracts rather than internal implementation details.
For example:
Order Service
|
| REST API
↓
Payment Service
Order Service shouldn’t know how Payment Service stores transactions internally.
14. What is high cohesion?
High cohesion means the functionality inside a service belongs together from a business perspective.
For example:
Payment Service
├── Payment
├── Refund
├── PaymentMethod
└── Transaction
These concepts naturally belong together.
15. What is the Database-per-Service pattern?
Each microservice owns its database.
Customer Service → Customer DB
Order Service → Order DB
Payment Service → Payment DB
Other services should not directly access that database.
16. Why shouldn’t microservices share a database?
Shared databases create tight coupling.
For example:
Order Service ─┐
Payment Service ├── Shared DB
Customer Service┘
A schema change can affect multiple services.
Database-per-service provides stronger ownership and autonomy.
17. Can microservices share a database?
Technically yes, but it should generally be treated as a transitional or constrained architecture, not the ideal target.
If multiple services directly manipulate the same tables, you lose much of the independence of microservices.
18. What is API composition?
API composition combines data from multiple services.
Client
|
↓
API Composer
/ \
↓ ↓
Order Customer
The composer aggregates responses and returns a single response.
19. What is the Backend-for-Frontend pattern?
BFF provides a dedicated backend for a particular frontend.
Web → Web BFF
Mobile → Mobile BFF
Each BFF can optimize APIs for its client’s requirements.
20. What is an API Gateway?
An API Gateway is a single entry point between clients and backend services.
Typical responsibilities:
- Routing
- Authentication
- Authorization
- Rate limiting
- TLS termination
- Request transformation
- Observability
Example:
Client
|
↓
API Gateway
/ | \
A B C
3. Communication
21. How do microservices communicate?
Two major approaches:
Synchronous:
- REST
- gRPC
Asynchronous:
- Kafka
- RabbitMQ
- AWS SQS/SNS
- Google Pub/Sub
22. REST vs messaging?
REST is usually appropriate when the caller needs an immediate response.
Messaging is useful when:
- Processing can be asynchronous
- Decoupling is important
- High throughput is required
- Temporary service unavailability should be tolerated
23. REST vs gRPC?
| REST | gRPC |
|---|---|
| HTTP/JSON commonly | HTTP/2 + Protobuf |
| Easy browser integration | Excellent service-to-service |
| Human readable | Compact binary |
| Broad ecosystem | Strong contracts |
| Usually simpler | Usually faster |
24. What is synchronous communication?
The caller waits for the response.
Order → Payment
← Response
It creates temporal coupling between services.
25. What is asynchronous communication?
The sender sends a message/event and doesn’t necessarily wait for immediate processing.
Order → Kafka → Payment
This reduces temporal coupling.
26. What is event-driven architecture?
Services communicate primarily through events.
Example:
Order Service
|
OrderCreated
↓
Kafka
/ \
Payment Shipping
Each consumer can independently react to the event.
27. What is an event?
An event represents something that already happened.
Examples:
OrderCreated
PaymentCompleted
CustomerRegistered
ShipmentDispatched
Events are usually expressed in the past tense.
28. Command vs event?
A command asks another component to perform an action.
CreateOrder
ProcessPayment
An event states that something happened.
OrderCreated
PaymentProcessed
29. What is Kafka?
Kafka is a distributed event streaming platform commonly used for:
- Event-driven architecture
- Messaging
- Data pipelines
- Event sourcing
- Streaming analytics
Key concepts include:
- Topic
- Partition
- Producer
- Consumer
- Consumer group
- Offset
30. What is a Kafka consumer group?
A consumer group allows multiple consumers to share the work of processing partitions.
Topic
├── P0 → Consumer A
├── P1 → Consumer B
└── P2 → Consumer C
Within a consumer group, each partition is normally assigned to only one consumer at a time.
4. Service Discovery & Infrastructure
31. What is service discovery?
Service discovery allows services to dynamically find other services.
Instead of:
http://10.20.1.23:8080
a service can use:
http://payment-service
Common approaches include:
- Client-side discovery
- Server-side discovery
- DNS-based discovery
- Kubernetes Services
32. What is client-side service discovery?
The client queries the service registry and selects an instance.
Client
↓
Registry
↓
Instance A/B/C
33. What is server-side service discovery?
The client contacts a load balancer or gateway.
Client
↓
Load Balancer
↓
Service Instance
The infrastructure handles service discovery.
34. What is load balancing?
Load balancing distributes traffic among multiple service instances.
┌─ Service A
Client → LB ─┼─ Service B
└─ Service C
Strategies include:
- Round robin
- Weighted routing
- Least connections
- Hash-based routing
35. What is Kubernetes Service?
A Kubernetes Service provides a stable network endpoint for a group of Pods.
Client
↓
Service
/ | \
Pod Pod Pod
It abstracts changing Pod IP addresses.
36. What is an API Gateway vs Load Balancer?
A load balancer primarily distributes traffic.
An API Gateway provides higher-level API capabilities such as:
- Authentication
- Authorization
- Routing
- Rate limiting
- Transformation
- API policies
37. What is a service mesh?
A service mesh manages service-to-service communication through infrastructure-side proxies.
Examples include:
- Istio
- Linkerd
It can provide:
- mTLS
- Traffic management
- Retries
- Observability
- Policy enforcement
38. What is the sidecar pattern?
A sidecar is a supporting process deployed alongside the application.
Pod
├── Application
└── Sidecar Proxy
The proxy can handle networking concerns without modifying application code.
5. Resilience
39. What is fault tolerance?
Fault tolerance means the system continues operating even when components fail.
Examples:
- Retries
- Timeouts
- Circuit breakers
- Bulkheads
- Fallbacks
- Redundancy
40. What is a timeout?
A timeout limits how long a service waits for another service.
Without timeouts:
A → B → C → D
A failure in D could cause requests to remain blocked for a long time.
41. What is a retry?
A retry attempts an operation again after a transient failure.
Example:
Request
↓
Failure
↓
Retry
↓
Success
Retries should normally be combined with timeouts and backoff.
42. What is exponential backoff?
The delay between retries increases exponentially.
For example:
1 sec
2 sec
4 sec
8 sec
Usually some jitter is added to prevent many clients from retrying simultaneously.
43. When should you NOT retry?
Avoid retries for:
- Validation errors
- Authentication failures
- Authorization failures
- Non-idempotent operations without protection
- Permanent business errors
Retries are primarily useful for transient failures.
44. What is a circuit breaker?
A circuit breaker prevents repeated calls to an unhealthy service.
States:
CLOSED
↓
OPEN
↓
HALF-OPEN
↓
CLOSED
When failures exceed a threshold, the circuit opens and calls fail fast.
45. Why is a circuit breaker important?
Without one:
A → B
A → B
A → B
A → B
...
A failing B can consume A’s threads, connections, and resources.
This can cause cascading failure.
46. What is bulkhead isolation?
Bulkheads isolate resources so one failing dependency doesn’t consume everything.
For example:
Payment calls → Thread Pool A
Customer calls → Thread Pool B
If Payment becomes unavailable, Customer calls can continue.
47. What is cascading failure?
A failure propagates through dependent services.
Service A
↓
Service B
↓
Service C ❌
C fails → B waits → B resources are exhausted → A fails.
48. What is graceful degradation?
The system continues operating with reduced functionality.
For example:
If Recommendation Service is down:
Product page
↓
Recommendations unavailable
↓
Product page still works
49. What is idempotency?
An operation is idempotent if executing it multiple times has the same effect as executing it once.
For example:
PUT /customers/123
can be designed to be idempotent.
Payment processing is more challenging because duplicate requests can cause duplicate charges.
50. How do you implement idempotency for payments?
A common approach is an idempotency key.
POST /payments
Idempotency-Key: ABC123
The server stores the result associated with the key.
Repeated requests with the same key return the existing result instead of creating another payment.
6. Distributed Transactions
51. Why are distributed transactions difficult?
Consider:
Order
↓
Payment
↓
Inventory
↓
Shipping
Each service owns different data.
A traditional ACID transaction cannot easily span all services.
52. What is a distributed transaction?
A transaction involving multiple independent resources or services.
Example:
Order DB
Payment DB
Inventory DB
53. What is the Saga pattern?
Saga breaks a distributed transaction into a sequence of local transactions.
Example:
Create Order
↓
Reserve Inventory
↓
Process Payment
↓
Create Shipment
If something fails, compensating actions are executed.
54. Saga choreography vs orchestration?
Choreography:
Services react to events.
OrderCreated
↓
Inventory
↓
InventoryReserved
↓
Payment
Orchestration:
A central orchestrator controls the workflow.
Saga Orchestrator
/ | \
Order Inventory Payment
55. Which Saga approach is better?
Neither is universally better.
Choreography:
- Less central coordination
- Can become difficult to understand at scale
Orchestration:
- Easier workflow visibility
- Central coordinator adds complexity
For complex business workflows, orchestration is often easier to operate.
56. What is eventual consistency?
Data across services may temporarily differ but eventually converge.
Example:
Order DB: PAID
Inventory DB: RESERVED
Shipping DB: PROCESSING
The system becomes consistent through asynchronous processing.
57. Strong consistency vs eventual consistency?
Strong consistency provides immediate consistency across relevant operations.
Eventual consistency accepts temporary inconsistency in exchange for:
- Availability
- Scalability
- Decoupling
- Performance
58. What is the Outbox Pattern?
The application writes business data and an event record into the same local database transaction.
Transaction
├── Update Order
└── Insert Outbox Event
A separate publisher then sends the event to Kafka.
This prevents the classic dual-write problem.
59. What is the dual-write problem?
Suppose:
DB update → SUCCESS
Kafka publish → FAILURE
Now the database says something happened but no event was published.
The Outbox Pattern addresses this problem.
60. What is CDC?
CDC means Change Data Capture.
It captures database changes and publishes them to downstream systems.
Tools such as Debezium can capture database transaction-log changes and publish events.
7. Spring Boot Microservices
61. How does Spring Boot help build microservices?
Spring Boot provides:
- Embedded servers
- Auto-configuration
- Dependency injection
- Configuration management
- Actuator
- REST support
- Security integration
- Observability support
62. What is Spring Cloud?
Spring Cloud provides tools for distributed systems, including patterns around:
- Configuration
- Service discovery
- Gateway
- Resilience
- Distributed systems integration
The exact components you choose should depend on the deployment platform and architecture.
63. What is Spring Cloud Gateway?
Spring Cloud Gateway is an API gateway implementation based on Spring.
It supports features such as:
- Routing
- Filters
- Authentication integration
- Rate limiting
- Request manipulation
64. What is Spring Boot Actuator?
Actuator exposes operational endpoints.
Examples:
/actuator/health
/actuator/metrics
It is commonly used for:
- Health checks
- Monitoring
- Metrics
- Kubernetes probes
65. What is Resilience4j?
Resilience4j is a lightweight fault-tolerance library for Java.
It provides patterns such as:
- Circuit breaker
- Retry
- Rate limiter
- Bulkhead
- Time limiter
66. How would you implement a circuit breaker in Spring Boot?
Conceptually:
@CircuitBreaker(
name = "paymentService",
fallbackMethod = "fallback"
)
public PaymentResponse pay(PaymentRequest request) {
return paymentClient.pay(request);
}
The exact configuration should define:
- Failure threshold
- Sliding window
- Wait duration
- Timeout
- Retry policy
67. RestTemplate vs WebClient?
RestTemplate is synchronous and blocking.
WebClient supports reactive and non-blocking HTTP communication.
For modern Spring applications, WebClient is generally preferred for reactive/non-blocking workloads.
68. What is OpenFeign?
Spring Cloud OpenFeign provides a declarative HTTP client.
Instead of manually constructing HTTP requests:
@FeignClient(name = "payment-service")
public interface PaymentClient {
@PostMapping("/payments")
PaymentResponse pay(PaymentRequest request);
}
It reduces boilerplate for synchronous service-to-service calls.
69. What is centralized configuration?
Configuration is managed centrally rather than independently duplicated across services.
Examples include:
- Spring Cloud Config
- Kubernetes ConfigMaps/Secrets
- Cloud-native configuration services
70. How should secrets be managed?
Never hard-code secrets:
Java
password = "myPassword123";
Use:
- Kubernetes Secrets
- AWS Secrets Manager
- Azure Key Vault
- Google Secret Manager
- Vault
Secrets should also be rotated and access-controlled.
8. Security
71. How do you secure microservices?
Use multiple layers:
Client
↓
API Gateway
↓
Authentication
↓
Authorization
↓
Service
↓
Database
Typical mechanisms:
- OAuth 2.0
- OpenID Connect
- JWT
- mTLS
- RBAC
- Network policies
- Secrets management
72. Authentication vs authorization?
Authentication:
Who are you?
Authorization:
What are you allowed to do?
For example:
Authentication → Bill is logged in
Authorization → Bill can approve payments
73. What is JWT?
JWT is a signed token containing claims.
Example conceptual structure:
Header.Payload.Signature
It can contain:
sub
roles
exp
iat
The receiving service validates the token’s signature and claims.
74. What are JWT disadvantages?
JWT can introduce:
- Token size
- Revocation complexity
- Stale permissions
- Key rotation requirements
- Risk if tokens are poorly handled
JWT is not automatically more secure simply because it is stateless.
75. What is OAuth 2.0?
OAuth 2.0 is an authorization framework used to delegate access to resources.
Common flows include:
- Authorization Code
- Client Credentials
For service-to-service communication, Client Credentials is commonly relevant.
76. What is mTLS?
Mutual TLS authenticates both sides of a connection.
Service A ←→ Service B
Certificate authentication
It is useful for service-to-service security.
77. What is zero-trust architecture?
Zero Trust assumes that no network location should automatically be trusted.
Every request should be evaluated based on:
- Identity
- Authentication
- Authorization
- Device/workload context
- Policy
78. How do you secure service-to-service communication?
Use combinations of:
- TLS
- mTLS
- OAuth2 access tokens
- Short-lived credentials
- Network policies
- Service identity
- Least privilege
9. Observability
79. What is observability?
Observability is the ability to understand the internal state of a system from its external outputs.
The three classic pillars are:
Logs
Metrics
Traces
80. What is distributed tracing?
Distributed tracing tracks a request across multiple services.
API Gateway
↓
Order
↓
Payment
↓
Inventory
A trace ID connects all these operations.
81. What is correlation ID?
A correlation ID identifies a request across services.
Example:
X-Correlation-ID: abc-123
It allows engineers to search logs belonging to the same request.
82. What is OpenTelemetry?
OpenTelemetry is an open standard and ecosystem for collecting telemetry such as:
- Traces
- Metrics
- Logs
It provides instrumentation and exporters to observability backends.
83. What metrics should you monitor?
Important metrics include:
- Request rate
- Error rate
- Latency
- CPU
- Memory
- Saturation
- Queue depth
- Database connections
- Kafka consumer lag
- Circuit breaker state
A useful starting point is the RED methodology:
- Rate
- Errors
- Duration
84. What is the difference between logs and traces?
Logs describe individual events.
Traces describe the journey of a request through a distributed system.
Example:
Trace
├── Gateway span
├── Order span
├── Payment span
└── Inventory span
85. What is a health check?
A health check tells the platform whether a service is healthy.
Typical categories:
Liveness:
Is the process alive?
Readiness:
Can the service receive traffic?
These distinctions are especially important in Kubernetes.
10. Kubernetes & Deployment
86. Why is Kubernetes commonly used with microservices?
Kubernetes provides capabilities such as:
- Service discovery
- Scheduling
- Scaling
- Self-healing
- Rolling deployments
- Configuration
- Secrets
- Load balancing
87. What is a Kubernetes Pod?
A Pod is the smallest deployable unit in Kubernetes.
A Pod typically contains one application container, although sidecars can also be included.
88. Deployment vs Pod?
A Pod runs containers.
A Deployment manages replicated Pods and provides:
- Rolling updates
- Replica management
- Rollbacks
- Desired-state reconciliation
89. What is horizontal scaling?
Horizontal scaling means adding more instances.
1 instance
↓
3 instances
↓
10 instances
Microservices are often designed to scale horizontally.
90. What is vertical scaling?
Vertical scaling means increasing the resources of an instance.
2 CPU / 4 GB
↓
8 CPU / 16 GB
91. What is blue-green deployment?
Two environments exist:
Blue → Current
Green → New
Traffic is switched from Blue to Green after validation.
Rollback can be relatively fast.
92. What is canary deployment?
A small percentage of traffic is sent to the new version.
95% → v1
5% → v2
If metrics look healthy, gradually increase v2 traffic.
93. What is rolling deployment?
Instances are gradually replaced with the new version.
v1 v1 v1 v1
v2 v1 v1 v1
v2 v2 v1 v1
v2 v2 v2 v2
94. What is zero-downtime deployment?
A deployment where users can continue accessing the service while the new version is rolled out.
Important considerations:
- Backward-compatible APIs
- Database migrations
- Readiness probes
- Graceful shutdown
- Rolling deployment
- Connection draining
11. Advanced Architecture
95. What is CQRS?
CQRS means Command Query Responsibility Segregation.
Separate write and read models:
Commands → Write Model
Queries → Read Model
This can be useful when read and write workloads have significantly different requirements.
96. What is Event Sourcing?
Instead of storing only the current state, the system stores a sequence of events.
OrderCreated
PaymentReceived
OrderShipped
OrderDelivered
Current state can be reconstructed from events.
Event sourcing provides powerful audit/history capabilities but introduces significant complexity.
97. What is a strangler pattern?
The Strangler Fig Pattern gradually replaces a legacy monolith.
┌→ New Customer Service
Client → Gateway
├→ New Order Service
└→ Legacy Monolith
Over time, functionality moves from the monolith to new services.
98. How would you migrate a monolith to microservices?
A strong answer:
- Understand the domain
- Identify bounded contexts
- Identify high-value boundaries
- Introduce an API gateway/facade
- Extract one capability
- Establish independent data ownership
- Add observability
- Automate CI/CD
- Validate production behavior
- Gradually extract additional capabilities
Avoid a big-bang rewrite.
99. How would you design a highly available microservices system?
I would design it around multiple layers:
┌── Service A ── DB
Client → Gateway ├── Service B ── DB
└── Service C ── DB
│
Kafka
Key principles:
- Multiple service instances
- Load balancing
- Horizontal scaling
- Multi-AZ deployment
- Database replication
- Caching where appropriate
- Circuit breakers
- Timeouts
- Retries with backoff
- Idempotency
- Asynchronous processing
- Health checks
- Distributed tracing
- Automated deployment
- Disaster recovery
100. How would you answer a microservices system-design interview question?
Use a structured approach:
Step 1 — Clarify requirements
Ask:
- What functionality is required?
- Expected traffic?
- Latency requirements?
- Availability requirements?
- Consistency requirements?
- Data retention?
- Security requirements?
Step 2 — Identify domains
For example:
User
Order
Payment
Inventory
Shipping
Notification
Step 3 — Define APIs
POST /orders
GET /orders/{id}
POST /payments
GET /inventory/{productId}
Step 4 — Decide communication
Use:
REST/gRPC → synchronous queries/commands
Kafka → asynchronous events
Step 5 — Define data ownership
Order → Order DB
Payment → Payment DB
Inventory → Inventory DB
Step 6 — Design resilience
Include:
Timeout
Retry
Circuit Breaker
Bulkhead
Idempotency
Dead Letter Queue
Step 7 — Design observability
Include:
OpenTelemetry
Metrics
Logs
Distributed Tracing
Correlation/Trace IDs
Step 8 — Design deployment
Kubernetes
↓
Multiple replicas
↓
Multi-AZ
↓
Rolling/Canary deployment
Step 9 — Discuss failure scenarios
Interviewers often care more about failure handling than the happy path.
For example:
What happens if Payment Service is unavailable?
A strong answer might be:
Order Service
↓
Payment unavailable
↓
Timeout
↓
Circuit Breaker
↓
Order remains PAYMENT_PENDING
↓
Retry asynchronously
↓
PaymentCompleted event
↓
Order → CONFIRMED