Questions: Distributed Tracing and Observability

Question 1

A user reports that a checkout request is taking 4 seconds. Your system logs each microservice independently but has no distributed tracing. What critical diagnostic information is UNAVAILABLE without tracing?

• A. The HTTP status code returned to the user at the end of the request
• B. The exact error message from any service that returned a 500 response
• C. The causal sequence and duration of each service call — specifically which service consumed the 4 seconds and whether calls were sequential or parallel
• D. Which services were involved in processing the request at all

Answer: (C)

Per-service logs can tell you what happened inside each service in isolation, but they cannot reconstruct the cross-service causal timeline. Without tracing, you cannot determine whether the payment service called the inventory service (or vice versa), whether two calls ran in parallel, or how long each leg took within the overall 4-second wall clock time. Distributed tracing supplies exactly this: a linked, time-stamped tree of spans across all services, enabling root-cause diagnosis of where the latency actually lives.

Question 2

How is the parent-child relationship between spans in a distributed trace established across service boundaries?

• A. The tracing backend infers relationships by matching timestamps across service logs after the fact
• B. Each service calls a central tracing coordinator to register its work before processing
• C. The calling service embeds its span ID in outbound request headers; the receiving service reads this as its parent span ID and creates a child span
• D. Spans are linked retroactively by matching shared user session IDs in log records

Answer: (C)

Trace context propagation via headers is the mechanism that makes distributed tracing possible. When Service A calls Service B, Service A's span ID is injected into the outgoing request headers (using standards like W3C Trace Context or B3). Service B extracts this header, uses the received span ID as its parent span ID, and creates a new child span. This chaining continues across every service boundary, producing a complete tree — all without requiring a central coordinator at call time.

Question 3

A single trace can contain spans from dozens of different services, all sharing a trace ID that was generated when the request first entered the system.

• T. True
• F. False

Answer: True

The trace ID is assigned once — typically at the entry point (API gateway or first service) — and propagated in headers through every service call for the lifetime of that request. Every span created anywhere in the call graph uses this same trace ID, which is how the tracing backend can assemble thousands of individual spans from many services into a single coherent trace tree.

Question 4

Capturing a full trace for nearly every request is standard practice in high-throughput production systems because the per-trace storage overhead is negligible.

• T. True
• F. False

Answer: False

Full-fidelity tracing of every request generates enormous data volumes in high-throughput systems. A service processing 100,000 requests/second would produce millions of spans per second, creating storage, ingestion, and query performance problems. Production systems use sampling strategies — head-based sampling (decide at request start whether to trace), tail-based sampling (decide after completion, keeping only errors or slow outliers), or probabilistic sampling (trace 1–10% of requests) — to manage volume while retaining diagnostic value.

Question 5

How does distributed tracing complement metrics and logs? What can it reveal that the other two pillars of observability cannot?

Model answer: Metrics tell you that something is wrong (e.g., p99 latency spiked to 3 seconds), and per-service logs tell you what happened locally within each service. Neither can reconstruct the cross-service causal flow of a specific request. Distributed tracing links spans from all services into a single tree with timing, revealing which service caused a slowdown, whether service calls were sequential or parallel, how errors propagated through the dependency graph, and what the request looked like end-to-end — information that is structurally unavailable from per-service observations alone.

The three pillars are complementary precisely because they answer different questions: metrics surface the problem, logs explain local behavior, and traces reveal causality across service boundaries. High-latency incidents in microservice architectures almost always require all three to diagnose definitively.