Spring Cloud, Observability & Distributed Tracing — Interview Questions

How to use this lesson

Many Spring Cloud interview questions still mention Netflix OSS (Zuul, Ribbon, Hystrix) and Sleuth. Answer with what they did, and what replaced them:

• Gateway, LoadBalancer, Resilience4j;
• Micrometer Tracing + OpenTelemetry.

That shows you've actually run Boot 3 in production.

Q1. How does Spring Cloud Config work, and how is it different from application.yml?

Short answer:

• application.yml is packaged with each service, or mounted per instance. Changes mean redeploying, or editing each environment separately, and there's no central audit trail.
• Spring Cloud Config is a central configuration server backed by Git (or Vault, JDBC, S3). Clients import it at startup (spring.config.import=configserver:http://config:8888), and receive properties for their application name + profile + label (branch or tag):
  • orders-service-prod.yml, layered over application.yml shared by all services;
  • versioned and auditable through Git history;
  • with encrypted values ({cipher});
  • and refreshable at runtime (/actuator/refresh, or Spring Cloud Bus broadcasting to all instances).

The trade-offs: another critical component to run (make it highly available, and make clients use optional: or fail-fast deliberately). On Kubernetes, ConfigMaps and Secrets (optionally with Spring Cloud Kubernetes) or GitOps often replace it.

Learn it in depth → Configuration Management

Q2. What is @RefreshScope in Spring Cloud Config for? What are the caveats?

Short answer: Beans in @RefreshScope are lazily re-created after a refresh event (POST /actuator/refresh, or a Bus event). The scope proxy discards the cached instance, so the next call builds a new one with the new property values. @ConfigurationProperties beans are rebound on refresh automatically, even without the scope.

The caveats:

• Proxies: refresh-scoped beans are proxied, so there's a small cost per call, and final classes don't work.
• Stateful beans lose their state on refresh (connection pools re-created, caches cleared).
• Not everything is refreshable: DataSource URLs, server ports and already-created infrastructure beans need restarts.
• Partial updates across instances: refresh through the Bus, or roll pods, so instances don't diverge.
• Thread-safety while the swap happens.

Many teams prefer rolling restarts (immutable configuration), and feature flags for runtime toggles.

Q3. How does Spring Cloud Gateway differ from Netflix Zuul?

Short answer:

• Zuul 1: blocking servlet-based (thread per request), with filters. It was removed from Spring Cloud (maintenance mode, then removed in the 2020.0 release train). Zuul 2 (non-blocking) was never integrated into Spring Cloud.
• Spring Cloud Gateway: built on Spring WebFlux, Reactor and Netty, so it's non-blocking. There's also a Gateway Server MVC variant, for servlet or virtual-thread stacks. It has:
  • route predicates (path, host, header, method, weight) and filters (rewrite, retry, circuit breaker, rate limiter, token relay, request size);
  • discovery integration (lb://service);
  • WebSocket and HTTP/2 support;
  • Java DSL or YAML configuration.

It's the recommended Spring-based API gateway.

Learn it in depth → API Gateway

Q4. How does Spring Cloud do client-side load balancing: Ribbon or LoadBalancer?

Short answer: Ribbon (Netflix) is deprecated, and removed from Spring Cloud. Its replacement is Spring Cloud LoadBalancer:

• A @LoadBalanced RestClient.Builder/RestTemplate/WebClient.Builder, or OpenFeign or HTTP interface clients, resolves http://inventory-service through a ServiceInstanceListSupplier (backed by discovery: Eureka, Consul, Kubernetes; with caching).
• It picks an instance with a ReactorServiceInstanceLoadBalancer: round-robin by default, random, or custom (zone preference, health checks, same-instance or sticky preference, weighted).
• It's configurable per client, through child contexts (@LoadBalancerClient(name = "inventory", configuration = ...)).

On Kubernetes, you often skip client-side balancing, and rely on Service or mesh load balancing instead.

Q5. How do Hystrix and Resilience4j compare for circuit breaking in Spring Cloud?

Short answer:

• Hystrix (Netflix): circuit breaking, with thread-pool isolation per dependency, and a dashboard. It's in maintenance mode, and removed from Spring Cloud.
• Resilience4j: the successor. It's lightweight and modular, built on functional composition. It provides CircuitBreaker (count- or time-based sliding windows, and slow-call thresholds), Retry, RateLimiter, Bulkhead (semaphore or thread-pool), TimeLimiter and caching. It integrates with Spring Boot annotations, Spring Cloud CircuitBreaker (an abstraction), Micrometer metrics, and reactive types.

The migration: replace @HystrixCommand(fallbackMethod) with @CircuitBreaker(name, fallbackMethod) plus the YAML configuration, and turn the thread-pool isolation into bulkheads where needed.

Learn it in depth → Circuit Breaker Pattern

Q6. How do you implement rate limiting in Spring Cloud Gateway?

Short answer: Use the built-in RequestRateLimiter filter, with RedisRateLimiter: a token bucket in Redis, run as a Lua script, shared across the gateway instances. It's configured with:

• replenishRate (tokens per second);
• burstCapacity;
• requestedTokens (the cost per request);
• a KeyResolver bean deciding whom to limit: the user ID from the JWT, an API key, a tenant, or the IP address.

When limited, it returns 429 Too Many Requests, with X-RateLimit-* headers.

spring:
  cloud:
    gateway:
      routes:
        - id: search
          uri: lb://search-service
          predicates: [ "Path=/api/search/**" ]
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 20
                redis-rate-limiter.burstCapacity: 40
                key-resolver: "#{@principalKeyResolver}"

@Bean KeyResolver principalKeyResolver() {
    return exchange -> exchange.getPrincipal().map(Principal::getName).defaultIfEmpty("anonymous");
}

Key points to cover:

• Tiered limits (per plan).
• Endpoint-specific costs.
• Decide how to behave when Redis is down (fail open or closed).
• Combine it with a WAF or CDN limits for DDoS-scale abuse.

Learn it in depth → Bulkhead & Rate Limiting

Q7. What was Spring Cloud Sleuth used for? What replaces it in Spring Boot 3? How did Sleuth add trace IDs to logs?

Short answer: Sleuth auto-instrumented Spring applications for distributed tracing:

• it created spans for incoming and outgoing HTTP calls, messaging and scheduled tasks;
• it propagated trace context in headers (B3, and later W3C);
• it put traceId/spanId into the logging MDC, so every log line carried them ([app,traceId,spanId]);
• it exported spans to Zipkin.

In Spring Boot 3, Sleuth isn't supported. Its core moved to Micrometer Tracing:

• micrometer-tracing-bridge-otel (OpenTelemetry) or -bridge-brave;
• plus an exporter (OTLP or Zipkin);
• driven by the Micrometer Observation API, so one instrumentation produces both metrics and traces;
• the MDC correlation is automatic (the logging.pattern.correlation property).

Common trap: the source says "the alternative is OpenTelemetry". More precisely, it's Micrometer Tracing, typically bridged to OpenTelemetry. (You can also use the OpenTelemetry Java agent directly.)

Q8. What is Micrometer Tracing in Spring Boot 3?

Short answer: A tracing facade (like SLF4J, but for tracing), used by Spring Boot 3's observability:

• The Observation API: Spring components (MVC, WebFlux, RestClient/WebClient, @Scheduled, Kafka, JDBC through datasource-micrometer, Spring Security, and so on) create observations, which produce timers (metrics) and spans (traces) with shared tags.
• Bridges choose the tracer (OpenTelemetry or Brave), and reporters or exporters send the spans (OTLP to a Collector → Tempo or Jaeger, or Zipkin).
• Configuration: management.tracing.sampling.probability, management.otlp.tracing.endpoint, and propagation types (W3C by default).
• Custom spans: @Observed on methods, or Observation.createNotStarted(...).observe(...).

@Observed(name = "pricing.quote", contextualName = "quote-price", lowCardinalityKeyValues = {"region", "IN"})
public Quote quote(String sku) { ... }                // produces the pricing.quote timer and a span

Q9. What are traceId and spanId, and what are they used for?

Short answer:

• traceId: a unique ID for one end-to-end request across all services (128-bit in W3C). Every span in that request shares it.
• spanId: the ID of one unit of work (an incoming request, a database call, an outgoing HTTP call), with a parent span ID that forms the call tree.

They travel between services in traceparent headers (W3C: 00-<traceId>-<spanId>-<flags>), including through message headers in Kafka.

Uses:

• correlate logs across services (search for one traceId);
• visualise the call tree and latency per hop in Tempo, Jaeger or Zipkin;
• find which service or database call is slow, or failing;
• link metrics exemplars to example traces;
• return the traceId to clients in error responses, for support.

Learn it in depth → Distributed Tracing

Q10. What is OpenTelemetry?

Short answer: OpenTelemetry (OTel) is the CNCF vendor-neutral standard for telemetry (traces, metrics and logs):

• APIs and SDKs for many languages;
• automatic instrumentation (the Java agent instruments common libraries without code changes);
• the OTLP protocol;
• the OpenTelemetry Collector (receives, processes, batches, samples, and exports to any backend: Tempo, Jaeger, Prometheus, Datadog, Elastic, Honeycomb);
• semantic conventions, for consistent attribute names.

In Spring Boot 3: use Micrometer Tracing with the OTel bridge plus the OTLP exporter, the OTel Java agent, or Spring Boot's OTLP metrics export. It avoids vendor lock-in: change the backend by changing the Collector's configuration.

Q11. How do you integrate Prometheus with Spring Boot?

Short answer:

1. Add micrometer-registry-prometheus (plus spring-boot-starter-actuator).
2. Expose the endpoint: management.endpoints.web.exposure.include=health,prometheus. Metrics appear at /actuator/prometheus, in the text format.
3. Prometheus scrapes it: on Kubernetes, through a ServiceMonitor/PodMonitor (Prometheus Operator), or scrape annotations. Secure it, or serve it on a separate management port.
4. Built-in metrics: JVM (memory, GC, threads), http.server.requests (with histograms and percentiles: management.metrics.distribution.percentiles-histogram.http.server.requests=true), HikariCP, Tomcat or Netty, cache, executor, Kafka and logback metrics.
5. Custom metrics: inject MeterRegistry, then Counter, Timer, Gauge, DistributionSummary, or @Timed/@Counted, with low-cardinality tags (never user IDs).
6. Common tags: management.metrics.tags.application=orders.
7. Dashboards and alerts: Grafana, plus Alertmanager rules on SLOs (latency, error rate, saturation).

Learn it in depth → Metrics & Monitoring

Q12. Logs vs metrics vs traces: what's the difference?

Short answer: They're the three pillars of observability:

• Metrics: numeric aggregates over time (request rate, error rate, p99 latency, CPU, queue lag). Cheap, long retention, and ideal for dashboards and alerting. They tell you that something is wrong. Keep the tag cardinality low.
• Traces: the path and timing of individual requests across services (spans). They tell you where the time or the failure is. They're sampled, because full volume is costly.
• Logs: discrete, detailed events with context (structured JSON). They tell you why: the error messages, and the business details. They're expensive at volume, and need retention and PII policies.

Correlate them: trace IDs in logs, exemplars linking metrics to traces, and shared service and version tags. The workflow is: a metrics alert → traces → logs. Continuous profiles are an emerging fourth pillar.

Q13. What are the best practices for centralised logging and tracing?

Short answer:

• Logging:
  • Structured JSON logs (Boot 3.4+ logging.structured.format.console=ecs|logstash) written to stdout.
  • Shipped by an agent (Fluent Bit, Vector, the OTel Collector) to ELK/OpenSearch, Loki, or a cloud service.
  • A consistent schema (service, environment, version, traceId/spanId, user or tenant hashes).
  • Log levels by environment. No secrets or PII (mask them).
  • Sample noisy logs.
  • Retention and cost controls.
  • Correlation IDs on messages and asynchronous flows.
• Tracing:
  • Instrument every hop (HTTP, messaging, databases), with W3C propagation.
  • Tail-based sampling in the Collector (keep the errors and slow traces).
  • Consistent span names and attributes (semantic conventions).
  • Link the traces to logs and metrics (exemplars).
  • Include external calls (payment providers) as client spans.
• Operations: dashboards per service (RED/USE metrics), SLO-based alerting, runbooks that link to trace searches, and access controls on log data.

Learn it in depth → Centralized Logging

Q14. What is Spring Cloud Stream?

Short answer: A framework for message-driven microservices, with a binder abstraction over brokers (Kafka, RabbitMQ, Kafka Streams, and cloud binders: Pub/Sub, Kinesis, Azure Event Hubs, Solace):

• The functional programming model: @Bean Function<In, Out>, Consumer<In> and Supplier<Out> beans, bound to destinations by configuration (spring.cloud.stream.bindings.process-in-0.destination=orders).
• The binder handles serialisation (content types), consumer groups, partitioning, retries and DLQs, and error channels.
• StreamBridge for dynamic publishing.

@Bean
Function<OrderPlaced, InvoiceRequested> invoice() {       // consumes from orders, produces to invoices
    return event -> new InvoiceRequested(event.orderId(), event.total());
}

The trade-off: portability and less boilerplate, against less direct access to broker-specific features. Teams often use Spring Kafka directly for Kafka-heavy systems, when they need fine control.

Q15. How do you implement a saga with Spring?

Short answer:

• Choreography: Spring Kafka or Spring Cloud Stream listeners in each service. Each service does its local transaction plus the outbox write, and a relay (Debezium, or a scheduled poller) publishes the events. Each service listens for the others' events, and runs its compensations on failure events. Consumers are idempotent (processed-event tables).
• Orchestration: an orchestrator service holding the saga state in a table (a Spring State Machine, or a hand-written state machine), which sends commands and consumes replies, with timeouts through @Scheduled scans or delayed messages. Or use a workflow engine with Spring Boot starters: Temporal, Camunda 8/Zeebe, or Axon (sagas plus event sourcing).
• The Spring building blocks:
  • @Transactional local transactions;
  • @TransactionalEventListener(AFTER_COMMIT) for in-process steps;
  • Spring Modulith's event publication registry (a persisted outbox for application events);
  • Spring Kafka transactions for consume-process-produce.
• Observability: a saga ID as the correlation ID in traces and logs, plus dashboards of the state counts (in progress, compensating, failed).

Learn it in depth → Saga Pattern

Follow-up questions this topic invites — and their answers

Q: How does trace context cross a Kafka boundary? A: The producer's observation writes traceparent into the record headers. The consumer's observation extracts it, and continues the trace (as a child or a linked span). Enable observation on KafkaTemplate and the listener containers.

Q: What's the risk of high-cardinality metric tags? A: Every unique tag combination creates a new time series. Tags like user ID or order ID explode memory and storage in Prometheus, and can take it down. Use bounded values (status code, endpoint template, region).

Q: Head-based vs tail-based sampling? A: Head-based sampling decides at the start of a trace (for example, 10%). It's cheap, but can miss rare errors. Tail-based sampling (in the Collector) decides after seeing the whole trace, so it can keep every error and slow trace, at the cost of buffering.

Q: Is Eureka still needed on Kubernetes? A: Usually not. Kubernetes Services, DNS and readiness-based endpoints provide discovery and load balancing. Eureka is still useful for hybrid VM/Kubernetes estates, or client-side zone-aware balancing.