Skip to content
Bill Liao
Go back

100 Microservice Questions and Answers

Edit page

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:


2. What are the main characteristics of microservices?

The most important characteristics are:

  1. Independent deployability
  2. Loose coupling
  3. High cohesion
  4. Autonomous teams
  5. Independent scalability
  6. Decentralized data management
  7. Resilience and fault isolation
  8. Automated CI/CD
  9. API-based communication
  10. Strong observability

3. What are the advantages of microservices?

Key advantages include:


4. What are the disadvantages of microservices?

Microservices introduce significant distributed-system complexity:

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:

Don’t use microservices simply because they are popular.


6. When should you NOT use microservices?

A monolith may be better when:

A modular monolith can often be a better starting point.


7. Microservices vs monolith?

MonolithMicroservices
Single deploymentIndependent deployments
Usually shared databaseDatabase per service
Simple communicationNetwork communication
Easier debuggingDistributed tracing required
Simple transactionsDistributed transactions
Easier operationsMore operational complexity
Scale entire applicationScale 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:

DDD is particularly useful when defining microservice boundaries.


2. Microservice Design

11. How do you identify microservice boundaries?

Start with:

  1. Business capabilities
  2. Bounded contexts
  3. Domain ownership
  4. Data ownership
  5. Team ownership
  6. Change frequency
  7. 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:

Example:

Client
  |
  ↓
API Gateway
 / | \
A  B  C

3. Communication

21. How do microservices communicate?

Two major approaches:

Synchronous:

Asynchronous:


22. REST vs messaging?

REST is usually appropriate when the caller needs an immediate response.

Messaging is useful when:


23. REST vs gRPC?

RESTgRPC
HTTP/JSON commonlyHTTP/2 + Protobuf
Easy browser integrationExcellent service-to-service
Human readableCompact binary
Broad ecosystemStrong contracts
Usually simplerUsually 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:

Key concepts include:


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:


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:


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:


37. What is a service mesh?

A service mesh manages service-to-service communication through infrastructure-side proxies.

Examples include:

It can provide:


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:


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:

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:

Orchestration:

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:


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:


62. What is Spring Cloud?

Spring Cloud provides tools for distributed systems, including patterns around:

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:


64. What is Spring Boot Actuator?

Actuator exposes operational endpoints.

Examples:

/actuator/health
/actuator/metrics

It is commonly used for:


65. What is Resilience4j?

Resilience4j is a lightweight fault-tolerance library for Java.

It provides patterns such as:


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:


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:


70. How should secrets be managed?

Never hard-code secrets:

Java

password = "myPassword123";

Use:

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:


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:

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:

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:


78. How do you secure service-to-service communication?

Use combinations of:


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:

It provides instrumentation and exporters to observability backends.


83. What metrics should you monitor?

Important metrics include:

A useful starting point is the RED methodology:


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:


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:


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:


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:

  1. Understand the domain
  2. Identify bounded contexts
  3. Identify high-value boundaries
  4. Introduce an API gateway/facade
  5. Extract one capability
  6. Establish independent data ownership
  7. Add observability
  8. Automate CI/CD
  9. Validate production behavior
  10. 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:


100. How would you answer a microservices system-design interview question?

Use a structured approach:

Step 1 — Clarify requirements

Ask:

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

Edit page
Share this post:

Previous Post
100 AWS interview Questions and Answers
Next Post
100 Spring Boot Interview Questions and Answers