Microservices Interview Questions for 3 Years Experience

At around three years of experience, microservices interviews stop rewarding definitions and start rewarding evidence. The interviewer assumes you can recite "small, independently deployable services" — what they want now is proof you have built and operated them. Almost every question loops back to your own project: how you split it, how the pieces talk, and what broke. This page covers the questions that actually decide a mid-level microservices interview, framed the way they are asked.

How did you decide where to split a service?

Split along business capabilities and data ownership, not technical layers. A service should own its data and change for one business reason. The clean answer references bounded contexts from domain-driven design: an Orders service, a Payments service, an Inventory service — each with its own schema.

The honest mid-level answer also admits where you got it wrong. Interviewers love "we split too early and created chatty calls, so we merged two services back together." That shows you understand splitting has a cost, not just a benefit. If every use case requires calling three services in a row, the boundary is probably in the wrong place.

Interview note: Follow-up: "how do you avoid a distributed monolith?" Answer: independent deployability and no shared database. If two services must deploy together or write to the same tables, they are one service wearing a costume.

How do two of your services communicate, and why?

Synchronous REST (or Feign/WebClient) when the caller needs an immediate answer; asynchronous messaging (Kafka, RabbitMQ) when the work can happen later and you want decoupling. State which you used and the trade-off you accepted.

Synchronous calls are simple but create temporal coupling — if Payments is down, Orders is down. Asynchronous events remove that coupling but force you to handle eventual consistency and duplicate delivery. A strong answer names both and explains why your case fit one.

@FeignClient(name = "inventory-service")
public interface InventoryClient {
    @GetMapping("/api/stock/{sku}")
    StockResponse getStock(@PathVariable("sku") String sku);
}

Naming Feign is fine, but be ready for "what happens when inventory-service is slow?" The answer is timeouts plus a circuit breaker — never an unbounded blocking call.

Interview note: Trap: candidates say "we used REST" and stop. The scoring detail is synchronous vs asynchronous and the failure behavior, not the protocol name.

Tell me about a production bug that spanned multiple services.

Pick one real incident and walk the trace: symptom, how you correlated logs across services, the root cause, the fix. This is the single most predictive mid-level question.

A good story mentions correlation IDs — a request ID passed in headers and logged by every service so you can stitch one user action across three logs. If you used distributed tracing (Zipkin, Jaeger, or Sleuth/Micrometer Tracing), say so. The failure mode you describe should be genuinely distributed: a retry storm, a missing timeout, a poison message, an event consumed twice.

Interview note: Follow-up: "how did you find which service was slow?" Distributed tracing shows per-hop latency. Without it, you are grepping logs by timestamp and guessing — mention that pain if it was real.

How do you handle configuration across services?

Externalize configuration so the same build runs in every environment — typically a config server or environment variables, never hardcoded values. Spring Cloud Config or Kubernetes ConfigMaps/Secrets are the usual answers.

The mid-level detail: secrets do not belong in Git. Database passwords go in a secret manager or Kubernetes Secret, not application.yml. Mention how you refreshed config without redeploying if you used it (@RefreshScope), but do not overclaim.

Why database-per-service? Didn't that cause problems?

Each service owns its data so it can evolve its schema independently — the price is that you cannot use a foreign key or a single transaction across services. This is where interviewers test whether you understand distributed data.

Be honest that joins across services become API calls or data duplication, and that consistency becomes eventual. If you needed a cross-service transaction, the grown-up answer is the saga pattern — compensating actions rather than a two-phase commit.

Interview note: Trap: "how did you generate a report joining orders and customers?" Not a SQL join across two databases. You either call both services and join in memory, or you maintain a read model fed by events.

How did you make a message consumer safe to retry?

Make it idempotent: processing the same message twice must not double the effect. At-least-once delivery means duplicates are normal, so consumers dedupe by message key or track processed IDs.

if (processedRepo.existsById(event.getEventId())) {
    return; // already handled — safe to ignore the duplicate
}
processOrder(event);
processedRepo.save(new ProcessedEvent(event.getEventId()));

Idempotency is the concept that separates people who read about Kafka from people who ran it. Say it plainly.

How do you version an API without breaking consumers?

Add, don't break: introduce new fields as optional, version the URL or media type when a breaking change is unavoidable, and keep the old version running until consumers migrate. Coordinated big-bang deploys across services are the anti-pattern.

How did you test a service in isolation?

Unit tests for logic, then contract or integration tests for the boundaries — mocking or stubbing the services you depend on. Mention Testcontainers if you spun up a real database or Kafka in tests, and contract testing (Spring Cloud Contract, Pact) if you guarded the API against consumers.

What did you deploy with, and how did a release go out?

Containers (Docker) orchestrated by Kubernetes, deployed one service at a time. The point interviewers check: independent deployability. You should be able to ship the Orders service without redeploying Payments. Mention health checks and a rolling update if you used them.

What interviewers really test at 3 years

They are checking whether you have operated microservices or only assembled them. The strongest signal is a specific failure story told with the right vocabulary — correlation IDs, idempotency, timeouts, eventual consistency — because those words only enter your speech after you have been paged at 2 a.m. Prepare two real incidents you can narrate end to end.

To sharpen the two areas that come up most, pair this with the microservices communication questions and the API gateway question set, and structure your project stories against the microservices learning path. A focused mock interview is the fastest way to hear where your story stops being convincing — and to push it one layer deeper.