Dependency map: in two hours, figure out what will actually bring the business down

In most companies the infrastructure diagram exists in two forms. The first is a pretty presentation: clusters, replicas, load balancers, arrows between them. The second is the real one — in a single engineer’s head — and it’s noticeably more complex.

The problem with both is that they describe technology, not the business. They show where servers are, but not what actually stops sales. And the failure that stops sales almost never looks dramatic on a diagram: it’s not a crashed cluster but an expired certificate, an unavailable external service, or an account you’ve lost access to.

A dependency map is a way to see the system through the business’s eyes. It’s drawn in a single two-hour session and almost always reveals two or three single points of failure the company hadn’t considered.

Who to invite

Just engineers are not enough, and that’s the main mistake. Engineers know how the system is built; they don’t always know what happens to revenue when it fails.

Gather four people: a technical specialist, a support representative, someone from sales or operations, and the person who makes budget decisions. Support is invaluable — they’re the first to learn what broke and remember all past incidents in details that aren’t in any report. Sales know which failures customers will forgive and which they won’t.

Two hours and one board are enough. The tool is secondary: an online whiteboard will do, and for the first time — a sheet of paper.

How to draw: following the request path

Don’t start by listing servers — you’ll get an inventory list, not a map. Follow the customer’s path, top to bottom, asking at each step “what’s next”.

1. Entry point. Where is the domain registered and to whose name? Which provider hosts the DNS records? Who can physically change them at three in the morning?

2. Transport. How does the request reach your infrastructure? Is there a CDN, DDoS protection, who issues and renews the TLS certificate?

3. Reception point. Which load balancer or web server receives the request? Is there just one or several?

4. Application. Which services handle the request? Where is static content stored — on the local disk of a server or in object storage?

5. Data. Where are the database, cache, queues? What happens to the application if the cache is unavailable: does it work slower or stop working completely?

6. External services. Payment gateway, message delivery, CRM, delivery service, mapping service, authorization service. Every external call is someone else’s infrastructure that you can’t control.

7. Supporting systems. Monitoring, backups, deployment system, password storage. Their failure isn’t immediately visible to the customer, but it deprives you of the ability to respond.

Second map: administrative dependencies

The technical map is not enough. Draw a second one in parallel — shorter and nastier. It doesn’t show servers but rights, accounts, and credentials:

• Whose name the domain is registered to and which email receives renewal notifications.
• Which bank card is linked to the cloud provider account and when it expires.
• Who is the organization owner in the provider’s console — i.e., who alone can restore access to others.
• Where keys and passwords are stored and what will happen if that service becomes unavailable.
• Whose phone receives the second factor for critical accounts.
• Who receives notifications about TLS certificate and license expirations.

This map often turns out to be more dangerous than the technical one. A server can be fixed in an hour, but recovering control over a domain registered to a departed employee takes weeks — and during that time you can do nothing.

Exercise “color it red”

When both maps are drawn, ask for each node one question: what will happen to the business if this element disappears right now?

Mark in red those whose failure immediately stops revenue. Yellow — those that degrade operations but allow the business to continue. Green — those whose absence no one outside will notice for a day.

Argue out loud. Disagreements in assessments are the most valuable result of this session: when an engineer is sure a service is minor but support knows its failure triggers forty tickets in an hour, you’ve found not a technical problem but a gap in understanding the system.

What is found almost always

Domain and email registered to a departed employee. The domain is registered to a person’s personal address who left two years ago; renewal notifications go nowhere. As long as everything works, it’s unnoticed. On the day of the incident it’s discovered that there’s no one who can change the DNS record.

A synchronous call to an external service without a timeout. When completing an order the application calls an external CRM and waits for a response. Usually the response arrives in 100 milliseconds. On the day the CRM has problems and the response takes 30 seconds, all free workers in your application become occupied waiting — and the site stops responding entirely, even though your infrastructure is fully functional. This is fixed by setting timeouts, disabling non-essential calls during degradation, and moving anything that can be deferred to asynchronous processing.

Cache as an unnoticed point of failure. User sessions are stored in Redis for scalability, but Redis itself runs as a single instance. Its failure means nobody can log in, even though the database is fully operational.

A single notification channel. Monitoring sends alerts to a corporate messenger that is deployed on the same infrastructure as the product. During a major incident you will not receive alerts about it.

A certificate that no one renews. Automatic renewal is configured but once it broke, and this only becomes known on the day browsers start showing warnings about insecure connections.

What to do next

The map is not an end in itself. It is needed to make three decisions.

First: fix what can be fixed cheaply. Re-register the domain to the company, add a second notification channel, set timeouts on external calls, assign an owner for each critical account. These are days of work, not budgets, and eliminate half of the discovered risks.

Second: determine redundancy priorities. Not all red items need the same level of redundancy — start by calculating the cost of failure. There’s a separate analysis about this: component criticality.

Third: stop treating the map as a one-time activity. It becomes outdated in a quarter: integrations appear, providers change, people leave. A reasonable rhythm is to review it once a quarter and always after any major architectural change. Fifteen minutes is usually enough to check it if the map already exists.

Start with three components on a sheet of paper. An incomplete map drawn today is more useful than a comprehensive diagram that’s planned for “sometime later.”

The outer layer of the map — domain, DNS, email, certificates — is checked automatically in a couple of minutes. We’ll go through the rest together if you need an external perspective.