What does a deployment diagram communicate that a container diagram cannot, and what is most often missing from it?

What it adds

Where things actually run, and therefore what fails together.

A container diagram shows logical components and their relationships. A deployment diagram shows the physical or infrastructural placement: which regions, which zones, which clusters, which edge locations, and what is replicated where.

That placement is what determines failure domains, and failure domains are the substance of most availability conversations. Two components that look independent on a container diagram may share a zone, a cluster, a control plane or a configuration source — and the deployment diagram is where that becomes visible.

What is most often missing

1. The control plane. Configuration distribution, deployment pipelines, service discovery, secret management. These reach everywhere by design and are therefore a dependency of everything, including of recovery — and a recovery mechanism depending on the control plane depends on something whose availability is negatively correlated with your need for it.

2. Shared infrastructure across apparently separate components. A shared database cluster, a shared cache, a shared identity service. The diagram should make shared fate explicit rather than leaving it inferred.

3. Capacity and headroom. How much of each location's capacity is in use, and whether the survivors can absorb a failed peer. A topology showing three regions says nothing about whether losing one is survivable, which is the actual question.

4. Data replication direction and lag. Which store is authoritative, which are replicas, and what the replication topology is. This determines what is lost in a failover.

5. What must be reachable for the system to keep serving, as distinct from what is nice to have. The distinction between hard and soft dependencies is invisible without it.

For a globally distributed platform specifically

The deployment diagram should show the propagation path for configuration, because at that scale the mechanism designed to change behaviour everywhere quickly is also the mechanism most likely to cause a fast global outage.

Showing the staging path — canary location, then region, then fleet — and the rollback path, including whether rollback depends on the control plane that a bad configuration might have broken, is the single most valuable thing such a diagram can communicate.