Microservices Design Patterns Interview Questions and Answers

Design-pattern questions are where a microservices interview gets concrete. It is no longer "what are microservices" but "a payment succeeds and inventory fails — how do you keep the data consistent?" Each pattern is an answer to a specific distributed-system problem, and the candidates who stand out lead with the problem, not the pattern name. This set covers the twelve pattern questions asked most, each with the problem it solves, working detail, and a follow-up trap.

Why interviewers ask about microservices design patterns

Once you split a system into services, a predictable set of hard problems appears — consistency without shared transactions, resilience against partial failure, routing, migration. Design patterns are the industry's agreed answers, so knowing them signals you have worked past the "hello world" stage of microservices.

The give-away of a strong candidate is problem-first thinking. Weak answers recite "saga is a pattern for transactions"; strong answers say "when I need to update order and payment which live in different databases, I cannot use one ACID transaction, so I use a saga." The pattern is the conclusion, not the opening.

How to answer in an interview

For every pattern, state the problem, the mechanism, and one cost. "Circuit breaker" is a name; "when a downstream service is failing, retrying just makes it worse, so a circuit breaker stops calls and fails fast — the cost is that some requests get a fallback instead of the real answer" is an answer.

Keep a running example system so patterns connect. If the fundamentals feel loose, review what microservices are and the saga pattern guide before drilling.

Q1. What is the saga pattern and what problem does it solve?

Sagas maintain consistency across services that each own their database, where a single ACID transaction is impossible. A saga is a sequence of local transactions linked by events; each step has a compensating action that undoes it if a later step fails.

Order placed -> reserve inventory -> charge payment
If payment fails -> compensate: release inventory, cancel order

The mental model is "commit each step locally, and if something downstream fails, run the undos backward." There is no rollback of a distributed transaction because there was never one — just forward steps and compensations.

Interview note: Trap: "what if a compensating action itself fails?" You need retries with idempotency and, ultimately, alerting for manual intervention. Compensations must be designed to be safely retryable.

Q2. Choreography vs orchestration for sagas — which and why?

Choreography: each service reacts to events, no central coordinator — loosely coupled but hard to trace end to end. Orchestration: a central orchestrator directs each step explicitly — easy to follow and debug but adds a coordinating component and a coupling point.

The trade-off is visibility versus decoupling. Simple two- or three-step flows suit choreography; complex workflows with branching and many steps suit orchestration because you can reason about the whole flow in one place.

Interview note: Follow-up: "which is easier to debug when a saga gets stuck?" Orchestration — the orchestrator holds the state machine, so you can see exactly where it halted. Choreography forces you to reconstruct the flow from scattered events.

Q3. What is the circuit breaker pattern?

It prevents cascading failure. When calls to a service fail beyond a threshold, the breaker "opens" and fails fast — returning a fallback instead of hammering the failing service — then periodically "half-opens" to test whether it has recovered.

CLOSED  -> failures exceed threshold -> OPEN (fail fast, use fallback)
OPEN    -> after cooldown            -> HALF_OPEN (allow a trial call)
HALF_OPEN -> success                 -> CLOSED   (resume normal calls)

Without it, a slow dependency backs up its callers' threads until the whole system stalls — the signature microservices outage. The breaker gives the failing service room to recover. Detail in the circuit breaker guide.

Interview note: Trap: "difference between retry and circuit breaker?" Retry re-attempts a transient failure; a circuit breaker stops attempts when failures persist. Retrying a down service without a breaker makes the outage worse — they are used together.

Q4. What does the API gateway pattern provide?

A single entry point that routes client requests to services and centralises cross-cutting concerns — authentication, rate limiting, TLS termination and response aggregation. It shields clients from the internal service topology.

The problem it solves is client complexity: without a gateway, every client knows every service address and re-implements auth and throttling. The gateway also lets you aggregate several service calls into one client response, reducing chattiness.

Interview note: Follow-up: "gateway vs a plain load balancer?" A load balancer distributes traffic across identical instances; a gateway is application-aware — it routes by path, enforces auth, transforms and aggregates. Different jobs.

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

A dedicated gateway per client type — one BFF for web, another for mobile — each shaping responses to that client's exact needs. It avoids one generic API forced to serve very different consumers poorly.

Mobile and web have different bandwidth, screen and data needs; a single API compromises for both. A BFF lets each client's backend aggregate and trim data ideally, at the cost of more gateways to maintain.

Interview note: Trap: "isn't a BFF just duplicated code?" Some duplication, yes — the trade-off is decoupling client teams so a mobile change never risks the web contract. Shared logic still lives in the downstream services.

Q6. Explain CQRS and when you would use it.

CQRS (Command Query Responsibility Segregation) separates the write model (commands) from the read model (queries), often with different data stores optimised for each. Use it when reads and writes have very different shapes or scale — heavy reporting against complex writes.

The read side can be denormalised and replicated for fast queries while the write side stays normalised and consistent. The cost is complexity and eventual consistency between the two models, so you apply it selectively, not everywhere.

Interview note: Follow-up: "does CQRS require event sourcing?" No — they pair well but are independent. You can do CQRS with two ordinary databases kept in sync by events, without ever storing an event log as the source of truth.

Q7. What is event sourcing?

Instead of storing current state, you store the full sequence of state-changing events, and derive current state by replaying them. It gives a complete audit trail and lets you rebuild state or new read models from history.

AccountCreated -> Deposited(100) -> Withdrew(30)
Current balance = replay -> 70  (state is derived, not stored)

The power is auditability and the ability to reconstruct any past state; the cost is complexity, event schema evolution, and the need for snapshots so replay stays fast.

Interview note: Trap: "what happens when your event schema changes?" You need versioned events and upcasting to translate old events to the new shape — a real, ongoing maintenance cost people underestimate.

Q8. What is the strangler fig pattern?

A migration pattern: you incrementally replace a monolith by routing specific capabilities to new services while the monolith shrinks, until it is fully "strangled." A facade or gateway routes each request to the old or new implementation.

It exists because big-bang rewrites are high-risk and often fail. The strangler lets you migrate one capability at a time, in production, with the ability to roll back per capability. It is the standard safe path off a monolith.

Interview note: Follow-up: "how do you route between old and new during migration?" Through the gateway or a facade that decides per route, so you can move one endpoint at a time and revert instantly if the new service misbehaves.

Q9. What is the sidecar pattern?

You deploy a helper container alongside each service instance to handle cross-cutting concerns — logging, monitoring, TLS, service discovery — outside the application code. A service mesh like Istio uses sidecars to manage all service-to-service traffic.

The benefit is that infrastructure concerns live in the sidecar, so every service gets them uniformly regardless of language. The cost is another container per instance and the operational weight of the mesh.

Interview note: Trap: "why not just put that logic in a shared library?" A library couples every service to one language and forces a redeploy to upgrade it. A sidecar is language-agnostic and upgradeable independently of the service.

Q10. What is the outbox pattern and the dual-write problem?

The dual-write problem: updating your database and publishing an event are two operations that can partially fail, leaving them inconsistent. The outbox pattern writes the event into an outbox table in the same transaction as the data change; a separate relay reliably publishes it later.

BEGIN TX
  update order status = PAID
  insert into outbox (event = OrderPaid)   -- same transaction
COMMIT
-- relay reads outbox, publishes to Kafka, marks sent

This guarantees the event is stored atomically with the state change, so you never charge a payment without emitting the event, or vice versa. It is the reliable bridge between a database and a message broker.

Interview note: Follow-up: "how does the relay avoid publishing twice?" Consumers must be idempotent, and the relay marks rows as sent. At-least-once delivery plus idempotent consumers is the standard, since exactly-once is very hard.

Q11. What is the aggregator / API composition pattern?

When a client needs data owned by several services, an aggregator queries each service and composes the combined response. It replaces the cross-service join you cannot do because each service owns its own database.

The cost is that the aggregator's response is only as fast as its slowest dependency and only as available as all of them together. For heavy query needs, a CQRS read model is often preferable to live composition.

Interview note: Trap: "why not just query the databases directly and join?" Because that breaks the database-per-service boundary and couples services to each other's schemas — the anti-pattern that creates a distributed monolith.

Q12. What is the bulkhead pattern?

It isolates resources so a failure in one part cannot sink the whole system — like watertight compartments in a ship. You give each dependency its own thread pool or connection pool, so one slow service cannot exhaust the resources every other call needs.

Paired with the circuit breaker, the bulkhead is core resilience. The breaker stops calling a failing service; the bulkhead ensures that even while it fails, it cannot starve unrelated traffic of threads.

Interview note: Follow-up: "circuit breaker vs bulkhead — do you need both?" Yes, they are complementary: the bulkhead contains the blast radius of a slow dependency, the breaker stops calling a broken one. Together they prevent cascading failure.

How to prepare

Take one workflow — placing an order across order, payment and inventory — and design it with the patterns: a saga for consistency, circuit breakers on each call, an outbox for reliable events, a gateway at the edge. Working one scenario through every pattern shows you how they combine, which is exactly what a system-design round asks.

Rehearse leading with the problem for the big four — saga (Q1), circuit breaker (Q3), gateway (Q4), CQRS (Q6) — since those are asked constantly. Then connect them to the broader picture in the microservices architecture questions and the deeper microservices interview questions guide. If messaging comes up, the Kafka vs RabbitMQ comparison covers the brokers these patterns run on. This kind of applied design is central to our Java Full Stack with AI program.