Digital and cloud-scale architecture stage summary

Alistair Cockburn published hexagonal architecture in 2005 under the subtitle ports and adapters. The hexagon carries no special meaning beyond signalling that no side is privileged: there is no top for the user interface and no bottom for the database. Driving adapters initiate work against the application, and an HTTP controller, a command line tool and a test case are all driving adapters calling the same driving port. Driven adapters are the things the application calls out to: a relational repository, a message publisher, a text-message gateway.

The move that distinguishes the pattern from ordinary dependency injection is ownership of the interface. In a conventional layered application the data access layer defines the repository interface and the business logic imports it, so the dependency runs from the domain towards the infrastructure. In hexagonal architecture the application declares the repository interface in its own package, and the database adapter implements an interface it does not own. The arrow is reversed, and that is the structural difference, not the shape of the diagram.

Two consequences follow immediately. A test harness is architecturally the same kind of thing as the production controller, which is why test-first work is natural here rather than bolted on, and an in-memory implementation of a driven port is a real adapter rather than a mock. The check that tells you whether a codebase actually does this is blunt: try to run the entire domain test suite with no database and no broker running. If you cannot, some adapter detail has leaked through a port, and the leak is usually visible in the imports of a single file.

Robert Martin's clean architecture, set out in a 2012 article and expanded into the 2017 book, synthesises hexagonal architecture with Jeffrey Palermo's onion architecture from 2008 and adds a single overriding constraint. The rings run from the innermost outwards: enterprise business rules as entities, application business rules as use cases, interface adapters as controllers, presenters and gateways, and frameworks and drivers on the outside. Stability decreases as you move out, which is why the volatile things live where replacing them is cheap.

The dependency rule is absolute. Nothing in an inner ring imports anything from an outer ring. An entity never imports a controller; a use case never imports a database library or a framework annotation. Where a rule belongs follows from the rule itself. A constraint that holds regardless of how the application is invoked, such as an account balance not falling below its overdraft limit, is an entity invariant. Enforcing it only in a controller means it holds for one entry point, and enforcing it only as a database constraint means it holds only once the transaction reaches the database.

The reliable tell that a codebase claims this pattern without practising it is persistence or serialisation annotations decorating domain entities. Those are adapter concerns wearing domain clothing, and they are why the domain cannot be compiled or tested without the framework present. Removing them is usually a small change with a large consequence: the inner rings become independently compilable, and the tests that cover business rules stop needing infrastructure to run.

Functions as a service means the provider owns the servers, the operating system, the scaling and the patching, and you supply a function that runs in response to an event. Billing is per invocation and per unit of execution time, so idle capacity is not charged for. That is the entire economic argument, and it is a real one for work that arrives in bursts. Servers still exist; you simply cannot see, patch or tune them, which is the operational half of the same trade.

The execution model is stateless by necessity rather than by preference. Anything that must survive between invocations has to be externalised to a database, cache or object store, because that constraint is exactly what lets the provider route the next invocation to any available container. The hard edges follow from the same design. A single AWS Lambda execution is capped at fifteen minutes, so long-running transcoding or training work needs a different execution model or an orchestrated workflow. A cold start happens when no warm container is available, adding a fraction of a second for interpreted runtimes and rather more for a standard JVM; provisioned concurrency removes it by paying to keep containers warm. Vendor coupling lives in the event contracts, not in the deployment tool, so a framework that abstracts deployment does not abstract the lock-in.

The consequence for design is to look at workload shape before anything else. Per-invocation billing wins on spiky, irregular, event-driven work, where provisioning for the peak would mean paying for it all year. It loses at constant high throughput, where you pay a premium for elasticity you are not using and a long-lived instance is cheaper. Work out the crossover for your own memory setting and average duration rather than repeating a figure from a conference talk, and be honest that operational simplicity has value in its own right for a small team.

Edge computing runs code at points of presence close to the user instead of in one central region. The gain is physical: a request from Australia to a European region spends hundreds of milliseconds crossing the planet before any compute begins, while a function at a local point of presence answers within the local network. For work that happens on every single request, such as authentication checks, routing decisions and personalisation headers, that difference is felt directly by the user.

The cost is the runtime you get. Edge platforms execute in lightweight JavaScript isolates rather than full server processes, which means no file system or process modules, a very small CPU budget per request, and no direct database connections. Edge functions are stateless by design and call origin services when they need data. That makes them well suited to decisions and poorly suited to the work behind those decisions, and it is why an edge tier is usually a thin layer in front of something else rather than a replacement for it.

The largest latency win at the edge is often not compute at all but cache: content served from a content delivery network never reaches the origin, so it never pays for compute or for the round trip. The practical consequence is to choose the execution model per unit of work rather than per application. A single well-built system routinely uses all three: cache and edge functions for per-request decisions, central serverless for bursty event handling, and long-lived servers for the steady core.

Observability is the ability to infer the internal state of a system from its external outputs, and the working test is whether you can answer a question nobody anticipated without shipping new code to add logging. The three pillars divide the work. Logs are timestamped records of discrete events and answer what happened at a moment. Metrics are numeric measurements aggregated over time and answer how a service has been behaving. Traces are end-to-end records of one request as it crosses services and answer where in the path the time went.

They are a sequence rather than alternatives, and the reason is visible in any request that crosses several services. Each service can report a healthy error rate and a normal average latency while the end-to-end experience is terrible, because the wait is sitting inside one dependency that is slow rather than failing. A trace attaches an identifier at the first hop and propagates it, and each service contributes a span, so the waterfall shows the one span consuming the time. Correlating five separate log streams by timestamp to reach the same conclusion is the work that turns a two-minute diagnosis into a forty-minute one.

Structured logging is the join between the pillars. A log line written as a sentence cannot be queried; a record carrying fields for the identifiers that matter, including the trace identifier, can be filtered and correlated, and takes you from an error straight to the trace it belongs to. OpenTelemetry, the Cloud Native Computing Foundation project that resulted from merging OpenTracing and OpenCensus, is the vendor-neutral way to emit all of this: instrument once, and change the backend by changing an exporter rather than by re-instrumenting the estate. If localising a fault across services routinely takes tens of minutes, the missing capability is tracing, and more logging will not supply it.

Three terms sit in a hierarchy and are constantly confused. A service level indicator is the thing you measure, such as the proportion of requests that return success within a stated latency. A service level objective is the target for that indicator over a defined window. A service level agreement is a contractual commitment with a penalty attached, and it should always be looser than the objective you run to internally. The rate, errors and duration triple gives you indicators at every service entry point, which is where the measurement usually starts.

The error budget is the failure the objective permits, and it converts an argument into arithmetic. Over a thirty-day window, an objective of 99.9 percent allows 43.2 minutes of failure, 99.99 percent allows a little over four minutes, and 99.999 percent allows about 26 seconds. That arithmetic reframes incidents: a single event that fails 0.08 percent of the month's requests has consumed 80 percent of a 99.9 percent budget, and the remaining fifth of the month should be spent differently from the first four fifths.

Two consequences change what you would actually do. Set the objective just above the measured baseline and tighten it as reliability improves, because an objective the service has never met does not drive reliability, it drives arguments about the measurement. And give the budget real governance weight: if the budget is exhausted and risky deployments carry on regardless, the objective is a dashboard decoration rather than a control, and the reliability conversation goes back to being a matter of who argues hardest.

Blue-green keeps two production environments, validates the idle one while the live one still serves traffic, then switches everything at the load balancer in one move. Rollback is a traffic redirect rather than a pipeline run, which makes it the fastest reversal available for application code. The price is double infrastructure through the transition, and the validation has to happen before the switch rather than after it, which is the part teams skip when they are in a hurry.

Canary sends a small share of traffic to the new version, holds it for an observation window, and promotes or reverses on the same indicators that define the objective. It produces real user signal at a small blast radius, and it works best with automated gates on error rate and tail latency rather than a person watching a chart. Its limitation is statistical: at one to five percent of traffic you need enough requests for a rare error rate to be measurable at all, so a low-traffic service needs a much longer window than a busy one. Rolling deployment replaces instances in batches with health checks between them, needs no extra infrastructure, and is the default in most orchestrators.

Rolling carries one non-negotiable precondition. During the rollout window the old and new versions serve traffic side by side, so every change must be backwards compatible in both directions. Renaming a field in a response part way through a rollout means some consumers receive the old shape and some the new one, and the failures are often silent rather than loud. The rule that follows is to match the strategy to the reversal cost: routine compatible changes roll, and changes that would be expensive or impossible to undo go blue-green or canary.

Feature flags separate shipping code from exposing behaviour. The new path goes to production disabled, and a flag decides whether it runs. That enables dark launching to internal users, progressive exposure to a growing share of customers, and a kill switch that takes effect as a configuration change rather than a pipeline run. After a change has already reached everyone, flipping a flag is the fastest reversal there is, which is precisely the moment a deployment strategy has run out of options.

Flags are also debt, and it accrues quietly. Every long-lived flag is a live branch in production code, and the combinations multiply faster than the tests do. The workable policy is two categories with different lifecycles: temporary release toggles that carry a removal deadline and are actually removed, and permanent operational toggles that have a named owner and a review. Teams that let the count drift into the dozens report that nobody can say with confidence what the system will do for a given user.

No deployment strategy protects the database. Blue and green share a schema, so a destructive migration makes rollback impossible even while application rollback remains instant, and this is where deployment strategies fail in practice rather than in theory. The safe sequence is expand then contract: apply a backwards-compatible schema change first, deploy code that tolerates both the old and new shapes, and remove the old shape in a later release once nothing reads it. Treat schema and code as separate releases every time, including the release that finally cleans up.

When every service owns its own database there is no shared transaction coordinator, and any participant can fail independently at any point in a sequence. Two-phase commit was the traditional answer: a prepare round in which every participant confirms it can commit, then a commit round. It buys atomicity with distributed locks, and a participant that dies between the two rounds leaves the coordinator waiting or guessing. At throughput the locking costs more than the guarantee returns, which is why most distributed designs decline it.

A saga replaces one atomic transaction with a sequence of local transactions, each committing to a single database, linked by events or calls, with compensating transactions that undo the earlier steps when a later step fails. Choreography has each service react to events with no coordinator, which is simple and robust for short chains and becomes hard to reason about as the chain grows, because no single place holds the state of a job in flight. Orchestration puts the sequence and the compensation logic in one coordinator, which makes the flow visible and debuggable at the cost of a coupling point. Neither gives atomicity: intermediate states are visible to other readers, and the application has to tolerate that.

Two mechanisms carry the rest of the weight. The transactional outbox removes the dual-write problem by inserting the event row in the same database transaction as the business change, with a relay process publishing from the outbox and retrying until the broker confirms. That relay makes delivery at-least-once, so consumers must be idempotent by design rather than by luck. Idempotency keys do the same job on the request side: the caller generates one key for each logical operation and reuses it on every retry, and the server returns the stored result instead of repeating the effect. The blunt version of this lesson is that a retry policy without idempotency is a duplicate-charge policy that has not fired yet.

Versioning exists so a contract can evolve without breaking consumers you do not control and cannot deploy. Adding an optional field is backwards compatible provided consumers are tolerant readers that ignore what they do not recognise, and that habit on the consumer side is what makes additive evolution possible at all. Removing a field, renaming one, changing a type or making an optional field required are breaking changes, and no amount of goodwill makes them safe to ship in place.

Versioning in the URL path is the most visible approach, but the large public APIs are a poor argument for it: GitHub versions through an X-GitHub-Api-Version header and Stripe through a date-based Stripe-Version header, both keeping the URL stable while the contract moves underneath. The mechanism matters less than the operational commitment behind it. Run at least two versions at once, and announce a deprecation with a migration window long enough for a consumer team to fit the work into a planning cycle rather than meet it as an incident, then withdraw the old version only once that window has run. Tell them in a way that does not depend on anyone reading a changelog, because the consumers you cannot deploy are exactly the ones who will not see it.

The reason to invest early is that integration effort grows faster than service count: five services have ten possible pairs and twenty services have one hundred and ninety. Idempotency, outboxes and contract discipline are cheap to establish while the count is small and expensive to retrofit across an existing mesh of live integrations. If a split is being considered, put the integration mechanics in place first, in the same way that governance is cheaper before fragmentation than after it.

Governance is what turns architecture from a recommendation into a constraint. It runs on a spectrum, and both ends fail in predictable ways. Centralised approval buys consistency and pays for it with a queue that slows every team down. Full decentralisation buys speed and pays for it with fragmentation, and the classic symptom is a dozen teams choosing four or more message brokers for individually sensible reasons, after which every cross-team integration needs its own client library, monitoring approach and operations runbook.

Federated governance sits between them: a small architecture function sets standards, approved choices and the non-negotiable constraints, and teams decide freely inside those guardrails. An architecture review board earns its place through scope rather than authority. It should see decisions that are expensive to reverse, that cross team boundaries, that change shared APIs or event schemas, or that touch security, compliance and data residency. It should not see refactoring, internal technology choices inside one team's context, or implementation detail that no other team can observe. A board that reviews everything becomes the bottleneck it was created to prevent.

TOGAF supplies the vocabulary at enterprise scale: four architecture domains covering business, data, application and technology, and the Architecture Development Method, a cyclical process running from a preliminary setup and an architecture vision, through the domain architectures, into opportunities and solutions, migration planning, implementation governance and change management, with requirements management running throughout. The 10th edition was published in 2022. The method is a reference cycle to tailor, not a waterfall to obey and not a standard to comply with. At smaller scale, take the domains, the governance concepts and the phase vocabulary, and run the full method only where cross-domain consistency has real business value.

An architectural fitness function is an automated check that a system still satisfies an architectural characteristic, a term set out by Neal Ford, Rebecca Parsons and Patrick Kua in 2017. Its contribution is to move enforcement from a document and a periodic review to a check that runs on every commit and fails the build. A written standard depends on a reviewer remembering it under time pressure; a failing build does not depend on anyone's attention at all.

Two examples pay for themselves quickly. A dependency-direction check verifies that the domain never imports infrastructure, expressed as a rules library in some languages and as a short import-inspection script in others, which turns the dependency rule from the first two sections into something enforced rather than aspired to. A coupling check verifies that one service's database user has no access to another service's schema, which enforces data ownership at the point where it is normally violated quietly by a convenient query.

Fitness functions work best surrounded by lightweight instruments rather than heavy process. A technology radar sorted into adopt, trial, assess and hold, reviewed on a regular cadence, tells teams what is safe to reach for. Decision records reviewed in pull requests leave a searchable trail of why a choice was made, which makes the next decision better informed. Open architecture office hours catch problems early, because an engineer who would avoid booking a formal review will happily ask a question in a low-stakes session. The habit to adopt is to state each governance rule in the form that could fail a build, and to give the ones that genuinely cannot be automated a named owner and a review date instead.

Chaos engineering is the discipline of experimenting on a system in order to build confidence in its ability to withstand turbulent conditions in production. The word discipline is load-bearing: this is not breaking things at random. Netflix ran Chaos Monkey against production instances during working hours from 2011 and extended the idea to availability zone and region failure, on the explicit reasoning that a weakness is better discovered on a Tuesday afternoon with the team watching than at two in the morning during a real failure.

Every experiment has the same five parts. Define the steady state as a measurable description of normal, drawn from the same indicators that define your objectives. State a hypothesis specific enough to be wrong, with numbers for the expected fallback behaviour, the recovery time and the acceptable error and latency ceilings. Inject one failure with a defined scope and duration. Observe the indicators throughout. Conclude by comparing what happened with what you predicted. A rejected hypothesis is the more valuable outcome, because it has exposed a weakness under controlled conditions instead of during an unplanned outage.

The prerequisites are not optional extras. You need indicators and objectives with live monitoring to establish the steady state, distributed tracing to work out what is happening inside the system during the injection, an engineer on call for the window, a written abort condition whose threshold was decided before the experiment rather than during it, and stakeholders who know the experiment is running so that impact is not mistaken for an incident. Minimise blast radius: terminate one replica before you terminate a zone. Chaos on a system you cannot observe does not produce insight, it produces an incident with a nicer name.

The Architecture Trade-off Analysis Method, developed at the Software Engineering Institute, is first of all a risk identification method rather than a way of finding an optimal design. It gives three pieces of vocabulary worth using even when you never run the full workshop. A sensitivity point is a decision where a change moves one quality attribute sharply. A trade-off point is a decision where improving one quality attribute necessarily degrades another. A risk is a decision that may not survive the uncertainty in the requirements it was based on.

A worked example makes the three concrete. Calling a downstream service synchronously makes the caller's latency sensitive to the callee's response time, which is a sensitivity point: the caller is only ever as fast as its slowest dependency. Switching to asynchronous messaging improves the caller's latency and availability while giving up immediacy, since the downstream effect now lands seconds later, and that is a trade-off point rather than a free improvement. The risk is that asynchronous delivery needs retry handling and a dead-letter path, and that without them the message is dropped silently rather than loudly.

A full formal evaluation is proportionate for a small number of large decisions. For everyday ones, a decision record does the same job in three lines: what improves, what is accepted as worse, and the threshold at which the trade would need revisiting. That last line is the one most often missing and the one that matters most later, because it tells the next team what changed condition should reopen the question. An architecture with its trade-offs named is easier to maintain than one that was quietly optimised, because the next engineer can see which attribute was sacrificed on purpose.