Microservices Interview Questions

This article collects common microservices interview questions with short answers. Each group links to the articles that explain the mechanism in full. The diagram shows how the groups relate.

flowchart LR
    F[Fundamentals] --> D[Decomposition]
    D --> C[Communication]
    C --> DA[Data]
    DA --> R[Resilience]
    R --> O[Operations and security]

Fundamentals

Background: monolith vs microservices, when to use microservices, trade-offs.

1. What is a microservice? A service that is independently deployable, owns its own data, and is organized around one business capability. Its deployment unit is a single service, and it communicates with other services over the network.

2. How does a modular monolith differ from microservices? A modular monolith has strict module boundaries inside one deployable unit, with in-process calls. Microservices put those boundaries across the network, which adds independent deployment and scaling but also latency, partial failure, and operational cost.

3. When should a team not use microservices? When the team is small, the domain is not yet understood, or there is no deployment automation and monitoring. Boundaries drawn too early are expensive to change, because moving logic or data between services needs API changes and data migration.

4. What is a distributed monolith? A system split into services that still must be deployed together or that fail together, usually due to shared databases, synchronous call chains, or tightly coupled release schedules. It carries the network and operational costs of microservices without independent deployment.

5. How would you migrate a monolith to microservices? Incrementally, with the strangler fig pattern: put a facade in front of the monolith, extract one capability at a time behind it, and route traffic to the new service. See migrating with the strangler fig. An anti-corruption layer keeps the monolith's model out of the new service.

Decomposition

Background: bounded contexts, business capability decomposition, service granularity, Conway's law.

6. What is a bounded context? A boundary inside which a domain model and its terms have one consistent meaning. The same word, such as "customer", can mean different things in different contexts, and each context has its own model.

7. How do you decide service boundaries? Start from business capabilities and bounded contexts. Check that a candidate service has high cohesion, changes for one reason, owns its data, and can be owned by one team.

8. What signs indicate services are too fine-grained? Chatty synchronous calls between services, changes that always touch several services, and transactions that span services for one business operation.

9. What is Conway's law? Systems tend to mirror the communication structure of the organizations that build them. The inverse Conway maneuver structures teams to match the architecture wanted.

10. Should services share libraries? Sharing generic utilities is acceptable. Sharing domain models or database access code couples services through releases. Share contracts (schemas), not implementations.

Communication

Background: sync vs async, choreography vs orchestration, service discovery, service mesh, API versioning and contract testing.

11. When do you use synchronous versus asynchronous communication? Use synchronous calls when the caller needs the answer to continue. Use messaging when the work can complete later or when the caller should not depend on the receiver being up. Asynchronous messaging removes temporal coupling.

12. How does a chain of synchronous calls affect availability? Availability multiplies. Three services each at 99.9 percent give about 99.7 percent for a request that needs all three (0.999^3), assuming failures are independent. Each added synchronous dependency lowers the total.

13. Choreography or orchestration? Choreography has services react to each other's events, with no central coordinator, which suits short flows. Orchestration uses a coordinator that sends commands and tracks state, which suits long flows with many steps and compensation logic.

14. What does an API gateway do? It is the single entry point for clients: routing, TLS termination, authentication, rate limiting, and sometimes response aggregation. See reverse proxy and API gateway.

15. What is a backend for frontend? A gateway tailored to one client type (web, mobile), which aggregates and shapes responses for that client. See BFF and API composition.

16. How do services find each other? Through a service registry or DNS. In client-side discovery the caller queries the registry and balances load itself. In server-side discovery a load balancer or platform (for example Kubernetes Services) does it.

17. What does a service mesh provide? Sidecar proxies (the data plane) handle mutual TLS, retries, timeouts, and traffic routing, configured by a control plane. It moves these concerns out of application code at the cost of extra hops and operational complexity.

18. How do you change an API without breaking consumers? Make changes backward compatible (add optional fields, do not remove or repurpose fields), use expand-contract for breaking changes, and verify with consumer-driven contract tests.

Data

Background: database per service, saga, outbox and CDC, event sourcing and CQRS, eventual consistency, idempotent consumers.

19. Why does each service own its database? It lets a service change its schema and storage technology without coordinating with others, and prevents hidden coupling through shared tables. Other services access the data only through its API or events.

20. How do you run a transaction across services? Use a saga: a sequence of local transactions where each step has a compensating transaction that undoes it if a later step fails. Two-phase commit is usually avoided because it blocks and is not supported by many stores and external providers.

21. What is a compensating transaction, and can it always undo a step? It is a business-level reversal, such as releasing a reservation or issuing a refund. Some actions cannot be reversed (an email sent), so they are placed after the steps that can fail.

22. What is the dual-write problem? Updating a database and publishing a message are two operations that cannot be made atomic together. A crash between them leaves them inconsistent.

23. How does the transactional outbox solve it? The service writes the message to an outbox table in the same local transaction as the state change. A relay process then publishes outbox rows to the broker, giving at-least-once delivery.

24. What is change data capture? Reading a database's transaction log to emit each committed change as an event. It can drive the outbox relay without polling, and does not add load to application queries.

25. What is CQRS? Command Query Responsibility Segregation separates the write model from one or more read models optimized for queries. Read models are updated from events, so they are eventually consistent.

26. What is event sourcing, and what are its costs? State is stored as an append-only sequence of events, and current state is derived by replaying them. It gives a full audit history, but complicates schema evolution, queries, and deletion of personal data.

27. How do you query data that lives in several services? Use API composition (call each service and join in memory), or maintain a denormalized read model fed by events. Composition suits small result sets. Read models suit large or frequent queries.

28. How do you make a consumer idempotent? Record processed message IDs in the same transaction as the side effect (the inbox pattern), or design the operation to be naturally idempotent, such as setting a value instead of incrementing it.

Resilience

Background: timeouts, retries, backoff, circuit breaker, bulkhead and load shedding, health checks, chaos engineering.

29. Why must every remote call have a timeout? Without one, a slow dependency holds threads and connections indefinitely and exhausts the caller's resources. Timeouts should fit inside the caller's own deadline, which is propagated downstream.

30. What is retry amplification and how do you limit it? When each layer of a call chain retries, the load on the deepest service multiplies by the number of attempts per layer. With three layers that each make up to 3 attempts, one client request can produce up to 27 calls to the deepest service. Limit it by retrying at one layer, using retry budgets, and applying exponential backoff with jitter.

31. How does a circuit breaker work? It counts failures per dependency. When failures pass a threshold the circuit opens and calls fail immediately. After a wait it goes half-open and lets a few trial requests through. Success closes it, failure reopens it.

32. What is the bulkhead pattern? Isolating resources per dependency (separate thread pools or connection pools) so one slow dependency cannot consume the resources needed for others.

33. What is load shedding? Rejecting some requests early when the service is overloaded, preferably low-priority ones, to keep latency acceptable for the rest.

34. What is the difference between liveness and readiness probes? A liveness probe tells the platform whether to restart the container. A readiness probe tells it whether to send traffic. A service that is temporarily unable to serve should fail readiness, not liveness.

35. What is chaos engineering? Deliberately injecting failures, such as killing instances or adding latency, to test a hypothesis about steady-state behavior, with a limited blast radius.

Operations and security

Background: Kubernetes, CI/CD and deployment, feature flags, distributed tracing, zero trust, observability.

36. How do you release a change with low risk? Deploy behind a feature flag or as a canary: send a small share of traffic to the new version, compare error rate and latency to the old one, and roll back automatically on regression.

37. How do you trace a request across services? Generate a trace ID at the edge and propagate it in headers (W3C traceparent) on every call and in message metadata. Each service records spans with that trace ID, and a backend assembles them into a trace.

38. What are the three pillars of observability? Logs (discrete events), metrics (numeric time series), and traces (request paths across services). Correlating them by trace ID makes diagnosis faster.

39. How do services authenticate each other? With mutual TLS using per-service identities (for example SPIFFE IDs) issued and rotated automatically. Authorization then checks the caller's identity against policy.

40. Where should authorization happen? Authentication is commonly done at the gateway. Authorization decisions that depend on business data must also be enforced in the service that owns the data, because a service cannot assume all traffic passed through the gateway.