Applied · Module 1

Architecture styles in the real world

The big styles are patterns, not rules.

45 min 4 outcomes Software Development and Architecture Intermediate

Previously

Start with Software Development and Architecture Intermediate

Layered patterns, microservices, events, data ownership and real trade offs between coupling, performance and changeability.

This module

Architecture styles in the real world

The big styles are patterns, not rules.

Integration and APIs

Systems talk in two main ways.

Progress

Mark this module complete when you can explain it without rereading every paragraph.

Why this matters

The best style is the one your team can operate safely, not the one that looks impressive on a slide.

What you will be able to do

1 Explain architecture styles in the real world in your own words and apply it to a realistic scenario.
2 Styles are patterns for organising responsibility and failure. Choose based on constraints and operations.
3 Check the assumption "Constraints are real" and explain what changes if it is false.
4 Check the assumption "Operations is considered" and explain what changes if it is false.

Before you begin

Foundations-level vocabulary and concepts
Confidence with basic diagrams and section terminology

Common ways people get this wrong

Style as ideology. When style becomes ideology, teams stop seeing constraints.
Copying case studies. Copying a famous architecture without context creates pain.

Main idea at a glance

Diagram

Stage 1

Monolith

One application, shared database, internal calls at process speed.

I think monoliths are underrated. They are straightforward to understand and deploy until they genuinely become a bottleneck.

The big styles are patterns, not rules. A monolith can be right for speed. A modular monolith gives structure without operational sprawl.

microservice is great for team autonomy when you can manage the complexity. serverless can be fast for spikes and small tasks.

Diagram

Stage 1

Team size

Single team can coordinate tightly. Multiple teams need clearer boundaries.

I think team size is often the strongest driver of architecture shape, more than any technical reason.

Style comparison pathway

Choose style from operational reality, not fashion.

Stage 1

Define delivery constraints

Understand team size, release frequency, scaling patterns, and operational maturity.

I think most teams skip this step and go straight to technology choices.

How to use Intermediate

If you can explain why you made a trade off, and what you sacrificed, you are learning architecture.

Good practice: Pick one real system and evaluate choices against non functional requirements. Latency, availability, security, cost, and operability.
Bad practice: Choosing microservices because they sound senior. You do not get points for complexity. You get paged for it.
Best practice: Write one ADR per major decision. Keep it short, include trade offs, and include how you will know if the decision was wrong.

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

Avoid these architecture style mistakes

Most style mistakes start when teams optimise for status instead of delivery outcomes.

Choosing style for prestige

Decide from constraints and operating capability, not trend pressure.
Splitting by technical layer

Boundaries should follow domain responsibility and ownership, not framework layers.
Ignoring operating cost

Count deployment pipelines, alerting burden, and on-call load before splitting services.

Verification. Questions that force honesty

Style verification checks

Run these checks before committing to a style change.

Name the likely failure mode

Define the first likely failure and the signal that will detect it quickly.
Test dependency outage behaviour

Specify what Service A does when Service B is down: timeout, queue, degrade, or fail visibly.
Confirm safe deployment capacity

Measure how many deployments your team can operate safely without service instability.

Reflection prompt

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

Mental model

Architecture styles

Styles are patterns for organising responsibility and failure. Choose based on constraints and operations.

1

Need
2

Style
3

Trade-offs
4

Operate

Assumptions to keep in mind

Constraints are real. Team size, delivery speed, and compliance shape what will work.
Operations is considered. A style you cannot operate safely is the wrong style.

Failure modes to notice

Style as ideology. When style becomes ideology, teams stop seeing constraints.
Copying case studies. Copying a famous architecture without context creates pain.

Key terms

monolith: A single deployed system where most responsibilities live together.
modular monolith: One deployable system with clear internal modules.
microservice: A small service that owns one clear job and deploys independently.
serverless: Functions that run on demand with managed infrastructure.

Check yourself

Quick check. Architecture styles

0 of 7 opened

Why choose a modular monolith

It keeps deployment simple while still enforcing boundaries.

What makes microservices difficult

Operational complexity and distributed debugging.

When is serverless useful

For event driven tasks or spiky workloads.

Scenario. A team wants microservices because 'we might scale'. What evidence would justify splitting now

Concrete bottlenecks include multiple teams blocked by deploy coupling, clear bounded contexts with stable contracts, and operational readiness such as observability, on call cover, and incident handling.

Why can a monolith be a good start

It keeps coordination simple while learning the domain.

What should guide style choice

Team maturity, delivery needs, and risk tolerance.

What is a common microservices failure

Splitting too early without strong contracts.

Artefact and reflection

Artefact

A one-page decision note with assumption, evidence, and chosen action

Reflection

Where in your work would explain architecture styles in the real world in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?

Optional practice

Toggle between styles and compare strengths and risks.