Skip to main content

Software Architecture · Intermediate

Software Development and Architecture Intermediate

Page 2 of 4

We move from simple boxes and arrows to real world architecture styles, integration patterns and trade offs.

Core path

Your path through this level

Progress saves in this browser and syncs after you sign in

Completed
0 of 4
You will be able to
  • Explain common architecture styles and integration patterns with clear examples.
  • Apply service boundary and data ownership thinking to a realistic scenario.
  • Analyse coupling, latency, and consistency trade offs in designs.

Pick up where you left off

Architecture stylesIntegration and APIsQuality attributes and trade-offsData, state, and consistency
Optional
Full module map
Use this if you want the shape of the level before you start
Show
Module 2.1Architecture styles
Styles are patterns for organising responsibility and failure. Choose based on constraints and operations.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain architecture styles 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.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Style as ideology. When style becomes ideology, teams stop seeing constraints.
  • Copying case studies. Copying a famous architecture without context creates pain.
Module 2.2Integration and APIs
Integration is where systems fail. Make contracts and signals explicit.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain integration and apis in your own words and apply it to a realistic scenario.
  2. Integration is where systems fail. Make contracts and signals explicit.
  3. Check the assumption "Contracts are versioned" and explain what changes if it is false.
  4. Check the assumption "Failures are observable" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Distributed monolith. Tight coupling across services keeps the complexity and loses the benefits.
  • Breaking changes. Unversioned change breaks systems silently.
Module 2.3Quality attributes and trade-offs
Quality attributes are trade-offs. Choose deliberately and measure what you care about.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain quality attributes and trade-offs in your own words and apply it to a realistic scenario.
  2. Quality attributes are trade-offs. Choose deliberately and measure what you care about.
  3. Check the assumption "Qualities are measurable" and explain what changes if it is false.
  4. Check the assumption "Trade-offs are recorded" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Optimising one axis. Optimising only for speed can destroy reliability and safety.
  • Vague requirements. Vague requirements create rework and conflict.
Module 2.4Data, state, and consistency
Consistency is a decision. Choose where you need strong guarantees and where you can relax them.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain data, state, and consistency in your own words and apply it to a realistic scenario.
  2. Consistency is a decision. Choose where you need strong guarantees and where you can relax them.
  3. Check the assumption "Consistency needs are known" and explain what changes if it is false.
  4. Check the assumption "Failure is expected" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Inconsistent reads. Users see surprises when consistency is assumed but not enforced.
  • State split across systems. When state is split without clear ownership, debugging becomes slow.
Optional
Planning and evidence
Objectives, timing, and CPD tracking
Show

If you want to start learning now, leave this closed. Come back when you want to plan your practice or keep evidence for CPD. This is guidance and it is not endorsed by awarding bodies. Standards mapping lives on the course overview page.

Learning objectives

What you will be able to do

  1. 1. Explain common architecture styles and integration patterns with clear examples.
  2. 2. Apply service boundary and data ownership thinking to a realistic scenario.
  3. 3. Analyse coupling, latency, and consistency trade offs in designs.
  4. 4. Evaluate design options against non functional needs, not personal preference.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Applied

Trade-offs, quality attributes, and pattern choice.

Style
scenario
18 questions
Pass standard
Coming next
Not externally certified
▸Evidence you can save (CPD friendly)
  • A design comparison note: monolith vs modular monolith vs microservices, with your constraints and why your choice fits.
  • An integration decision: events vs API calls, including failure modes, idempotency, and monitoring signals.
  • A performance or reliability experiment note: what you measured, what changed, and what you learned.

CPD timing

Intermediate time breakdown

Defensible timing based on page content: reading, labs, checkpoints, and reflection.

Reading
30m
4,569 words × 1.3
Practice
60m
4 × 15m
Checkpoints
20m
4 × 5m
Reflection
32m
4 × 8m
Estimated total
2h 22m
Based on page content
Claimed hours
3h
Includes reattempts + capstone
Claimed hours exceed on-page estimate by ~1h. Gap will be filled with guided practice and assessment-grade work.

CPD tracking

Fixed hours for this level are 3. Timed assessment time is included once on pass.

View in My CPD
Pricing and CPDSign in to sync progress and unlock assessments
Progress minutes
0.0 hours

Learning objectives

What you will be able to do

  1. 1. Explain common architecture styles and integration patterns with clear examples.
  2. 2. Apply service boundary and data ownership thinking to a realistic scenario.
  3. 3. Analyse coupling, latency, and consistency trade offs in designs.
  4. 4. Evaluate design options against non functional needs, not personal preference.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Applied

Trade-offs, quality attributes, and pattern choice.

Style
scenario
18 questions
Pass standard
Coming next
Not externally certified
▸Evidence you can save (CPD friendly)
  • A design comparison note: monolith vs modular monolith vs microservices, with your constraints and why your choice fits.
  • An integration decision: events vs API calls, including failure modes, idempotency, and monitoring signals.
  • A performance or reliability experiment note: what you measured, what changed, and what you learned.

Learning contract

Intermediate outcomes

About 3 hours

Read the explanation first, then use the tools to test the idea. Skip any tool that is not useful for your goal.

  1. Explain common architecture styles and integration patterns with clear examples.
  2. Apply service boundary and data ownership thinking to a realistic scenario.
  3. Analyse coupling, latency, and consistency trade offs in designs.
  4. Evaluate design options against non functional needs, not personal preference.
Loading content...

Next step

Practise this level, then move on

I recommend you use the practice assessment for Applied to test your understanding and write a short reflection. Timed assessments are being prepared for this track.

Practice

Assessment

No timer

Pace

Reflection

Evidence

Practice assessment

Start the practice assessment for Applied

It is designed for confidence and evidence, and you can retry as often as you need.

Start practice assessment
The timed assessment for this level is being prepared. Use the practice assessment and labs until it is ready.

Sign in to save progress and keep your pass record

You can complete the course while signed out, and your progress saves in this browser. Sign in before assessments so your pass record is attached to your account.

Sign in for trackingContinue to AdvancedSupport us

Courses and assessments are free. There is no paywall for the learning path, practice questions, or formal assessments. Optional donations support hosting, maintenance, and ongoing updates.

During timed assessments, copy and the context menu are restricted to reduce casual cheating. Passed assessments are recorded in your account as evidence.

Course materials are protected by intellectual property rights.View terms