45 Microservices Interview Questions and Answers (2026)

Last updated: October 2026

Microservices questions are where backend interviews separate people who've read about distributed systems from people who've been paged at 2 a.m. because one service took down three others.

Interviewers don't want definitions recited from a blog. They want trade-offs. "Why not just a monolith?" "What happens when the payment service is slow?" "How do you keep data consistent without a distributed transaction?" This guide covers 45 questions asked in backend, Java/Spring Boot and senior engineer interviews in India, with answers you can actually say out loud.

Microservices interview questions: the quick answer

• What gets tested: service boundaries, communication (REST, gRPC, messaging), API gateway, service discovery, data per service, Saga, resilience patterns, observability, deployment on containers and Kubernetes.
• Typical format: concept questions mixed into a backend round, then a design discussion: "break this e-commerce app into services".
• What wins: honest trade-offs. Saying "microservices would be overkill here" at the right moment is a strong signal, not a weak one.
• Common stack in Indian companies: Java with Spring Boot and Spring Cloud, Kafka or RabbitMQ, Docker, Kubernetes, and Prometheus with Grafana.

Fundamentals (1–12)

1. What are microservices?

An architecture where an application is built as a set of small, independently deployable services, each owning one business capability and its own data, and talking to the others over the network. Think of separate Order, Payment, Inventory and Notification services instead of one big app.

2. Microservices vs monolith: what's the difference?

3. What are the main benefits of microservices?

Independent deployments (teams ship without waiting for each other), independent scaling, fault isolation, freedom to choose the right tech per service, and smaller codebases that are easier to understand.

4. What are the main drawbacks?

Network calls fail and add latency, data consistency gets harder, debugging spans many services, and you need serious DevOps: CI/CD, containers, monitoring and tracing. The overall system is more complex even if each part is simpler.

5. When should you not use microservices?

When the team is small, the product is still finding its shape, or the domain boundaries aren't clear yet. A well-structured modular monolith is often the better start; you can split later along proven boundaries. Many experienced engineers will say this, and interviewers like hearing it.

6. How do you decide service boundaries?

Use domain-driven design: find bounded contexts, the areas of the business with their own language and rules, such as Ordering, Billing and Shipping. A good service owns one business capability end to end, changes for one reason, and doesn't need to call five other services for every request.

7. What is a bounded context?

A DDD term for a boundary inside which a model and its terms have one clear meaning. "Customer" in Billing (payment methods, invoices) is different from "Customer" in Support (tickets, history). Each bounded context is a natural candidate for a service.

8. What is the "database per service" pattern?

Each service owns its data and no other service reads its tables directly. Others get the data through the service's API or events. This keeps services independent but means you can't join across services in SQL.

9. What is a distributed monolith?

A system split into services that still have to be deployed together because they share a database, call each other synchronously in long chains, or share libraries tightly. You get the costs of microservices with none of the benefits. Spotting this anti-pattern is a good senior signal.

10. What is the twelve-factor app?

A set of 12 principles for building cloud-friendly services, including config stored in the environment, stateless processes, logs treated as event streams, and dev/prod parity. Most microservice best practices come from it.

11. What is the difference between SOA and microservices?

Service-oriented architecture (SOA) usually relied on a central enterprise service bus, shared schemas and larger services. Microservices favour smart endpoints and dumb pipes, decentralised data and much smaller, independently deployed services.

12. How do microservices communicate?

Synchronously, through REST over HTTP or gRPC, when the caller needs an immediate answer. Asynchronously, through messages or events via Kafka, RabbitMQ or SQS, when it doesn't. Most real systems use both.

Communication and infrastructure patterns (13–25)

13. REST vs gRPC: when do you use which?

REST with JSON is simple, human-readable and great for public and browser-facing APIs. gRPC uses HTTP/2 and Protocol Buffers: faster, strongly typed contracts and streaming support, which makes it a good fit for internal service-to-service calls with high traffic.

14. What are the benefits of asynchronous messaging?

Loose coupling (the sender doesn't need the receiver to be up), better resilience, handling traffic spikes with a queue as a buffer, and easy fan-out: one "OrderPlaced" event can trigger email, analytics and inventory updates.

15. Kafka vs RabbitMQ?

Kafka is a distributed log: very high throughput, messages are retained and can be replayed, and it's ideal for event streaming and many consumers. RabbitMQ is a traditional message broker with flexible routing and per-message acknowledgements, a good fit for task queues and complex routing. Choose based on whether you need replay and streaming (Kafka) or routing and work queues (RabbitMQ).

16. What is an API gateway?

A single entry point in front of your services that handles routing, authentication, rate limiting, SSL termination, request aggregation and sometimes caching. Examples include Spring Cloud Gateway, Kong, NGINX, AWS API Gateway and Apigee.

17. What is the Backend for Frontend (BFF) pattern?

A separate gateway layer per client type (web, mobile, partner API), each shaped for that client's needs. The mobile app gets smaller payloads; the web dashboard gets richer aggregated data.

18. What is service discovery?

The way services find each other's current network addresses as instances scale up, down and move. In client-side discovery, the client asks a registry like Eureka or Consul. In server-side discovery, a load balancer does it. In Kubernetes, Services and built-in DNS handle discovery for you.

19. How does load balancing work between services?

Requests are spread across healthy instances using round robin, least connections or weighted rules. It can happen on the client side (Spring Cloud LoadBalancer), at a load balancer or ingress, or inside a service mesh sidecar.

20. What is centralised configuration?

Keeping configuration outside the code, in a config server (Spring Cloud Config), Kubernetes ConfigMaps and Secrets, or a cloud parameter store, so you can change settings per environment without rebuilding. Secrets belong in a vault (HashiCorp Vault, AWS Secrets Manager), not in Git.

21. What is a service mesh?

An infrastructure layer, usually sidecar proxies like Envoy managed by Istio or Linkerd, that handles service-to-service traffic: mTLS encryption, retries, timeouts, traffic splitting and metrics, without changing application code. Worth it at scale; overkill for five services.

22. What is the circuit breaker pattern?

It wraps calls to a dependency and tracks failures. After too many failures, the circuit "opens" and calls fail fast (or return a fallback) instead of waiting on a broken service. After a cool-down it goes "half-open" and lets a few test calls through. In Java, Resilience4j is the common library.

@CircuitBreaker(name = "inventory", fallbackMethod = "inventoryFallback")
public Stock getStock(String sku) {
    return inventoryClient.getStock(sku);
}

public Stock inventoryFallback(String sku, Throwable ex) {
    return Stock.unknown(sku);   // show "check availability" instead of failing the page
}

23. What are retries, timeouts and bulkheads?

• Timeouts: never wait forever on a network call.
• Retries: retry transient failures with exponential backoff and jitter, and only for idempotent operations.
• Bulkheads: isolate resources, such as separate thread pools per dependency, so one slow dependency can't use up every thread.

Together with circuit breakers, these stop one slow service from cascading into a full outage.

24. What is idempotency, and why does it matter?

An operation is idempotent if doing it twice has the same effect as doing it once. With retries and at-least-once messaging, duplicates will happen. Make writes idempotent with idempotency keys, for example the client sends a unique key with each payment request, and the server ignores repeats.

25. How do you version APIs?

URL versioning (/v1/orders), header versioning, or content negotiation. More important than the method: make backward-compatible changes (add fields, don't rename or remove them), support old versions for a deprecation period, and use contract tests so consumers don't break.

Data and consistency (26–33)

26. How do you handle transactions across multiple services?

Avoid two-phase commit; it's slow and couples services tightly. Use the Saga pattern: a sequence of local transactions, where each step publishes an event or calls the next step, and failures trigger compensating actions, for example refund the payment if the inventory reservation fails.

27. Choreography vs orchestration in Sagas?

In choreography, services react to each other's events with no central coordinator. It's simple for 2–3 steps but hard to follow as it grows. In orchestration, a central orchestrator (a service or a workflow engine like Temporal or Camunda) tells each service what to do next. It's easier to see, test and change for longer flows.

28. What is eventual consistency?

Data across services becomes consistent after a short delay rather than instantly. For example, an order shows "payment pending" for a second before the payment service confirms. Most business flows tolerate this if the UI is honest about it.

29. What is the transactional outbox pattern?

It solves "save to the database AND publish an event" without losing either. You write the business change and an outbox row in the same local transaction. A separate relay process (or change data capture with Debezium) reads the outbox and publishes to Kafka. No event is lost if the app crashes in between.

30. What is CQRS?

Command Query Responsibility Segregation: separate models for writes (commands) and reads (queries). The write side stays normalised and consistent; the read side is denormalised for fast queries, often updated from events. Useful when read and write patterns differ a lot; unnecessary complexity otherwise.

31. What is event sourcing?

Instead of storing only the current state, you store every change as an event (OrderCreated, ItemAdded, OrderPaid) and rebuild state by replaying them. You get a full audit trail and can create new read models later. It's harder to query and evolve, so use it where history matters, as in banking ledgers.

32. How do you query data that's spread across services?

Options: API composition (a gateway or aggregator calls several services and merges the results), a read model built from events (CQRS), or a reporting data warehouse fed by CDC. Avoid letting services read each other's databases.

33. How do you handle a shared reference table, such as a product catalogue?

Make one service the owner and source of truth. Other services either call it (with caching) or keep a local read-only copy updated from its events. Never have two services writing to the same table.

Testing, deployment and observability (34–40)

34. How do you test microservices?

A testing pyramid: many unit tests, integration tests with real dependencies in containers (Testcontainers), contract tests between consumer and provider (Pact or Spring Cloud Contract), a few end-to-end tests, plus monitoring in production. Contract tests are the part most teams skip, and regret.

35. What are blue-green and canary deployments?

Blue-green: run the new version (green) next to the old (blue) and switch all traffic at once, with instant rollback. Canary: send a small share of traffic, say 5%, to the new version, watch error rates and latency, then increase gradually.

36. Why containers and Kubernetes for microservices?

Docker packages each service with its dependencies, so it runs the same everywhere. Kubernetes schedules containers, restarts failed ones, scales them, handles service discovery and supports rolling updates. Together they make running dozens of services practical. See our Kubernetes interview questions for more.

37. What are the three pillars of observability?

Logs (what happened), metrics (how much and how often: latency, error rate, throughput) and traces (the path of one request across services). OpenTelemetry is now the common standard for collecting all three.

38. What is distributed tracing?

Each incoming request gets a trace ID that's passed along in headers to every service it touches. Each service records spans with timings. Tools like Jaeger, Zipkin, Grafana Tempo or Datadog then show the full request path and where time was spent.

39. What should you monitor for each service?

The four golden signals: latency, traffic, errors and saturation. Add business metrics too, such as orders per minute and payment success rate, and alert on symptoms users feel, not on every CPU spike.

40. How do you secure microservices?

Authenticate users at the gateway with OAuth 2.0 / OpenID Connect and pass JWTs downstream; validate tokens in each service. Use mTLS between services (often via a service mesh), apply least-privilege permissions, keep secrets in a vault, and rate-limit public endpoints.

Scenario and design questions (41–45)

41. Break an e-commerce monolith into microservices. How would you start?

Don't rewrite everything at once. Use the strangler fig pattern: put a gateway in front, pick one well-bounded, frequently changing area (say Notifications or Search), build it as a service, route its traffic there, and repeat. Likely services: Catalogue, Cart, Order, Payment, Inventory, Shipping, User and Notification.

42. The payment service is slow, and checkout pages time out. What do you do?

Short term: add timeouts and a circuit breaker on the payment call, return "payment processing, we'll confirm shortly" and finish asynchronously, and scale the payment service if it's resource-bound. Then find the root cause using traces, perhaps a slow third-party gateway, DB locks or connection pool exhaustion, and fix that.

43. A message was processed twice and a customer was charged twice. How do you prevent it?

Assume at-least-once delivery. Make the consumer idempotent: store processed message IDs or use an idempotency key on the payment, with a unique constraint, so a repeat becomes a no-op. Also reconcile with the payment provider.

44. How would you design order placement end to end?

1. The client calls the gateway, which calls the Order service.
2. The Order service creates the order as PENDING and writes an outbox event in the same transaction.
3. Inventory reserves stock and emits StockReserved (or StockFailed).
4. Payment charges the customer and emits PaymentDone (or PaymentFailed).
5. The Order service marks the order CONFIRMED, or runs compensations: release stock, refund.
6. Notification sends the confirmation.

Mention idempotency, retries with backoff, a dead-letter queue and tracing across the flow.

45. Tell me about a production issue in a microservices system you handled.

Use STAR: the situation (what broke and the user impact), how you found the cause (dashboards, traces, logs), what you fixed in the moment, and what you changed afterwards (an alert, a circuit breaker, a runbook). Interviewers value the "what we changed afterwards" part most.

Common mistakes candidates make

• Saying microservices are always better than monoliths.
• Splitting services by technical layer (UI service, DB service) instead of by business capability.
• Ignoring failure: no timeouts, no retries strategy, no idempotency.
• Using distributed transactions (2PC) as the default answer for consistency.
• No mention of observability. If you can't trace a request, you can't run microservices.

A 7-day microservices prep plan

Which roles ask microservices, and what they pay

Microservices come up for backend developers, Java/Spring Boot developers, full stack developers with 3+ years, SDE-2 and above, and platform engineers. For pay, see the full stack developer salary guide and Weekday's salary pages.

Related prep: Spring Boot interview questions, Java 8 interview questions, API testing interview questions and Node.js interview questions.

Frequently asked questions

Are microservices asked in fresher interviews?

Usually only at a basic level: what they are, monolith vs microservices, and REST APIs. Deep questions on Saga, CQRS and resilience are for candidates with 2–3+ years of backend experience.

Do I need to know Spring Cloud for microservices interviews?

For Java roles, yes, at least Spring Cloud Gateway, Config, OpenFeign and Resilience4j, and how Kubernetes can replace parts of Spring Cloud like Eureka. For Node.js or Go roles, focus on concepts plus that ecosystem's tools.

What's the difference between microservices and serverless?

Microservices are an architecture style; serverless is a way of running code, like AWS Lambda, where you don't manage servers. You can build microservices on serverless functions, containers or VMs.

How many microservices should an application have?

There's no right number. It should match your team structure and business domains. A common rule: a service should be owned by one team and be small enough for that team to understand fully.

What is the most important microservices pattern to know?

If you only learn three well: API gateway, Saga (with the outbox pattern), and circuit breaker with timeouts and retries. These cover the questions asked most often.

Prepping for backend roles? Find backend and Java developer jobs on Weekday, and check your resume with our free ATS resume checker before you apply.