Cloud Computing Architecture Guide

Patterns as Responsibility Compositions

Goal

Connect the capability decisions from earlier chapters to a practical way of reading and using architecture patterns.

The Short Version

An architecture pattern is reusable reasoning about a recurring problem. It describes the context, the forces that pull the design in different directions, an arrangement of responsibilities and boundaries, and the consequences of choosing that arrangement.

A product diagram answers, "Which components could I deploy?" A useful pattern also answers:

  • Why are these responsibilities separate?

  • Which flows cross trust or ownership boundaries?

  • What breaks, and what should happen when it does?

  • Which parts are stable and which are variation points?

  • What operational cost does the arrangement create?

The boxes are not the pattern. The reasoning that connects the boxes is.

A Pattern-Reading Method

Read any pattern from left to right:

Context and constraints
        |
        v
Forces and priorities
        |
        v
Responsibilities + boundaries + flows
        |
        v
Consequences, risks, and variation points

Start with context: users, business outcome, data sensitivity, workload shape, recovery expectations, team capabilities, and cost limits. Then identify forces. A low-latency response may conflict with strong consistency across regions. Team autonomy may conflict with the operational cost of many deployables. Strict isolation may conflict with pooled efficiency.

Only then inspect the composition. Trace seven things through it: identity, traffic, state, trust, failure, operational evidence, and ownership. If the diagram cannot show or explain those paths, it is an inventory, not yet an architecture answer.

Finally, state the consequences. Every useful pattern buys something and spends something. Caching can reduce latency and origin load, but introduces invalidation and staleness decisions. Asynchronous work can isolate a user request from slow processing, but adds durable state, retries, and reconciliation.

Stable Shape and Variation Points

Patterns are reusable because some responsibilities persist while implementations change. A public application commonly needs controlled entry, application execution, data authority, workload identity, telemetry, and recovery. The specific number of tiers, runtime type, data technology, and regional topology are variation points.

Provider reference architectures are valuable evidence about supported service combinations and provider defaults. They are not universal deployment answers. Reuse the responsibility shape, validate its assumptions, and adapt it to the current forces.

Example: Two Similar Three-Tier Applications

Two diagrams both show a web tier, application tier, and database. The first system is an internal expense application used in one country. It has predictable weekday demand, modest recovery needs, and one owning team. A managed application runtime and regional relational database may be enough.

The second handles regulated customer records globally. It needs residency controls, stronger audit evidence, regional failure procedures, and separate security and application owners. Its visible tiers may look similar, but identity scope, key ownership, data placement, deployment gates, logging, and recovery boundaries differ substantially.

Copying the first diagram for the second problem preserves the boxes while discarding the pattern reasoning.

Common Mistakes

  • Naming components without stating the force or responsibility that justifies them.

  • Treating every reference architecture as a target state instead of a source of tested ideas.

  • Hiding deployment, recovery, cost, and ownership outside the main design.

  • Adding components for theoretical flexibility without evidence that the flexibility is valuable.

  • Calling a choice a best practice without naming the context in which it is best.

If Someone Asks You

How do you tell whether an architecture pattern fits a problem?

A good answer is: "I compare the pattern's context and forces with ours, trace its identity, traffic, state, failure, and ownership paths, and check whether its consequences are acceptable. I reuse the reasoning and responsibility shape, then adapt the implementation and validate the risky assumptions."

What You Should Remember

Reuse the reasoning and responsibility shape, then adapt the implementation.

Questions to Check Your Understanding

  1. Which responsibilities in a public application are likely to remain stable across providers?

  2. Which context changes should force you to revisit the pattern?

  3. Why are operating consequences part of the pattern rather than an afterthought?

Further Study