Microservices Interview Questions for Java Developers

Microservices questions test judgment more than definitions — every answer is a trade-off. Interviewers want to hear you reason about why: why split here, why async there, what breaks when the network lies. These are the questions Java shops actually ask, with the reasoning that scores.

1. Monolith vs microservices — when would you NOT split?

Answer: microservices buy independent deployability and team autonomy at the price of distributed-systems complexity (network failures, eventual consistency, observability overhead). Don't split: small team, unclear domain boundaries, or a startup that needs speed — a modular monolith wins. The scoring sentence: "Microservices are an organizational scaling pattern first, a technical pattern second."

2. How do you decide service boundaries?

Answer: Domain-Driven Design's bounded contexts — split along business capabilities (Orders, Payments, Inventory), not technical layers (never a "database service"). Each service owns its data exclusively; sharing a database between services is the cardinal sin because it re-couples everything you just split. Test: "Can I deploy and scale this independently?" If no, the boundary is wrong.

3. REST vs gRPC vs messaging — how do you choose?

  • REST/HTTP: external APIs, browser clients, maximum interoperability. Human-readable, universally supported.
  • gRPC: internal service-to-service — binary protobuf, strongly typed contracts, streaming. Lower latency, but harder to debug by hand.
  • Async messaging (Kafka/RabbitMQ): anything that doesn't need an immediate answer — order placed → inventory, notifications, analytics. Decouples availability: the consumer can be down without blocking the producer.

Answer: synchronous for queries needing answers now, async for events and side effects. The follow-up: "What breaks with too much sync communication?" — cascading failures; which leads to question 4.

4. How do you stop one failing service from taking down the rest?

The resilience trio — name all three:

  • Circuit breaker (Resilience4j): after N failures, stop calling the sick service for a cooldown — fail fast instead of piling up blocked threads. Half-open state probes recovery.
  • Retry with backoff + jitter: retry transient failures, but exponential backoff with random jitter so 100 clients don't retry in lockstep (retry storms).
  • Bulkhead: isolate thread pools per dependency — Payments being slow must not starve the pool serving the catalog.
  • Timeouts everywhere: no call without a deadline. The most skipped, most important one.

5. How do you handle transactions across services? (The Saga question)

Answer: no distributed 2PC in practice — use the Saga pattern: a sequence of local transactions, each publishing an event that triggers the next; each step defines a compensating action (cancel order → refund payment → restock inventory). Two flavors: choreography (services react to events, no coordinator — simple, but the flow is implicit) vs orchestration (a saga orchestrator commands each step — explicit, easier to debug). For interviews: draw choreography for 3 services, orchestration beyond that.

6. What is service discovery, and do I need it?

Answer: services come and go (scaling, deploys, crashes), so hardcoded URLs don't work. Client-side (Eureka: client queries the registry) vs server-side (a load balancer / Kubernetes Service fronts the instances). In 2026 the honest answer is often "Kubernetes DNS + Services handle it" — but know what problem it's solving for the follow-up.

7. What does the API gateway do?

Answer: single entry point: routing, authentication (validate JWT once), rate limiting, request aggregation (one mobile call → fan out to 3 services → one response). Spring Cloud Gateway is the Java answer. The trap: "Isn't it a single point of failure?" — yes, so it must be stateless and horizontally scaled, with nothing in it but cross-cutting concerns. Business logic in the gateway is the anti-pattern to name.

8. How do you debug a request across 12 services?

Answer: the observability trio: distributed tracing (one trace ID propagated via headers — Micrometer Tracing/OpenTelemetry — so you see the request's full path and where the 2 seconds went), centralized logging (ELK/Loki — grep one place, not 12 machines), metrics + alerts (RED: rate, errors, duration per service). The interview signal: you reach for the trace ID before anything else.

9. How is configuration managed?

Answer: externalized per environment — Spring Cloud Config server or Kubernetes ConfigMaps/Secrets; never bake environment values into the artifact. Secrets come from a vault (HashiCorp Vault, cloud secret managers), never git. Config changes shouldn't require a redeploy.

In this series

  1. Java 17 to 21 Interview Questions: Records, Pattern Matching, Virtual Threads — records, pattern matching, virtual threads.
  2. Spring Boot Interview Questions and Answers (2026 Edition) — auto-configuration to actuators.
  3. Java Multithreading and Concurrency Interview Questions: Deep Dive — volatile, locks, deadlocks, pools.
  4. Microservices Interview Questions for Java Developers (this post) — decomposition, resilience, sagas.

More: Java Interview Prep hub — the full collection of Java interview questions on JavaMakeUse.

Comments

Popular posts from this blog

Java Banking Finance Services and Insurance (BFSI) domain interview questions

JSP Servlet Interview Questions For Freshers Series 1

Java program to check even or odd number