Spring Boot Interview Questions for 5 Years Experience

By five years, a Spring Boot interview is an architecture interview wearing a framework label. This set covers what a senior engineer must lead on — microservices boundaries, resilience, security, distributed transactions and observability — each with an architect-level answer, code where it clarifies, and the follow-up that tests whether you have actually run systems in production.

Why the questions change at 5 years

At five years you are expected to own design decisions, not just implement them. The interviewer wants to see you decompose a domain, weigh synchronous against asynchronous communication, and name what breaks at scale before it breaks.

So the questions are open-ended and trade-off heavy. There is rarely one right answer — there is your answer and how well you defend it against failure modes. A senior candidate volunteers the downsides of their own choice.

Expect three arcs: system decomposition and communication, resilience and security, and operability. Framework fluency is assumed; the microservices architecture explained tutorial and the 3-years experience set are the floor you build on here.

How to answer at senior level

Structure system answers as: clarify requirements, propose a design, name the failure modes, and state the trade-off you accepted. Interviewers are grading your reasoning process more than the final diagram.

Ground every claim in something you have operated. "We used a saga because a distributed transaction across payments and inventory was not possible, and we made each step idempotent after a duplicate-charge incident" is the kind of answer that ends the round early.

Q1. How do you decide microservices boundaries?

Draw boundaries around business capabilities and DDD bounded contexts, so each service owns its data and changes for a single reason. Avoid splitting by technical layer or so finely that one feature touches many services.

A good boundary means a team can deploy a service without coordinating with others. The classic mistake is the distributed monolith: services that must be released together because they share a database or chatty synchronous calls.

Interview note: Follow-up: "how do you know a boundary is wrong?" When a single change repeatedly spans multiple services, or two services must always deploy together — that is a seam in the wrong place.

Q2. Synchronous or asynchronous communication — how do you choose?

Use synchronous REST or gRPC when the caller needs an immediate answer and can tolerate the callee's availability. Use asynchronous messaging (Kafka, RabbitMQ) for events, decoupling, and when the caller should not block or fail because a downstream service is down.

Synchronous chains couple availability: if service C is down, A and B fail too. Events break that coupling at the cost of eventual consistency and harder debugging.

Interview note: Trap: "your checkout calls five services synchronously — what is the availability?" It multiplies; each dependency lowers overall availability, which argues for async or fewer hops.

Q3. How do you handle transactions across services?

You cannot hold a database transaction across services, so you use the saga pattern: a sequence of local transactions, each publishing an event, with compensating transactions to undo previous steps on failure. Choreography uses events; orchestration uses a coordinator.

// Orchestrated saga step (simplified)
public void handle(OrderCreated e) {
    try {
        payment.charge(e.orderId(), e.amount());
        inventory.reserve(e.orderId());
    } catch (Exception ex) {
        payment.refund(e.orderId()); // compensating action
    }
}

Idempotency and eventual consistency are the core concerns. Study the pattern in depth and drill it in the microservices design patterns interview set.

Interview note: Follow-up: "choreography vs orchestration — which and why?" Choreography is decoupled but hard to trace; orchestration centralizes the flow at the cost of a coordinator. Pick based on how complex the workflow is.

Q4. How do you make a service resilient with Resilience4j?

Combine a circuit breaker to stop calling a failing dependency, retries with exponential backoff for transient faults, timeouts so calls cannot hang, bulkheads to isolate resource pools, and fallbacks for graceful degradation.

@CircuitBreaker(name = "pricing", fallbackMethod = "cachedPrice")
public Price getPrice(String sku) { return pricingClient.fetch(sku); }

public Price cachedPrice(String sku, Throwable t) {
    return priceCache.get(sku); // degrade gracefully
}

The point is preventing cascade: one slow dependency should not exhaust threads and take down the whole service. See the circuit breaker pattern tutorial.

Interview note: Trap: "retries make things more reliable — always?" No — retrying a non-idempotent call or a genuinely overloaded service amplifies load and can cause a retry storm.

Q5. How is authentication and authorization done in a microservices system?

Use stateless JWTs issued by an OAuth2/OpenID Connect provider, validated at the API gateway and again at each service. Authorize with roles or scopes via Spring Security. Service-to-service calls use mutual TLS or signed service tokens.

Stateless tokens avoid a shared session store and scale horizontally. The gateway does coarse checks; each service still enforces its own authorization because you never trust the network.

Interview note: Follow-up: "where do you validate the JWT — gateway or service?" Both. The gateway rejects obviously bad requests early; each service re-validates because zero-trust means never assuming an upstream did it.

Q6. How do you achieve observability across services?

Instrument the three pillars: metrics with Micrometer and Prometheus, centralized structured logs, and distributed tracing that propagates a correlation/trace id across every hop. Actuator health endpoints feed readiness and liveness probes.

Without a trace id threaded through logs, debugging a request that touched six services is guesswork. Correlation ids turn a scattered incident into a single timeline.

Interview note: Trap: "logs show an error but you cannot tell which request caused it — what was missing?" A correlation id propagated from the entry point through every downstream call.

Q7. What is an API gateway and why use one?

A gateway is the single entry point that routes requests to services and centralizes cross-cutting concerns: authentication, rate limiting, request aggregation and TLS termination. It keeps those concerns out of every individual service.

It also decouples clients from the internal topology — services can move or split without clients knowing. The risk is making the gateway a bottleneck or a new monolith of logic, so keep business rules out of it.

Interview note: Follow-up: "what should NOT live in the gateway?" Business logic — it belongs in services; the gateway handles routing and cross-cutting policy only.

Q8. How do you handle configuration and secrets at scale?

Externalize configuration with a config server or the platform's config maps, use profiles per environment, and keep secrets in a vault with short-lived credentials — never in properties files or images.

At senior level you should mention rotation and least privilege: a leaked long-lived database password is a breach; short-lived, rotated credentials limit the blast radius.

Interview note: Trap: "the DB password is in application-prod.properties in Git — what is wrong?" Secrets in source control are a security incident waiting to happen; move them to a secrets manager and rotate the exposed one.

Q9. How do you design for data consistency without distributed transactions?

Accept eventual consistency, model workflows as sagas with compensations, make consumers idempotent so duplicate events are safe, and use the outbox pattern so a database change and its event are published atomically.

// Outbox: write the event in the same local transaction as the state change
@Transactional
public void placeOrder(Order o) {
    orderRepo.save(o);
    outboxRepo.save(new OutboxEvent("OrderPlaced", o.getId()));
}

A relay then publishes outbox rows to the broker, guaranteeing the event is sent exactly when the state change committed.

Interview note: Follow-up: "why the outbox instead of publishing after commit?" Publishing after commit can lose the event if the app crashes between commit and publish; the outbox makes them atomic.

Q10. How do you version and evolve APIs without breaking clients?

Prefer backward-compatible changes: add fields, never remove or repurpose them. When a breaking change is unavoidable, version the API (URI or header) and run old and new in parallel until clients migrate.

For events, use a schema registry and tolerant readers so consumers ignore unknown fields. The senior insight is that in a distributed system you can never deploy all clients at once, so compatibility is mandatory.

Interview note: Trap: "you renamed a JSON field in the response — safe?" No — that is a breaking change; old clients break. Add the new field and deprecate the old one instead.

Q11. How do you roll out changes safely in production?

Use rolling or canary deployments behind health checks, feature flags to decouple deploy from release, and database migrations that are backward compatible (expand-then-contract) so old and new versions run simultaneously.

The expand-contract pattern — add a column, deploy code that writes both, backfill, then drop the old — lets you migrate schema without downtime while both app versions are live.

Interview note: Follow-up: "you must rename a column with zero downtime — how?" Expand (add new column, write both), migrate reads, then contract (drop old) in a later release — never a single rename.

Q12. When are microservices the wrong choice?

When the team is small, the domain is not well understood, or the operational maturity (CI/CD, monitoring, on-call) is not there. A well-structured modular monolith is often faster and cheaper until scale or team size genuinely demands splitting.

The senior signal here is restraint: recommending microservices reflexively is a red flag. Naming when not to use them shows you have felt their operational cost. Rehearse the trade-offs in the microservices architecture interview set.

Interview note: Trap: "we have 4 engineers and want microservices — advise them." Usually no — the coordination and operational overhead will outweigh the benefits at that size; start modular.

How to prepare

Prepare two or three systems you have worked on as design case studies: draw the services, the data ownership, the failure modes, and one decision you would now make differently. Senior interviews reward honest reflection over polished perfection.

Split prep across decomposition and communication, resilience and security, and operability — and rehearse thinking out loud, because the process is what is graded. Pair this with the microservices architecture and design-patterns interview sets, and revisit the service-level depth these system questions assume. The Java Full Stack with AI course builds from that foundation toward the architecture reasoning senior roles demand.