Part 9 of 17 · ~1 min
Distributed Tracing and Observability
A single user request in a microservices system might touch five services before a response comes back — and any one of them could be where a bug, a slowdown, or an error actually originated. Three practices become necessary (not optional) once a system crosses from one process into several:
- Correlation IDs — a unique ID generated at the very start of a request (often at the API gateway) and passed along, unchanged, through every subsequent service-to-service call it triggers. Every log line, from every service, that request touches gets tagged with that ID, so "what happened to this specific request" is a single searchable query across otherwise-separate services' logs, instead of manually reconstructing a timeline from five unrelated log files.
- Centralized logging — every service's logs shipped to one searchable place (rather than living only on whatever machine happened to run that service instance, which may not even exist anymore by the time someone goes looking).
- Distributed tracing — a step further than correlation IDs: a tracing system (built on something like the OpenTelemetry standard) captures not just that a request touched five services, but the actual timing and parent/child relationship of every call along the way, rendered as a single trace — which specific downstream call in that chain took 400ms out of a 500ms total response time, for instance.
None of this is needed in a monolith, where a single stack trace inside one process already contains the whole story of what went wrong. It's not optional tooling for microservices, though — without it, "somewhere across five services" is often the entire extent of what you can say about a production incident, which isn't good enough to actually fix anything.