2. Boundaries, State, and Data

Most hard architecture problems become easier after you know where state lives and who owns it. Draw the system boundary, external dependencies, trust boundaries, data stores, and the direction of important calls. For each business fact, identify one authoritative source of truth.

Evidence: S3, S24, S54, S58

Key decisions

Stateful vs stateless compute: keep durable state outside replaceable application instances when practical.

Data ownership: in a microservices design, keep service data private to the owning service and expose behavior/data through explicit contracts rather than shared schemas.

Failure domains: identify which failures should be isolated from which other functions.

Dependency direction: know what must be available for a critical request to succeed.

Trust boundaries: every transition across a security boundary needs explicit authentication/authorization assumptions.

Evidence: S3, S27, S54, S58

C4 diagrams: zoom from context to code

The C4 model provides a small set of architecture views at increasing levels of detail. Treat the levels like a map: start wide, then zoom in only where another view helps a specific audience or decision. C4 is notation- and tooling-independent; consistent scope, names, responsibilities, and relationships matter more than shapes or colours.

Most teams need only system context and container diagrams. Add component or code diagrams when they answer a real question; do not document every level by default. Use separate dynamic diagrams for important runtime interactions and deployment diagrams for environment-specific infrastructure, replicas, and failover.

A C4-style system context example. Key: blue is the system in scope; grey boxes are people or external systems.

C4 diagram checklist

• The title states the diagram type and scope.
• One diagram uses one abstraction level; it does not mix systems, containers, components, and code without a clear reason.
• Every element has a type, meaningful name, and short responsibility description.
• Containers and components identify their main technology where it helps the audience.
• Every relationship is directional and labelled with its purpose; container relationships also name the protocol or technology.
• A legend explains shapes, colours, line styles, acronyms, and any additional notation.
• Names and relationships remain consistent when zooming between diagrams.
• The diagram has an owner or generation path and is updated when the architecture changes.

Evidence: S93

Checklist

• A system context diagram shows people, the system in scope, and directly connected external systems.

• A container diagram shows the system's applications, data stores, responsibilities, technologies, and communication paths.

• Each important data set has a clear owner/source of truth.

• Durable state is not accidentally stored only in one application instance.

• Session state strategy is explicit.

• Critical synchronous dependency chains are visible.

• External dependencies have documented limits and failure behavior.

• Failure domains are intentional; unrelated features should not fail together without reason.

• Trust boundaries are marked.

• Data classification is known for sensitive or regulated data.

• When using microservices, boundaries follow business capability/responsibility rather than horizontal technical layers.

Evidence: S3, S24, S27, S54, S58