Open the architecture diagram your team uses. Now open a recent incident postmortem. There is a good chance the postmortem mentions a service, a queue, or a dependency that is not on the diagram. There is also a good chance the diagram still shows something that nobody has called in months.

This is not a failure of effort. It is a property of how diagrams work.

A diagram captures a moment. A system never stops moving.

Diagrams are written by people. Production is not.

Diagrams are made for a purpose — a design review, an onboarding deck, a vendor pitch, a migration plan. Each one is built with an audience in mind, which means each one quietly leaves things out.

The cache that one team added during an outage and never told anyone about. The webhook a partner integration relies on, owned by a team that disbanded. The fallback to the old payment provider that fires three percent of the time when the new one times out. The cron that still runs because no one is sure if it is safe to disable.

None of this makes it onto the slide. All of it is in production.

Three places the diagram is usually wrong

Look at any real distributed system and you will find the same patterns of drift.

Phantom services.

The diagram shows a service in the middle of an important flow. In production, traffic routes around it through a queue and a worker that were added later. The original service is still deployed, still costing money, still on the diagram, and contributing nothing.

Invisible fan-out.

The diagram shows a single arrow from Service A to Service B. In production, that one call triggers six downstream calls, two database writes, an event on a topic that four other services consume, and a webhook to a third party. The arrow does not capture the blast radius.

Async denial.

Synchronous calls get drawn. Queues, topics, and event buses get a small box on the side, if anything. In real systems, the async paths are often where the business logic actually lives — and where incidents originate.

The shift

The diagram is not the problem. Trusting it as the source of truth is.

A useful architecture view is not drawn once and defended forever. It is generated from what services actually do — which APIs are called, which queues carry events, which dependencies are real, which paths are dormant. The picture should update at the speed of the system, not the speed of the team that maintains it.

This is what KarmaDomain in CodeKarma is built around: showing the architecture that exists, not the one that was once approved.

The most useful architecture view is the one the system writes itself.