Spring Boot vs Spring Cloud — What's the Difference?
Fast recall
Quick revision
Core answer
Whether you understand Spring Cloud is a set of opinionated solutions to common distributed-systems problems, layered on Spring Boot — not a replacement
Reaching for Spring Cloud (Eureka, Config Server, Gateway) when the system has only 1-3 services, adding operational complexity that delivers no benefit
Mention the deprecation of Netflix OSS components (Hystrix, Ribbon, Zuul) in favor of Resilience4j, Spring Cloud LoadBalancer, and Spring Cloud Gateway — and the platform-native alternatives (Kubernetes Service, ConfigMap, Istio) that often replace Spring Cloud entirely
Interview-ready guide
Interview answer
Spring Boot is for building one application; Spring Cloud is for wiring many Boot applications into a distributed system. You always use Spring Cloud through Boot — never standalone.
What Boot owns
- Auto-configuration, embedded server, starter POMs, Actuator
- Everything to take a single service from
main()to production
What Cloud adds on top
- Service discovery: Eureka, Consul, Zookeeper — services register and look each other up by name
- Centralized config: Config Server pulls properties from Git, refreshable at runtime via
/actuator/refresh - Client-side load balancing: Spring Cloud LoadBalancer with
@LoadBalancedRestClient.Builder - API gateway: Spring Cloud Gateway for routing, auth, rate limiting at the edge
- Resilience: Resilience4j for circuit breaker, retry, bulkhead, rate limiter
- Distributed tracing: Micrometer Tracing propagates trace IDs across services to OpenTelemetry/Zipkin
When Cloud is justified
- 5+ services with dynamic scaling — needs discovery
- Config that must change without a redeploy — needs Config Server
- Calls between services that must survive transient failures — needs circuit breaker
- 1-3 services — properties file and hardcoded URLs are simpler
The deprecation story
- Netflix OSS components (Hystrix, Ribbon, Zuul) are end-of-life
- Replaced by Resilience4j, Spring Cloud LoadBalancer, Spring Cloud Gateway respectively
Platform-native alternative
- In Kubernetes, Service provides discovery, ConfigMap provides config, Istio provides resilience and tracing
- Spring Cloud Kubernetes bridges Boot apps to those primitives — many shops skip Eureka and Config Server entirely
In an interview, I'd close with: don't reach for Spring Cloud until you actually have a distributed system. It's the right tool for the right problem; using it on a 2-service deployment is operational complexity for no payoff.
Spring Boot vs Spring Cloud — What's the Difference
Direct Answer
Spring Boot is for building a single application; Spring Cloud is for wiring many Boot apps into a distributed system. Boot gives you auto-configuration, embedded servers, and starter POMs to ship one service. Spring Cloud adds the distributed-systems patterns on top: service discovery (Eureka, Consul), client-side load balancing (Spring Cloud LoadBalancer), centralized configuration (Config Server), API gateway (Gateway), circuit breakers (Resilience4j), and distributed tracing (Micrometer Tracing). You always use Spring Cloud through Spring Boot — never as a standalone framework. Cloud's value appears only when you have 5+ services that need to find each other, share config, and survive partial failures.
Common Mistakes & Pitfalls
Reaching for Spring Cloud (Eureka, Config Server, Gateway) when the system has only 1-3 services, adding operational complexity that delivers no benefit
Check your understanding
Answer these without looking back at the article.
- How does Spring Cloud Config Server propagate property changes to running services?
- What replaced Hystrix in modern Spring Cloud stacks, and how does it differ?
- When would you use Spring Cloud Gateway vs an external API gateway like Kong or AWS API Gateway?
- How does `@LoadBalanced` integrate with Eureka or Kubernetes discovery?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.