Observability Cannot Fix a Broken Architecture

Observability is essential when a system has meaningful complexity. It becomes wasteful when it is used to compensate for complexity nobody is willing to remove.

A dashboard can show that six services participated in a failed request. It cannot explain why six services were required in the first place.

What observability is good at

Logs, metrics, traces, and error reporting help teams answer:

• what failed;
• when it started;
• which users were affected;
• how the system behaved before and after the event;
• whether a fix improved the outcome.

These are operational questions. Architecture asks a different set: why is this path fragile, who owns it, and could the system be simpler?

Warning signs

Observability may be masking architecture debt when tracing is required to understand an ordinary request, alerts fire without a clear owner, every incident crosses several team boundaries, or dashboards multiply while recovery time stays flat.

Simplify before instrumenting everything

Start with a service map and identify the paths that create customer value. Remove unnecessary hops, make ownership explicit, and standardize error behavior. Then instrument the remaining boundaries.

For most small products, a strong baseline is modest:

1. application error reporting;
2. structured logs with request identifiers;
3. latency and failure rate for critical paths;
4. uptime checks from outside the system;
5. product events that confirm the user outcome.

Distributed tracing is valuable when the architecture is genuinely distributed. It is not a requirement for architectural seriousness.

The purpose of observability is not to produce telemetry. It is to reduce uncertainty and recovery time. If those measures do not improve, another dashboard is unlikely to be the answer.