Microservices Interview Questions Java Spring Boot 2026
Picture this: you’ve cleared the DSA round, the interviewer smiles, and then says — “Tell me how you’d design an order service that talks to inventory and payment without them going down together.” That’s a microservices question. And if you haven’t thought it through, you’ll ramble. I’ve watched dozens of candidates do exactly that, on both sides of the table.
⏱️ 9 min read | 📚 Updated June 2026
💡 Quick Tip: Need fast answers? Jump directly to the FAQ section below.
This guide is for Java developers — whether you’re at 2 years of experience or 8 — who are targeting product companies, EPAM, or even the digital transformation wings of TCS and Infosys. By the end, you’ll be able to answer questions on service discovery, API gateways, circuit breakers, the saga pattern, and general resilience strategies with enough depth to survive a senior-engineer-level drill-down.
Everything here is Java + Spring Boot (3.x on Java 17/21 unless stated). Let’s get into it.
Table of Contents
- What Interviewers Are Actually Testing
- How the Rounds Typically Go
- Core Concepts With Code
- Common Wrong Answers and the Fixes
- A Realistic Prep Plan
- Frequently Asked Questions
What Interviewers Are Actually Testing
Microservices questions are rarely trivia. When an interviewer at EPAM or a funded startup asks “what is a circuit breaker?”, they don’t want a Wikipedia paragraph. They want to know if you’ve felt the pain of a downstream service timing out and taking your whole app with it. The follow-up will be: “Show me how you’d configure Resilience4j in Spring Boot 3.” If you can’t, the definition meant nothing.
At TCS and Infosys, the questions tend to be broader — architecture diagrams, 12-factor app principles, Docker/Kubernetes basics. At EPAM and product startups, expect whiteboard design sessions and code. Know your audience, but prepare for depth everywhere — companies are raising the bar in 2025-26 because cloud-native Java roles have exploded.
The five pillars I see tested consistently: service discovery, API gateway routing, circuit breaking, distributed transactions (saga), and overall resilience. Nail these and you’re ahead of 70% of candidates.
How the Rounds Typically Go
| Round | Duration | Topics | Difficulty |
|---|---|---|---|
| Technical Screen | 30-45 min | Spring Boot basics, REST, basic microservices theory | Medium |
| Architecture / Design | 60 min | Service decomposition, saga, API gateway, event-driven design | High |
| Coding Round | 45-60 min | Resilience4j config, Feign client, async messaging sketch | Medium-High |
| Managerial / HR | 30 min | Past microservices projects, failure scenarios, team dynamics | Low-Medium |
Core Concepts With Code
1. Service Discovery with Eureka
Service discovery lets microservices find each other without hardcoded URLs. Spring Cloud Netflix Eureka is still common in enterprise Java shops. A service registers itself on startup; other services query the registry by name.
// In the Eureka Server application
@SpringBootApplication
@EnableEurekaServer // turns this app into the registry
public class DiscoveryServerApplication {
public static void main(String[] args) {
SpringApplication.run(DiscoveryServerApplication.class, args);
}
}
Any client service just adds @EnableDiscoveryClient and sets eureka.client.service-url.defaultZone in its application.yml. Spring Cloud then uses the registry to resolve http://ORDER-SERVICE/api/orders to a real IP. The interviewer follow-up: “What happens if Eureka itself goes down?” Answer — clients cache the registry locally; they can still call each other for a while, but new registrations fail. That’s a real production answer.
For deeper Spring Cloud patterns, see our Java advanced topics guide.
2. API Gateway with Spring Cloud Gateway
The API gateway is the single entry point. It handles routing, authentication, rate limiting, and sometimes load balancing. Spring Cloud Gateway (built on Project Reactor, non-blocking) replaced the old Zuul in modern Spring Boot 3.x apps.
// application.yml — route config for Spring Cloud Gateway
spring:
cloud:
gateway:
routes:
- id: order-route
uri: lb://ORDER-SERVICE # lb:// = load-balanced via discovery
predicates:
- Path=/api/orders/**
filters:
- StripPrefix=1 # removes /api before forwarding
- name: CircuitBreaker
args:
name: orderCB
fallbackUri: forward:/fallback/orders
Notice the CircuitBreaker filter sitting right in the gateway config. That’s intentional — the gateway is a great place to apply cross-cutting resilience. The interviewer will then ask: “Isn’t putting circuit breakers at the gateway enough?” The nuanced answer: gateway-level CBs protect the caller, but each service should also have its own — because service-to-service calls (not just client-to-gateway) need protection too.
3. Circuit Breaker with Resilience4j
Resilience4j is the go-to library in Spring Boot 3.x (Hystrix is end-of-life). The circuit breaker has three states: CLOSED (normal), OPEN (failing fast), HALF_OPEN (testing recovery). This is probably the single most-asked deep-dive in 2025-26 interviews.
@Service
public class InventoryClient {
@CircuitBreaker(name = "inventoryCB", fallbackMethod = "fallbackStock")
@TimeLimiter(name = "inventoryCB") // pairs CB with a timeout
public CompletableFuture getStock(String productId) {
// calls downstream Inventory Service via Feign or RestTemplate
return CompletableFuture.supplyAsync(() -> inventoryFeignClient.getStock(productId));
}
// fallback: same signature + Throwable parameter
public CompletableFuture fallbackStock(String productId, Throwable t) {
return CompletableFuture.completedFuture(-1); // sentinel: "unknown stock"
}
}
Configure thresholds in application.yml: slidingWindowSize: 10, failureRateThreshold: 50, waitDurationInOpenState: 10s. The interviewer will ask what happens when the circuit is OPEN — your service returns the fallback immediately without waiting for a timeout. That’s the whole point: fail fast, recover gracefully.
Pro tip: Always pair
@CircuitBreakerwith@TimeLimiterin Resilience4j. A circuit breaker alone won’t save you from a downstream service that hangs indefinitely — you need the timeout to actually trigger the failure count.
4. The Saga Pattern for Distributed Transactions
This is the question that separates mid-level from senior candidates. You cannot use a traditional ACID transaction across microservices — each service owns its own database. The saga pattern coordinates a multi-step workflow by breaking it into local transactions, each publishing an event or message.
There are two flavors: Choreography (services react to events, no central coordinator — works well for simple flows) and Orchestration (a saga orchestrator, like Camunda or a custom Spring state machine, tells each service what to do). For an Order → Payment → Inventory flow, orchestration is easier to reason about in interviews because you can draw a clear sequence diagram.
The key thing to explain: each step must have a compensating transaction. If Payment succeeds but Inventory fails, you must trigger a “refund” event back on Payment. Interviewers love asking “what if the compensating transaction also fails?” — answer: idempotent retries with an outbox pattern and dead-letter queues. That level of detail will make you memorable.
See our advanced Java architecture patterns for more on event-driven design.
5. Resilience Beyond Circuit Breakers
Resilience is broader than just circuit breakers. Interviewers at product companies will probe all of these:
- Retry with backoff — Resilience4j’s
@Retrywith exponential backoff + jitter to avoid thundering herd - Bulkhead — isolate thread pools so a slow downstream doesn’t exhaust your whole service’s threads
- Rate Limiter — protect your own service from being overwhelmed by callers
- Timeouts — always set connection AND read timeouts on your HTTP clients; never use defaults
- Health checks — Spring Boot Actuator’s
/actuator/healthwith custom indicators for Kubernetes liveness/readiness probes
Pro tip: In interviews, frame resilience as a layered strategy — timeout → retry → circuit breaker → fallback. Each layer catches what the previous missed. If you say “we just added a circuit breaker,” it signals you haven’t thought about the full failure spectrum.
Common Wrong Answers and the Fixes
| Wrong Answer | Why It’s Wrong | Correct Answer |
|---|---|---|
| “Use @Transactional across services” | Two-phase commit doesn’t scale; tight coupling defeats microservices | Use the saga pattern with compensating transactions |
| “Eureka is the only service discovery option” | Shows narrow knowledge | Consul and Kubernetes native DNS are common alternatives |
| “Circuit breaker = retry” | Completely different mechanisms | CB stops calls when failure rate crosses threshold; retry attempts the call again |
| “API gateway just does routing” | Undersells it — interviewers want cross-cutting concerns | Auth, rate limiting, circuit breaking, response caching, request tracing |
A Realistic Prep Plan
Two weeks is enough if you’re already comfortable with Spring Boot basics. Here’s how I’d split it:
- Days 1-3: Build a tiny two-service app (Order + Inventory) with Eureka and a Feign client. Don’t read — build. You’ll hit real problems and remember the fixes.
- Days 4-6: Add Spring Cloud Gateway with routing and a circuit breaker filter. Add Resilience4j with
@CircuitBreaker+@Retryto the Feign client. - Days 7-9: Implement a simple choreography saga using Spring Events or Kafka (even a local embedded Kafka). Sketch the compensating transaction on paper.
- Days 10-12: Read the official Spring Cloud Circuit Breaker docs and the Resilience4j getting-started guide. Fill the gaps.
- Days 13-14: Mock interview yourself. Answer “design an e-commerce checkout flow with microservices” out loud. Record it. Watch it. Cringe. Improve.
Check our premium interview prep resources if you want curated mock questions with model answers for system design rounds.
Frequently Asked Questions
What’s the difference between choreography and orchestration in the saga pattern?
In choreography, each service listens to events and reacts independently — no central brain. In orchestration, a dedicated saga orchestrator (a separate service or workflow engine) sends commands to each participant and tracks state. Choreography is simpler for short flows; orchestration is easier to debug and audit for complex, multi-step transactions.
Is Hystrix still relevant for 2026 interviews?
Hystrix is officially in maintenance mode and shouldn’t be used in new projects. Mention it only if your current project uses it and you’re migrating. For any new Spring Boot 3.x work, Resilience4j is the answer — and interviewers at product companies will specifically ask which one you use to filter out outdated knowledge.
Do I need to know Kubernetes for microservices interviews?
You should know the basics — what a Pod, Service, and Deployment are — because they directly relate to service discovery and health checks. Deep Kubernetes expertise (Operators, Helm chart authoring) is a bonus, not a baseline for most Java developer roles.
How do I explain distributed tracing in an interview?
Say you use Spring Boot Actuator with Micrometer Tracing (Spring Boot 3.x replaced Sleuth with Micrometer), which propagates a trace ID across service calls via HTTP headers. Mention Zipkin or Jaeger as the backend collector. The key insight interviewers want: without trace correlation, debugging a failure across five services is nearly impossible in production.
What is the outbox pattern and why does it matter?
The outbox pattern solves the “dual write” problem — you need to update your database AND publish a message atomically, but you can’t have a transaction across a DB and a message broker. Instead, you write the message to an “outbox” table in the same DB transaction, and a separate process (like Debezium) reads and publishes it. This guarantees at-least-once delivery without distributed transactions.
Can the API gateway become a single point of failure?
Yes, and interviewers expect you to address this. The fix is running multiple gateway instances behind a load balancer (Nginx or a cloud LB), with stateless configuration so any instance can handle any request. Spring Cloud Gateway is reactive and handles high concurrency well, but you still need horizontal scaling and circuit breakers on the gateway’s own outbound calls.
