ORIGINAL TECHNICAL PRACTICE
Observe the user journey across services
An order submission occasionally fails, but every service reports low average latency. What observability would you add?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Measure the end-to-end user outcome and correlate work across service boundaries. Component averages can hide tail latency, retries and partial failures that affect the overall operation.
Work through it
- Define success at the business boundary and instrument request IDs, stage timings, status transitions and dependency outcomes. Preserve correlation through queues and asynchronous workers.
- Inspect percentile latency, error rates and saturation by operation and relevant segment. Use traces or structured events to reconstruct slow or failed paths.
- Build actionable alerts tied to the service objective and add safe reconciliation tooling for uncertain outcomes. Exclude sensitive payloads from broad logs and control retention.
Tradeoffs to discuss
- Detailed telemetry improves diagnosis but adds cost and privacy obligations. Sampling can reduce volume while making rare failures harder to reconstruct.
Common pitfalls
- A healthy transport response may conceal a failed business operation. Logging every raw request body is not a substitute for a useful event schema.