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
- Java 17 to 21 Interview Questions: Records, Pattern Matching, Virtual Threads — records, pattern matching, virtual threads.
- Spring Boot Interview Questions and Answers (2026 Edition) — auto-configuration to actuators.
- Java Multithreading and Concurrency Interview Questions: Deep Dive — volatile, locks, deadlocks, pools.
- 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
Post a Comment