How do you implement tracing in a microservices architecture?

Question

Accepted Answer

Distributed tracing tracks a single request as it flows across multiple microservices, giving visibility into latency and failures that span service boundaries.

Key Points:
• Spring Cloud Sleuth (or Micrometer Tracing in newer Spring Boot versions) automatically attaches a unique trace ID and span ID to each request as it enters the system.
• That trace ID propagates through HTTP headers on every downstream call, linking related spans together into one end-to-end trace.
• Zipkin (or Jaeger) collects the spans reported by each service and visualizes the full request path as a timeline, showing exactly where time was spent.
• Tracing makes it possible to pinpoint which specific service caused a slow or failed request in a chain of a dozen calls, something logs alone can't easily show.
• Sampling is usually applied in production to avoid tracing every single request, balancing visibility against overhead.

Example:
A slow checkout request that touches the Order, Inventory, and Payment services would show up in Zipkin as one trace with three spans, immediately revealing that, say, the Payment span took 2 seconds while the others took milliseconds.

Code Example:
```
# application.yml
management:
  tracing:
    sampling:
      probability: 1.0
  zipkin:
    tracing:
      endpoint: http://zipkin-server:9411/api/v2/spans
```

Interview Tip:
A concise interview answer is:

"I'd use Spring Cloud Sleuth, or Micrometer Tracing in newer Spring Boot, to automatically tag requests with a trace ID that propagates across service calls, and send the collected spans to Zipkin to visualize the full request path. That makes it easy to see exactly which service in a chain is responsible for latency or failures."