Skip to course content

Software Architecture revision

Applied Architecture revision

The full long-form applied notes for slower review and revision.

  • Revision
  • 23 min read
  • 4,569 words
Return to the module-first stage pageOpen the workspaceSave CPD evidence

Use this page when

You want the full longer reading path

Revision is the slower recap surface. Use it to reread, scan, or print the stage in one place after you have already worked through the module-first path.

How to use revision properly

Revision is not the default route through the course. It is the slower surface for recap, printing, annotation, or audit-friendly reading after the shorter module pages have already done the teaching work in smaller chunks.

Full stage reading

Intermediate architecture is about trade offs. We move past basic structure and focus on the choices that change how a system behaves in the real world.

Architecture styles in the real world

Learning contract

Architecture styles in the real world

The big styles are patterns, not rules. A monolith (A single deployed system where most responsibilities live together.) can be right for speed. A modular monolith (One deployable system with clear internal modules.) gives structure without operational sprawl.
microservice (A small service that owns one clear job and deploys independently.) is great for team autonomy when you can manage the complexity. serverless (Functions that run on demand with managed infrastructure.) can be fast for spikes and small tasks.

Interactive diagram

Interactive diagram

Style comparison pathway

Choose style from operational reality, not fashion.

Interactive diagram

Optional tool

Architecture style explorer

Toggle between styles and compare strengths and risks.

Use the related workspace if you need the live interactive version.

Knowledge check

Quick check. Architecture styles

Use this prompt as a self-check before you move on.

Worked example. Microservices that made delivery slower

A team splits a product into microservices early because “we will scale later”. They now have five deploy pipelines, five sets of logs, and five failure modes, but no clear contracts and no observability maturity. The result is slower delivery and harder debugging, not speed.
My opinion: start with the architecture you can operate. Evolve when you have evidence that the current shape is the bottleneck, not when you are bored.

Common mistakes in style selection

Verification. Questions that force honesty

Reflection prompt

If you were forced to simplify one system today, what would you merge and why.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Integration and APIs

Learning contract

Integration and APIs

Systems talk in two main ways. A synchronous call (A request where the caller waits for a response.) feels simple but creates tight coupling. An asynchronous message (A message sent without waiting for an immediate response.) decouples systems but adds coordination work.
Contracts matter. A contract (The agreed structure and behaviour of an API or message.) must be versioned so older clients keep working.

Integration paths

Synchronous calls and event messaging solve different risks.

Interactive diagram

Optional tool

Integration and API practice

Compare synchronous calls with asynchronous messages and see the trade offs.

Use the related workspace if you need the live interactive version.

Knowledge check

Quick check. Integration and APIs

Use this prompt as a self-check before you move on.

Worked example. A retry storm you accidentally built

Service A calls Service B synchronously. B gets slow. A times out and retries. Now A generates more traffic precisely when B is weakest. The system collapses under “helpful” retries.

Common mistakes in integration

Verification. Integration checklist you can run in review

Reflection prompt

Where would you rather pay complexity: in synchronous coupling today, or in asynchronous coordination over time.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Quality attributes and trade offs

Learning contract

Quality attributes and trade offs

latency (The time it takes for a request to receive a response.) and throughput (How many requests a system can handle in a period.) are easy to measure. availability (How often a system is able to serve requests.) is about reliability. We cannot maximise everything at once.
Architects balance these qualities rather than chase perfection. A fast system that fails often is not success.

Trade-off map

Architectural quality is portfolio management across competing outcomes.

Interactive diagram

Optional tool

Quality trade off explorer

Adjust priorities and see the balance shift.

Use the related workspace if you need the live interactive version.

Knowledge check

Quick check. Quality attributes

Use this prompt as a self-check before you move on.

Worked example. “Secure” vs “usable” is a fake argument

Someone proposes removing rate limits because it “hurts the user experience”. Another person proposes adding ten security checks to every request because “security is non-negotiable”. Both positions are lazy.
The real job is to design controls that are proportionate to risk and measured against outcomes. Example: rate limit the risky endpoints, add friction where harm is highest, and monitor for abuse.

Common mistakes in trade-off discussions

Verification. Make the trade-off explicit

Reflection prompt

Which quality attribute do you personally undervalue when you are under delivery pressure. What would force you to take it seriously.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Data, state and consistency

Learning contract

Data, state and consistency

State hides everywhere. It lives in databases, caches, and message queues. consistency (How aligned different parts of the system are at the same time.) comes in two main flavours. eventual consistency (A style where parts may disagree for a short time, but they line up if we wait.) is common in distributed systems.
Distributed systems are hard because the network is slow and things fail. You decide where you accept delay and where you need certainty.

State flow

Understand write truth, read projections, and staleness detection.

Interactive diagram

Optional tool

Consistency and state simulator

Toggle where state lives and watch it drift or align.

Use the related workspace if you need the live interactive version.

Knowledge check

Quick check. Data and state

Use this prompt as a self-check before you move on.

Worked example. The “stale price” incident

A product shows prices from a cache. The database updated, but the cache did not invalidate. Customers see stale prices, the business loses money, and everyone blames “eventual consistency” like it is a curse.
Eventual consistency is not a bug, it is a design choice. The question is whether you designed user experience, monitoring, and recovery around that choice.

Common mistakes with state

Verification. Can you reason about consistency under failure

CPD evidence (keep it real)

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.