A slow citizen checkout spans the API gateway, payments service, and notify service, and ops needs the path of one request end to end. Which observability approach should they use?
Select an answer to reveal the explanation.
Short Explanation
A checkout that crawls is like a package with three warehouses and no tracking number—you need the stamps on every hop. Distributed tracing stitches those hops into one request path across API, payments, and notify. Metrics alone won’t tell you which stop burned the seconds.
Full Explanation
Distributed tracing enables following one citizen checkout request’s spans across the API gateway, payments service, and notify service so operators see end-to-end latency and errors. Restarting every microservice nightly and comparing boot times fails to explain a single request path. Reviewing only the payments CPU graph and ignoring other hops misses multi-service causation. Increasing load-balancer idle timeout without collecting per-request path data may hide symptoms without diagnosing hops. Exam caveat: multi-hop latency stems point to tracing (context propagation + spans), not single-metric tunnel vision. Operational check: enable trace context across civic services, sample thoughtfully, link traces to logs, and practice reading a slow checkout trace in war rooms. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate. Confirm monitoring, access reviews, and backup coverage still align with the selected approach before closing the civic hypercare period.