Microservices Interview Questions for 5 Years Experience

By five years, an interviewer assumes you can build services — so they stop asking whether you can and start asking whether your judgment is sound. The questions shift from "how do services communicate" to "why did you accept eventual consistency here, and how did you keep it correct?" This is an architecture and ownership conversation. The strongest candidates defend real decisions and, crucially, name the alternative they rejected. Below are the questions that decide a mid-senior microservices loop.

Two services must both change or neither should. How do you do that without a distributed transaction?

Use a saga: a sequence of local transactions where each step publishes an event, and a failure triggers compensating actions that undo the earlier steps. Two-phase commit exists but locks resources across services and does not scale — most teams avoid it.

The five-year detail is knowing the two saga flavors: choreography (each service reacts to events, no central coordinator — simple but the flow is implicit and hard to trace) and orchestration (a coordinator service drives the steps explicitly — easier to reason about and monitor, at the cost of a central component). You should be able to say which you used and why.

Interview note: Follow-up: "what if the compensation itself fails?" You need retries with a dead-letter path and, ultimately, an operational alert — sagas guarantee eventual consistency, not zero manual intervention. Admitting that is senior, not weak.

When do you choose availability over consistency?

When a stale-but-fast answer is better for the business than a correct-but-unavailable one — a product catalog, a feed, a recommendation. When money or inventory correctness is at stake, you lean toward consistency and accept lower availability or higher latency.

Apply CAP rather than quote it: under a network partition you must pick. A senior answer ties the choice to a concrete feature and describes how eventual consistency was made safe — idempotent writes, versioning, or read-your-writes where the user expects it.

How do you keep one slow dependency from taking down the whole system?

Timeouts on every remote call, a circuit breaker to stop hammering a failing dependency, and bulkheads to isolate its thread pool so it cannot exhaust shared resources. The failure you are preventing is a cascade: one slow service fills every caller's thread pool until the whole graph is unresponsive.

@CircuitBreaker(name = "pricing", fallbackMethod = "cachedPrice")
@TimeLimiter(name = "pricing")
public CompletableFuture<Price> getPrice(String sku) {
    return CompletableFuture.supplyAsync(() -> pricingClient.price(sku));
}

public CompletableFuture<Price> cachedPrice(String sku, Throwable t) {
    return CompletableFuture.completedFuture(lastKnownPrice(sku)); // degrade, don't fail
}

The insight interviewers reward: a circuit breaker without a timeout is nearly useless, because a call that never returns never trips the breaker. Graceful degradation — a fallback that returns a cached or default value — is what keeps the user experience alive.

Interview note: Trap: "retries make things more reliable, right?" Not always — naive retries against an overloaded service amplify load and cause a retry storm. Retries need exponential backoff, jitter, and a cap, and should only target idempotent operations.

How do you make an operation idempotent across retries and duplicate events?

Give each request or event a unique key and record which keys you have processed, so a repeat is a no-op. At-least-once delivery and client retries make duplicates inevitable; idempotency is how correctness survives them.

For writes, an idempotency key on the request lets the service return the original result instead of applying the effect twice. For event consumers, dedupe on an event ID. This is table stakes at five years — be able to describe your exact mechanism.

How do you find a latency regression that spans ten services?

Distributed tracing to see per-hop latency for a single request, RED/USE metrics per service, and structured logs correlated by a trace ID. Without tracing you are guessing; with it you can point at the exact hop.

A senior answer separates the three pillars — metrics (aggregate trends and alerting), logs (detail for one event), traces (causality across services) — and knows each answers a different question. Mention SLOs and error budgets if you have operated to them.

How do you handle schema and API evolution across many teams?

Backward-compatible changes by default, consumer-driven contract tests to catch breakage before deploy, and versioning only when a breaking change is truly unavoidable. For events, treat the schema as a contract — a schema registry with compatibility rules prevents a producer from breaking every consumer silently.

The ownership angle: you cannot coordinate a synchronous upgrade across ten teams, so the architecture must tolerate old and new consumers running simultaneously. Design for the mixed state, not the instantaneous cutover.

How do you decide the right size for a service?

Size to a bounded context and a team's ownership, not to a line count. Too fine-grained and every feature becomes a distributed transaction with chatty calls; too coarse and you rebuild the monolith. The heuristic: a service should be independently deployable, own its data, and change for one business reason.

Interview note: Follow-up: "when would you merge two services?" When they always change together and constantly call each other — that coupling means the boundary was wrong. Merging back is a legitimate senior decision, not a failure.

What is the hardest trade-off you made, and would you make it again?

Pick a real one — synchronous simplicity vs asynchronous decoupling, strong vs eventual consistency, build vs buy — and defend it with the constraints you had. The point is not a perfect answer; it is showing you weigh alternatives, measure outcomes, and revisit decisions with new information.

What interviewers really test at 5 years

They are testing whether you can be trusted to own a design decision that will outlive the sprint. That trust comes from hearing you name a trade-off, choose deliberately, and describe how you would know if you were wrong. Rehearse two or three architecture decisions until you can give the reason, the rejected alternative, and the outcome for each.

Deepen the two areas most likely to be probed with the resilience patterns questions and the saga pattern question set, and map your stories to the microservices learning path. A mock interview centered on architecture trade-offs is the quickest way to find which of your decisions you cannot yet defend under follow-up.