Debugging a distributed mystery

In a monolith, a bug lives in one place. You open the logs, you find it.

Microservices change the problem. A single user action can cross 5+ services — and the failure can sit in any one of them, or in the gap between two of them.

Take a signup:

Auth service → User service → Notification service → Email provider

Say it fails halfway. The user exists, but the welcome never arrives. Or the account never gets created, but the notification already went out. Where do you look?

Without centralised logging and tracing, you open four dashboards, four log files, four different formats — and you guess. Each team can honestly say "it worked on my side," because each side only saw its own hop.

The fix is not more logs. It is one thread through all of them:

1. One request ID, carried across every hop, from the first request to the last.
2. Centralised logs, searchable by that ID — so one search shows the whole journey, not one service's slice of it.
3. Tracing that shows the order and timing of each hop — so you can see where the chain broke, not just that it broke.

With that, debugging stops being a mystery. You follow the request the way the user experienced it: Auth, then User, then Notification, then the provider — and the hop where the thread goes quiet is where you look.

The rule I keep: no service starts work without the request ID. A log line you cannot tie back to a request is a dead end, and a system full of dead ends is a system you cannot debug.

Microservices do not make bugs harder to write. They make evidence harder to follow. Centralise the evidence, and the mystery goes away.

Next in this series: 7 backend lessons I learned the hard way. I write about backend systems that look small until they aren't — follow along if that's your world; the longer pieces live on my Substack.