Spring Cloud Research & Evidence-Based Practice 2 — Questions and Answers
Question 1: When benchmarking Spring Cloud Gateway versus Zuul 1, which characteristic does empirical testing most consistently show?
- Zuul 1 handles more concurrent connections due to blocking I/O
- Spring Cloud Gateway achieves lower latency under high concurrency because it uses non-blocking Netty (Correct answer)
- Zuul 1 and Gateway perform identically under production load
- Spring Cloud Gateway uses more CPU per request than Zuul 1
Correct answer: Spring Cloud Gateway achieves lower latency under high concurrency because it uses non-blocking Netty
Spring Cloud Gateway is built on Project Reactor and Netty (non-blocking), which benchmark data consistently shows outperforming Zuul 1's blocking servlet model under high concurrency.
Question 2: A team evaluates Spring Cloud Config Server versus HashiCorp Vault for secrets management. What does evidence-based guidance highlight as their primary distinction?
- Config Server natively encrypts all properties at rest, making Vault redundant
- Vault is purpose-built for secret lifecycle management with dynamic secrets and leasing, while Config Server targets general externalized configuration (Correct answer)
- Config Server integrates only with Git backends, so Vault is required for all other sources
- Vault cannot serve Spring Boot applications without a custom Config Server adapter
Correct answer: Vault is purpose-built for secret lifecycle management with dynamic secrets and leasing, while Config Server targets general externalized configuration
Vault specializes in secret lifecycle management (dynamic secrets, leases, revocation), whereas Spring Cloud Config Server focuses on externalized general configuration management.
Question 3: Research into distributed-tracing adoption indicates that which Spring Cloud Sleuth behavior most commonly causes unexpected overhead when moving from development to production?
- Sleuth propagates trace context, but the default sampling rate of 1.0 used in testing floods the tracing backend in production (Correct answer)
- Sleuth replaces log4j2 entirely, causing classpath conflicts
- Sleuth requires a dedicated JVM agent and cannot run in-process
- Sleuth only works with Zipkin and cannot export to Jaeger
Correct answer: Sleuth propagates trace context, but the default sampling rate of 1.0 used in testing floods the tracing backend in production
A 100% sampling rate acceptable in development generates enormous trace volumes in production, so best practice is to lower it via spring.sleuth.sampler.probability.
Question 4: Evidence from Netflix's original Hystrix research led to which key insight about designing fallback strategies?
- Fallbacks should always retry the same downstream service before returning a cached response
- Silent fallbacks returning null are preferable to throwing exceptions
- Fallbacks should degrade gracefully by returning meaningful cached or default data rather than propagating failure (Correct answer)
- Fallbacks should trigger a full JVM restart to clear corrupted state
Correct answer: Fallbacks should degrade gracefully by returning meaningful cached or default data rather than propagating failure
Netflix's research showed that graceful degradation via meaningful fallback responses prevents cascading failures better than propagating errors or returning silent null values.
Question 5: When load-testing a Spring Cloud microservices system, which approach yields the most production-representative results?
- JMeter targeting individual service instances directly, bypassing Spring Cloud LoadBalancer
- Gatling or k6 combined with service-discovery-aware clients to mirror production routing (Correct answer)
- Apache Bench for its built-in Spring Cloud integration
- Manual curl scripts run in a loop
Correct answer: Gatling or k6 combined with service-discovery-aware clients to mirror production routing
Gatling or k6 can model realistic user journeys, and pairing them with discovery-aware routing mirrors how requests flow in production, giving more actionable benchmark results.
Question 6: A post-mortem reveals that a Spring Cloud Bus broadcast caused a configuration refresh storm. What evidence-based mitigation addresses the root cause?
- Disable Spring Cloud Bus entirely and restart services manually
- Use destination-filtered refreshes and stagger refresh events to avoid simultaneous restarts across all instances (Correct answer)
- Increase the message broker partition count to absorb the storm
- Switch from RabbitMQ to Kafka, as Kafka prevents broadcast storms by design
Correct answer: Use destination-filtered refreshes and stagger refresh events to avoid simultaneous restarts across all instances
Destination-filtered refreshes and staggered rollout prevent all service instances from simultaneously reloading configuration and saturating the config server or broker.
Question 7: Research into Spring Cloud Stream consumer group behavior shows that what happens when multiple service instances share the same consumer group on a topic?
- Every instance receives every message, ensuring no message is lost
- Messages are load-balanced so each message is processed by exactly one instance in the group (Correct answer)
- The first registered instance becomes the sole consumer and others are idle
- Consumer groups in Spring Cloud Stream are purely a naming convention with no routing effect
Correct answer: Messages are load-balanced so each message is processed by exactly one instance in the group
A consumer group maps to the competing consumer pattern: each message is delivered to exactly one instance in the group, enabling horizontal scaling without duplicate processing.
Spring Cloud Research & Evidence-Based Practice 2
When benchmarking Spring Cloud Gateway versus Zuul 1, which characteristic does empirical testing most consistently show?