The short answer: microservices interviews check that you understand the trade-offs, not just the patterns. Expect questions on when to use microservices at all, service boundaries and database per service, communication (REST, gRPC, messaging, API gateways, service discovery), data consistency (sagas, the transactional outbox, idempotency), resilience (timeouts, retries, circuit breakers, bulkheads), observability, deployment, testing and security, plus scenarios such as “a customer was charged but no order exists”. The strongest answers name the cost of each pattern. The answers below are checked against primary sources, including Martin Fowler’s site, microservices.io, Microsoft’s and AWS’s architecture guidance, Kubernetes and OpenTelemetry, with sources at the end.
For the design round itself, see our system design interview guide. Building on Java? Our Spring Boot interview questions cover the framework.
Microservices or monolith?
“What are microservices?”
James Lewis and Martin Fowler describe building one application as a “suite of small services, each running in its own process”, talking over lightweight mechanisms such as HTTP, organized around business capabilities and deployed independently by automated tooling. They note there’s no precise definition, only shared traits, such as decentralized data management and design for failure.
“What are the trade-offs against a monolith?”
| Monolith | Microservices | |
|---|---|---|
| Deployment | One unit | Each service independently |
| Scaling | The whole application | Each service separately |
| Module boundaries | Easy to erode | Strong, enforced by the network |
| Data | One database, simple transactions | Eventual consistency across services |
| Failure | Simple, in one process | Partial failures over a network |
| Operations | Simpler | Complex: many services to run and monitor |
Fowler’s summary: you gain strong module boundaries, independent deployment and technology diversity, and you pay with distribution, eventual consistency and operational complexity.
“When would you not use microservices?”
Fowler argues for monolith first: nearly every success story he has heard began as a monolith that grew too large, partly because stable boundaries are hard to draw before you understand the domain, and moving behavior between services costs far more than moving it inside a monolith. Stefan Tilkov argues the opposite on the same site: if microservices are the goal, splitting a monolith later is very hard. Either way, the style carries a premium that only pays off at high complexity, and Fowler lists prerequisites: rapid provisioning, basic monitoring and rapid application deployment.
A good middle ground is a modular monolith: one deployable application organized into vertical slices per business domain, which can be split later if there’s a reason. Spring Modulith, for example, checks and tests modules inside one Spring Boot application.
“Do teams ever go back to a monolith?”
Yes. In 2023, Amazon Prime Video’s engineers wrote that they moved one audio and video monitoring service from Step Functions and Lambda components into a single process, cutting infrastructure costs by over 90%. It’s a useful example if you state it accurately: it was one service, not all of Prime Video, and the post itself says the choice depends on the case.
Service boundaries
“How do you decide where to split services?”
By business capability or by domain, not by technical layer. In domain-driven design, a bounded context is a part of the model with its own consistent language. Microsoft’s guidance is that a service generally shouldn’t cross a bounded context, and aggregates are good candidates for services. Signs of a bad split include services that must always change together, or that call each other constantly for one request.
“What is database per service?”
Each service keeps its data private and exposes it only through its API. That can mean private tables, a private schema or a separate database server. A shared database is the anti-pattern: it couples services at development time through the schema and at run time through the database. The cost is running several data stores, and needing another pattern, such as API composition or CQRS, for queries across services.
“What is Conway’s law?”
A system’s design tends to mirror the communication structure of the organization that built it. The inverse Conway maneuver reshapes how teams communicate to encourage the architecture you want, which is why service boundaries and team boundaries are usually decided together.
Communication
“Synchronous or asynchronous?”
With synchronous calls (HTTP, gRPC), the caller waits for a reply, so both sides must be up for the whole call. With asynchronous messaging, the sender moves on and a broker buffers the message for one or more consumers. Async gives looser coupling, failure isolation and load leveling, but the broker must be highly available, and the flow is harder to follow. Use synchronous calls for queries that need an immediate answer, and events for work that can happen later.
“REST or gRPC?”
Microsoft’s guidance is to default to REST over HTTP unless you need the performance of a binary protocol. gRPC uses protocol buffers over HTTP/2, supports streaming in both directions, and is typically faster, so it’s common between internal services. REST stays simpler for public APIs and browsers.
“What does an API gateway do?”
It’s a single entry point and reverse proxy in front of your services. It handles routing, aggregation of several calls into one, and offloading of cross-cutting work such as authentication, rate limiting and TLS termination. Without one, clients couple to how you split your services, and every public service repeats that work. How does it differ from a load balancer? A load balancer spreads traffic across instances of one service; a gateway decides which service a request goes to and applies API-level policies. It can become a bottleneck, so keep business logic out of it.
“What is Backends for Frontends?”
Instead of one general-purpose API, each user experience gets its own backend, such as one for web and one for mobile, owned by the team building that experience. The cost is more services to run.
“How does service discovery work?”
Instances come and go, so clients can’t rely on fixed addresses. With client-side discovery, the client queries a service registry and picks an instance; Eureka is the classic example. With server-side discovery, the client calls a router at a known address, which looks up the instance. In Kubernetes, a Service gives a group of Pods a stable name and DNS entry, so applications usually don’t need a separate registry.
“What is a service mesh? Do you need one?”
A service mesh is an infrastructure layer that adds security, observability and traffic management with no code changes. Traditionally, a sidecar proxy runs beside each service. Istio’s ambient mode, generally available since Istio 1.24, instead uses a per-node proxy, with optional proxies for layer 7 features. A mesh adds operational work and some latency, so it pays off with many services and a need for mTLS or traffic policies, not on day one.
Data consistency
“How do you handle a transaction across services?”
With database per service, ACID transactions don’t cross service boundaries. Two-phase commit is usually avoided: many stores and brokers don’t support it, and it couples services together. The usual answer is a saga: a sequence of local transactions, where a failure triggers compensating transactions that undo the completed steps. Refunding a payment is a compensation; it’s a new business action, not a rollback.
“Choreography or orchestration?”
In choreography, each service publishes events that trigger the next step, with no central controller. It suits simple flows but gets hard to follow as they grow. In orchestration, a central orchestrator tells each participant what to do, which makes the flow visible and simplifies timeouts, at the cost of one more component to keep available. Both are hard to debug, and compensations can fail too.
“What is the transactional outbox pattern?”
The problem is the dual write: a service updates its database and publishes a message, and one can succeed while the other fails. The fix is to write the message to an outbox table in the same transaction as the business data:
BEGIN;
INSERT INTO orders (id, total)
VALUES (42, 99.50);
INSERT INTO outbox (topic, payload)
VALUES ('order.created',
'{"orderId": 42}');
COMMIT;A relay then publishes outbox rows to the broker, by polling the table or with change data capture from the database log (Debezium has an outbox router for this). The relay can publish a message more than once, which leads to the next question.
“What is an idempotent consumer?”
One where handling a message twice has the same effect as handling it once. Delivery is usually at-least-once: SQS standard queues, for example, can deliver duplicates, and AWS tells you to design for it. The common approach is to record processed message IDs in the same transaction as the work:
INSERT INTO processed_messages (id)
VALUES ('msg-1')
ON CONFLICT (id) DO NOTHING;If no row was inserted, skip the message. Be careful with claims of “exactly-once”: Kafka’s guarantee applies to read-process-write on Kafka topics, and other destinations have to cooperate.
“What are event sourcing and CQRS?”
Event sourcing stores every state change as an event, and rebuilds current state by replaying them. It gives a full history, but Microsoft warns it’s complex and costly to migrate into or out of. CQRS uses one model for updates and a different one for reads, often a read-only view built for a query, which means eventually consistent reads. Fowler cautions that it adds risky complexity for most systems. They’re often paired but are separate choices. For simple cross-service reads, API composition (call the services and join in memory) may be enough.
Resilience
“How do you stop one slow service taking down everything?”
Layer several defenses:
- Timeouts on every remote call. Amazon picks values from downstream latency percentiles.
- Retries with backoff, only for transient errors and idempotent operations.
- Circuit breakers to stop calling a failing dependency.
- Bulkheads that isolate resources, such as a connection pool per dependency, so one failure doesn’t spread.
- Rate limiting and load shedding, with HTTP 429 and
Retry-After. - Fallbacks, such as cached or default data.
“How does a circuit breaker work?”
| State | Behavior |
|---|---|
| Closed | Calls pass through, and failures are counted |
| Open | Calls fail immediately, without touching the dependency |
| Half-open | A limited number of calls test whether it has recovered |
Success in half-open closes the circuit, and failure reopens it. Retries assume an operation will eventually succeed; a breaker stops operations likely to fail. They combine well, though Amazon notes that breakers add modal behavior that’s hard to test.
“Why add jitter to retries?”
Retries multiply load. Amazon’s example: a five-deep call stack with three retries per layer multiplies load on the database by 243. Add exponential backoff so callers wait longer each time, and jitter so they don’t all return at once. Cap the attempts, and retry at one layer rather than every layer. Otherwise you create a retry storm that stops a struggling service from recovering.
def backoff(attempt, cap=5.0):
# Full jitter, up to the cap
limit = min(cap, 0.1 * 2**attempt)
return random.uniform(0, limit)“Hystrix or Resilience4j?”
Netflix Hystrix is in maintenance mode: its last release was in 2018, and Netflix pointed users to Resilience4j. Resilience4j is a lightweight library of decorators for circuit breakers, retries, rate limiters and bulkheads. An answer that still recommends Hystrix sounds dated.
Observability
“How do you debug a request across ten services?”
With distributed tracing. A trace is the path of one request, and a span is one unit of work within it. Context travels between services in headers; OpenTelemetry’s default uses the W3C traceparent header. Add the trace ID, or a correlation ID, to every log line so you can jump from a trace to its logs.
“What telemetry do you collect?”
Traces, metrics and logs are the core signals in OpenTelemetry. Profiles reached public alpha in March 2026, so a current answer can mention them. Alert on symptoms users feel, such as latency and error rate.
“Liveness, readiness or startup probe?”
| Probe | Question | On failure |
|---|---|---|
| Startup | Has the app started? | Holds off the other probes until then |
| Readiness | Can it take traffic? | Removed from the Service; no restart |
| Liveness | Is it stuck? | The container is restarted |
Don’t check dependencies in a liveness probe: if the database blips, every instance restarts. Kubernetes itself warns that bad liveness probes can cause cascading failures.
readinessProbe:
httpGet:
path: /ready
port: 8080
livenessProbe:
httpGet:
path: /live
port: 8080Deployment and testing
“Blue-green, canary or rolling?”
| Strategy | How it works | Trade-off |
|---|---|---|
| Rolling | Replaces instances gradually (Kubernetes: 25% max unavailable and 25% max surge by default) | Old and new versions serve traffic together |
| Blue-green | Two environments and a switch | Instant rollback, but double the capacity |
| Canary | Sends a small share of users to the new version first | Limits the blast radius, but routing is harder to manage |
“How do you migrate a monolith?”
With the strangler fig pattern: put a facade or proxy in front of the monolith, move one capability at a time to a new service, and shift traffic as each one is ready. Start with something low-risk and valuable. Watch out: the proxy can become a single point of failure, and AWS notes small applications may be better rewritten.
“How do you change an API without breaking consumers?”
Stay backward compatible: add fields, don’t rename or remove them. For a breaking change, add a new version and keep the old one running. Parallel change, also called expand and contract, does this in three phases: add the new form, migrate consumers, remove the old form. The Deprecation and Sunset HTTP headers tell clients what’s going away.
“How do you test microservices?”
Toby Clemson’s guide covers unit, integration, component, contract and end-to-end tests. Keep end-to-end tests few, and give them a time budget. Contract tests catch integration breaks without running everything: with Pact, consumer tests record what they expect in a contract, which is then verified against the real provider. Pact suits teams that control both sides, rather than public APIs.
“What are feature flags for?”
They change behavior without changing code, separating deployment from release. Pete Hodgson’s categories are release, experiment, ops and permissioning flags. They add complexity, so remove them when they’re done.
Security
“How do you secure service-to-service calls?”
mTLS authenticates both sides and encrypts traffic. A service mesh can issue and rotate the certificates; note that Istio’s default mode accepts plaintext too, so require STRICT when you’re ready. For authorization, the OAuth 2.0 client credentials grant lets a service get a token for itself. Zero trust, as NIST describes it, means no implicit trust based on network location, so “it’s inside the cluster” isn’t a defense.
“Validate tokens at the gateway or in each service?”
Both. OWASP’s guidance is that the gateway rejects unauthorized traffic at the edge, but every service still enforces access, including on internal calls, because fine-grained rules live in the service. Validating a JWT locally avoids a network call but can’t see revocation before expiry, while introspection sees revocation but adds latency and a dependency. Check more than the signature: verify the issuer, audience and expiry.
“Where do secrets go?”
In a secrets manager such as Vault or AWS Secrets Manager, not in code or images. Kubernetes Secrets are stored unencrypted in etcd by default, so turn on encryption at rest and restrict access with RBAC.
Microservices with Spring today
Java interviews often ask about Spring Cloud, and many answers online are years out of date:
- Eureka remains, but the Ribbon, Hystrix and Zuul modules were removed from Spring Cloud in the 2020.0 release train. Use Spring Cloud LoadBalancer and Spring Cloud Gateway.
- Spring Cloud Gateway now has WebFlux and Web MVC versions, with renamed starters since 2025.0.
- Spring Retry was archived in July 2026; Spring Framework 7 has
@Retryableand@ConcurrencyLimitbuilt in. - Spring Cloud Circuit Breaker is an abstraction, commonly used with Resilience4j.
- In Kubernetes, its Services and ConfigMaps can replace Eureka and Spring Cloud Config.
Scenario questions
- “A customer was charged, but no order exists.” A dual-write failure or a saga without compensation. Check the trace, repair the data, then fix the cause: an outbox, a saga with a refund step, and idempotency keys so retries don’t charge twice.
- “Checkout got slow because the payment provider is slow.” Set a timeout, add a circuit breaker and a bulkhead, then decide on a fallback. Can you accept the order and take payment asynchronously?
- “Consumers are processing the same message twice.” Expected with at-least-once delivery. Make the consumer idempotent, and check that the visibility timeout or acknowledgment window is longer than processing time.
- “One failing service took the whole site down.” A cascading failure, often from missing timeouts or retries at every layer. Look at the trace, then add timeouts, breakers and retry budgets, and test it with a failure drill.
- “Two services share a database, and every schema change is a fight.” Give one service ownership, move others to its API or to events, and migrate in steps with parallel change.
- “You have 50 services, and nobody knows what depends on what.” Use tracing to map real dependencies, assign an owner to every service, and consider merging services that always change together.
- “How would you split this monolith?” Find the domains, start with a low-risk capability, use a strangler fig, and move data last. Say what would make you stop.
Questions by level
- Junior: what microservices are, monolith vs microservices, REST basics, API gateways, why each service owns its data.
- Mid-level: sync vs async, service discovery, circuit breakers, retries and idempotency, sagas, tracing, health probes, deployment strategies.
- Senior: service boundaries and team structure, when not to use microservices, the outbox and CDC, CQRS and event sourcing trade-offs, service mesh decisions, migration plans, and failure drills.
Behavioral questions for microservices roles
Use the STAR method with a real example:
- “Tell me about an outage across several services. How did you find the cause?”
- “Describe a service you split out, or merged back. Why, and what happened?”
- “Tell me about a breaking change you had to coordinate across teams.”
- “Describe a time you argued against adding complexity.”
More: our backend developer interview questions, AWS interview questions, Kubernetes interview questions and Java interview questions.
Frequently asked questions
What microservices questions are asked in interviews?
What is the saga pattern?
What is the difference between an API gateway and a load balancer?
What are the circuit breaker states?
How do you keep data consistent across microservices?
Should a new project start with microservices?
Can Huru help me practice microservices interview questions?
Sources
- Martin Fowler’s site: Microservices (Lewis and Fowler, 2014), Microservice trade-offs, Monolith First, Don’t start with a monolith (Tilkov), Microservice Premium, Microservice Prerequisites, Bounded Context, Conway’s Law, CQRS, Circuit Breaker, Blue-Green Deployment, Canary Release, Strangler Fig, Parallel Change, Feature Toggles and Testing Strategies in a Microservice Architecture (Clemson). Read on 7 November 2026.
- microservices.io (Chris Richardson): Database per service, Shared database, Saga, Transactional outbox, Idempotent consumer, Client-side discovery, Server-side discovery and Event sourcing. Read on 7 November 2026.
- Microsoft Azure Architecture Center: Microservices style, Microservice boundaries, Interservice communication, API design, API gateways, Saga, Event sourcing, Circuit breaker, Bulkhead, Retry storm antipattern and CI/CD for microservices. Read on 7 November 2026.
- AWS: Timeouts, retries and backoff with jitter (Amazon Builders’ Library), Saga choreography, Transactional outbox, Strangler fig and SQS at-least-once delivery. Read on 7 November 2026.
- Prime Video Tech, Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% (Marcin Kolny, 2023; archived copy, as the original URL now redirects). Read on 7 November 2026.
- Platforms and tools: Kubernetes Services, Kubernetes probes, Kubernetes Deployments, Kubernetes Secrets, Istio service mesh, Istio ambient GA, Istio mTLS migration, gRPC introduction, Apache Kafka design, Debezium outbox event router, Hystrix, Resilience4j and Pact. Read on 7 November 2026.
- Observability and security: OpenTelemetry signals, OpenTelemetry context propagation, OpenTelemetry Profiles alpha, W3C Trace Context, OWASP Microservices Security Cheat Sheet, RFC 6749 (OAuth 2.0), RFC 8725 (JWT best practices) and NIST SP 800-207 (Zero Trust). Read on 7 November 2026.
- Spring: Spring Cloud, Spring Cloud Gateway, Spring Cloud Netflix, Spring Cloud 2020.0 release notes, Spring Cloud 2025.0 release notes, Spring Retry, Spring Framework resilience features and Spring Modulith. Read on 7 November 2026.
