The C4 container diagram

A container diagram takes the single box from the system context diagram and opens it. Everything inside is something that has to be running; everything outside stays as context.

Read it as a set of sentences: the customer browses the single-page application; the application calls the storefront API over HTTPS; the API writes orders to PostgreSQL and publishes to RabbitMQ; the worker consumes from RabbitMQ and writes to the same database. That last one is the sentence a container diagram exists to make visible - two containers writing to one database is a coupling that no service catalogue shows.

These two labels are what separate a container diagram from a sketch. Without the technology, a box called "Storefront API" could be a Lambda, a Rails monolith or a stored procedure. Without the protocol, a line between two boxes could be a synchronous call in the request path or a nightly batch job - which are opposite facts for anybody reasoning about failure.

Draw the arrow in the direction of the call rather than the direction of the data. A read is still a call from the reader to the store, and drawing the response as a second arrow doubles the line count while adding nothing - the reply is implied by the request.

Leaving out the datastores. A diagram of services with no databases hides exactly the coupling that causes incidents. If two containers write the same table, that has to be on the picture.

Mixing levels. A container diagram with one container opened into its internal classes is two diagrams badly overlaid. Open it on a component diagram instead, where the audience expects that depth.

Drawing infrastructure. Load balancers, sidecars and Kubernetes nodes belong on a deployment diagram. A container diagram is about what the software is, not where it runs.

Silently dropping external systems. The payment provider is not yours and cannot be omitted for that reason - it is where your latency and half your failure modes come from. Keep it, mark it external, and stop there.