Spring Cloud Interview Questions

Knowing where a dependency currently lives (services move/restart), handling a partially-failed or slow network call, keeping configuration consistent across many services, tracing one request across service boundaries, and keeping data consistent when a business operation spans multiple databases — none of these exist when everything is one process with one call stack and one database transaction.

Many — it's an umbrella project bundling independently-developed tools (Eureka originated at Netflix, Resilience4j is its own library) under Spring Boot's familiar starter-dependency and auto-configuration conventions, so each one feels like 'add a starter, add some properties' rather than a new paradigm per tool.

Config Server only serves configuration to services on their next startup by default — already-running instances already fetched their config and won't re-fetch it automatically, which is exactly why @RefreshScope and a manual or Config-Bus-triggered refresh exist.

Manually refreshing every instance of every service one at a time doesn't scale past a handful of services — Spring Cloud Bus connects every instance to a shared message broker so one refresh trigger fans out to every connected instance automatically.

A container restart, autoscaling event, or rescheduling gives a service instance a brand new address — a hardcoded URL becomes stale the moment that happens, silently calling a dead endpoint until someone notices and redeploys with the new address.

A hardware load balancer sits centrally, with every request funneling through one device; client-side load balancing has each CALLING service pick a healthy instance itself, using its own current view of the service registry, removing the central device as both a bottleneck and single point of failure.

Not a hardcoded URL — that name is looked up through service discovery (Eureka) and resolved to one of the currently-healthy registered instances via client-side load balancing, entirely transparent to the code making the call.

It ties up the calling thread indefinitely if the downstream service is slow but not crashed — under real concurrent load, this exhausts the caller's own thread pool, turning one slow downstream dependency into a cascading outage of the caller too.

OpenFeign returns the actual response object directly, blocking the calling thread until it arrives. WebClient returns a Mono/Flux — a reactive publisher representing a value that WILL arrive — releasing the calling thread immediately instead of holding it idle during the network round-trip.

At high concurrency, where a thread-per-call blocking model would need thousands of threads just to stay idle waiting on network I/O; at typical low-to-moderate concurrency, the thread cost is invisible and OpenFeign's simpler, sequential code usually wins on readability.

It tells the Gateway to resolve order-service through service discovery and client-side load balancing, rather than pointing at one hardcoded address — the same discovery mechanism used by Feign and WebClient elsewhere in this category.

A Gateway filter can validate a JWT once, centrally, before a request ever reaches any backend service, instead of duplicating identical validation logic across every single downstream service — a cross-cutting concern handled once at the edge rather than N times.

Every caller keeps sending requests and waiting, one thread per in-flight call — under real load, the CALLERS exhaust their own thread pools waiting on a service that was never going to respond in time, spreading the failure to services that were themselves perfectly healthy.

CLOSED (normal, failures counted), OPEN (calls fail fast without even attempting the downstream call), and HALF_OPEN (a limited number of test calls check for recovery). The transition to OPEN happens once the failure rate over a sliding window crosses a configured threshold.

If the first attempt actually succeeded downstream but the response was lost (making it LOOK like a failure to the caller), retrying re-executes the operation a second time — for something like 'charge this card,' that means charging the customer twice.

It isolates each downstream dependency into its own limited pool of concurrent calls (usually its own thread pool), named after a ship's bulkheads — physical compartments that keep water from one flooded section from sinking the whole vessel — so one hung dependency exhausts only ITS allocated capacity, not the whole application's.

A correlation ID only helps within one service's own log lines — once a request crosses a network call into another service, that ID needs to be propagated in an HTTP header to survive the boundary, otherwise each service's logs become an isolated island with no way to reconstruct the full request path.

A trace is the entire end-to-end journey of one request across every service it touched; a span is one unit of work within that journey — one service's handling of it, or one significant sub-operation — with the trace ID tying every span in the same journey together.

@Transactional guarantees atomicity within ONE database connection — it has no mechanism for guaranteeing that a write in one service's database and a write in a completely separate service's database either both happen or neither does.

It requires every participant to hold locks from the Prepare phase until Commit completes — if the coordinator itself crashes in between, participants can be left holding locks indefinitely, and it also requires every participating data store to support the same distributed-transaction protocol, which most NoSQL stores and message brokers don't.

It breaks a business operation into a sequence of independent LOCAL transactions, each fully committing on its own, with an explicit compensating transaction defined for each step to undo it if a later step in the sequence fails.

In choreography, each service reacts to events and decides its own next action with no central coordinator — loosely coupled but harder to trace as steps grow. In orchestration, one central orchestrator explicitly tells each service what to do — centrally visible, but the orchestrator itself becomes a critical, more tightly-coupled component.

A normalized relational schema prevents duplicate or inconsistent data, which is exactly right for writes — but a read pattern needing a denormalized, aggregated view across several joined tables on every page load fights against that same normalized structure, since the shape correct for writing often isn't the shape needed for reading.

The read side becomes eventually consistent with the write side — the moment a command commits, the write side is immediately consistent, but the read model only updates once its triggering event has propagated and been processed, a real non-zero delay that needs to be a deliberate, communicated trade-off.

An immutable, append-only sequence of every state-changing event that happened to that entity — current state is never stored directly, it's derived by replaying all of those events in order.

Replaying tens of thousands of accumulated events to reconstruct one long-lived entity's current state on every single read becomes a real performance problem as history grows — a periodic snapshot lets a later read replay only events AFTER that snapshot instead of from the very beginning.

setStatus(SHIPPED) is idempotent — calling it repeatedly always leaves the status as SHIPPED. incrementStock(-1) is NOT — calling it twice decrements stock twice, producing a different end result than calling it once.

The caller attaches a unique key to the request, and the server remembers which keys it has already fully processed — a retried request carrying the SAME key returns the already-completed result directly instead of re-executing the operation (like a payment charge) a second time.

Resilience4j's Circuit Breaker trips after enough recent failures and fails fast instead of piling up waiting threads; the Bulkhead ensures only that dependency's allocated capacity is affected, not the whole application's — together they let the calling services stay healthy even while the one dependency struggles.

Running a Config Server, a Eureka instance, and tuning circuit breaker thresholds all carry real ongoing operational cost — that cost needs to be weighed against the actual failure modes a small, low-traffic system will realistically encounter, not applied reflexively just because the patterns exist.