An auditor asks what happens to your service if a single availability zone fails. Which diagram answers the question directly?
Show the full answer Hide the answer
The deciding property
The question is about physical placement, and only one of these diagram types has placement in it. A container diagram tells you which logical components exist and how they talk; it is silent on how many copies run and where. Availability is a property of copies and locations, so the diagram that answers it must show both.
A deployment diagram that earns its place here shows: the zones, how many instances of each component run in each, which datastores have a quorum requirement and where their members sit, and what is single-homed. The last one is what the auditor is really hunting for, and it is usually something unglamorous: a NAT gateway, a licence server, a single-zone cache, a scheduler with one leader and no standby.
Why the other options fail
- The container diagram is the most common thing handed over in this situation, and it invites the wrong conclusion. Two boxes with a line between them look redundant and say nothing about whether both run in one zone.
- The sequence diagram shows the order of interactions in a healthy request. Useful for understanding behaviour and unable to express placement, which means it cannot show that steps 3 and 5 are the same physical node.
- The context diagram shows what is outside the system, which matters for a different question: whether a third party is itself zone-redundant. It is a good second artefact and a bad answer to this one.
What would flip the decision
| If the question changes to | The diagram that answers it | Because |
|---|---|---|
| "What breaks if the payments provider is slow?" | sequence diagram with timeouts marked | the answer is about ordering and deadlines |
| "Where does personal data go?" | data-flow diagram with trust boundaries | placement of systems is irrelevant; flows are the subject |
| "What is affected if this service is down?" | container or dependency diagram | the answer is logical coupling, not physical placement |
| "Can we lose a whole region?" | deployment diagram plus a replication view | you need replication direction and lag, which deployment alone omits |
What a strong answer adds
Quorum arithmetic on the diagram itself. A 3-member consensus group tolerates 1 member failing, so its placement across 3 zones survives one zone loss and its placement across 2 zones does not, whatever the instance count suggests. Writing "3 members, quorum 2" next to the datastore turns a debate into arithmetic. The cost of keeping this diagram accurate is real — it changes with every capacity decision — which is why most teams maintain one for the two or three datastores whose quorum matters and none for stateless services. Zonal failures have been a recurring cause of public cloud incidents since at least 2011, and this is the artefact that predicts your behaviour during one.
When this is the wrong artefact
When the deployment is managed and elastic and nobody can say where instances are. A diagram claiming specific placement in an environment where a scheduler decides it each morning is worse than none, because it is confidently wrong. In that case the honest artefact is a statement of the constraints you have configured — spread policies, zone-aware scheduling, replica placement rules — and a test that verifies them, rather than a picture of a layout you do not control.