Use a container view when the question is which applications and data stores make up one system and how they communicate. In the C4 model, container means an application or data store, not necessarily a Docker container. The official container-diagram guidance, checked October 24, 2026, also separates this view from environment-specific deployment details.
Describe the current state in plain text
This original fictional booking system has these supplied facts:
- A customer uses a browser application.
- The browser sends booking requests to the Booking API over HTTPS.
- The Booking API reads and writes the Reservations database through its database connection.
- The Booking API submits confirmation messages to an external mail service over HTTPS.
- The browser has no direct database connection in this described system.
An inventory is incomplete if “database connection” needs a specific protocol for the review. Mark that technology unknown until the owner confirms it. Do not add a cache, queue, replica or authentication service merely because similar systems often have one.
The expected relationship list is:
| Source | Destination | Purpose |
|---|---|---|
| Customer | Browser application | Uses booking interface |
| Browser application | Booking API | Sends booking requests over HTTPS |
| Booking API | Reservations database | Reads and writes reservation records |
| Booking API | External mail service | Submits confirmation messages over HTTPS |
These rows are the substantive answer. A graphic should preserve them. The absence of a browser-to-database edge follows from the supplied scenario, not a universal rule about all browser applications.
Request a traceable diagram draft
Draft a current-state C4-style container view for one booking system.
Audience and review question: [ENTER]
System boundary, components and responsibilities: [PASTE INVENTORY]
Observed/documented connections and protocols: [PASTE]
Evidence locations and facts not yet confirmed: [PASTE]
Return a plain-text inventory, labeled relationship table and Mermaid
flowchart source representing that same view. Label people, applications,
data stores and external systems distinctly; explain any notation.
Give each arrow a purpose and protocol only where supplied.
List every element and edge with its supporting source fact.
Do not add conventional components, reverse an arrow, infer deployment
replicas, claim production observation or recommend a redesign.
Keep unknown protocols visible. Separate disputed facts for owner review.
OpenAI's prompting guidance supports providing that context and output format. Mermaid source is a draft representation: render it with your chosen tool to check syntax, then inspect its meaning against the table. A successful render does not validate the architecture.
Audit one invented edge at a time
If a generated picture connects the browser directly to Reservations, identify the unsupported arrow and remove it from the diagram source. Then compare the complete revised edge list again; fixing one arrow can leave a stray reverse connection or unlabeled path elsewhere.
Ask owners to confirm disputed connections against permitted configuration or maintained documentation. If the question changes to replicas, regions or failover, prepare a deployment view with environment evidence rather than squeezing those claims into the container picture. The database design guide covers a different level: the meaning and identity of stored records.
Keep the reviewed inventory and diagram source together. Record which owner settled each unknown, and update both when a real connection changes. That gives the next reviewer something more dependable than a polished image with no traceable basis.