CPD timing for this level
Intermediate time breakdown
This is the first pass of a defensible timing model for this level, based on what is actually on the page: reading, labs, checkpoints, and reflection.
What changes at this level
Level expectations
I want each level to feel independent, but also clearly deeper than the last. This panel makes the jump explicit so the value is obvious.
Trade-offs, quality attributes, and pattern choice.
Not endorsed by a certification body. This is my marking standard for consistency and CPD evidence.
- 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.
Software Development and Architecture Intermediate
CPD tracking
Fixed hours for this level: 12. Timed assessment time is included once on pass.
View in My CPDIntermediate architecture is where you learn to justify trade-offs using constraints and evidence. It maps well to:
- iSAQB CPSA-F style architecture communication and reasoning
- TOGAF (orientation) for capability and target state language
- Cloud architecture certifications (AWS, Azure, Google Cloud) for system trade-offs and operating reality
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
The best style is the one your team can operate safely, not the one that looks impressive on a slide.
Style comparison
Each style trades simplicity for flexibility.
Monolith
Single deploy, shared codebase.
Modular monolith
Clear modules, still one deploy.
Microservices
Independent services and teams.
Serverless
Event driven functions.
Quick check: architecture styles
Why choose a modular monolith
What makes microservices difficult
When is serverless useful
Scenario: A team wants microservices because 'we might scale'. What evidence would justify splitting now
Why can a monolith be a good start
What should guide style choice
What is a common microservices failure
🧪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
- Choosing a style for prestige instead of constraints.
- Splitting by technical layers rather than domain responsibilities.
- Ignoring operational cost (deployments, monitoring, on-call burden).
🔎Verification. Questions that force honesty
- What is the most likely failure mode, and can we detect it quickly.
- If Service B is down, what happens to Service A. Timeouts, retries, queueing, or user impact.
- How many deploys per day can the team safely support.
📝Reflection prompt
If you were forced to simplify one system today, what would you merge and why.
Integration and APIs
Integration paths
Calls and events solve different problems.
HTTP call
Service A calls Service B and waits.
Message bus
Services publish and subscribe to events.
Quick check: integration and APIs
Why are synchronous calls risky
Why use asynchronous messaging
What is backward compatibility
Scenario: Service B is slow and Service A retries aggressively. What failure pattern can you trigger
Why version an API contract
What is a message queue for
What should an API contract always define
🧪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
- Unbounded retries, no jitter, and no circuit breaker behaviour.
- No idempotency, so retries create duplicates and corrupt state.
- No contract versioning, so small changes break consumers.
🔎Verification. Integration checklist you can run in review
- Timeouts are explicit, retries are bounded, and backoff uses jitter.
- Idempotency is defined for operations that can be retried.
- Error semantics are documented (what is safe to retry and what is not).
- Events have schemas, versioning, and a replay strategy.
📝Reflection prompt
Where would you rather pay complexity: in synchronous coupling today, or in asynchronous coordination over time.
Quality attributes and trade offs
Architects balance these qualities rather than chase perfection. A fast system that fails often is not success.
Trade off map
Quality is a balance, not a single score.
Performance
Speed and throughput.
Reliability
Availability and recovery time.
Maintainability
Ease of change and clarity.
Quick check: quality attributes
Why are trade offs unavoidable
What does availability measure
Scenario: Security proposes extra checks everywhere, product demands zero friction. What is the real job here
Why does latency matter
What is a common quality conflict
Why measure maintainability
What should guide trade off choices
🧪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
- Treating quality attributes as opinions rather than measurable constraints.
- Optimising one attribute locally and harming end-to-end outcomes.
- Ignoring the operational cost of “clever” solutions.
🔎Verification. Make the trade-off explicit
- What are we optimising for, and what are we accepting to get it.
- What is the failure cost, and how will we detect it.
- What is the rollback plan if the trade-off was wrong.
📝Reflection prompt
Which quality attribute do you personally undervalue when you are under delivery pressure. What would force you to take it seriously.
Data, state and consistency
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
Data moves through more than one store.
Database
Durable record of truth.
Cache
Fast reads, can be stale.
Message queue
State travels as events.
Quick check: data and state
Where can state live
What is eventual consistency
Scenario: The database updated but users still see old values. What is a likely cause
Why are distributed systems hard
Why use caches
What is the cost of strong consistency
Why send events
🧪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
- No cache invalidation strategy (or no monitoring for staleness).
- Treating “the database is truth” as enough when users read from projections.
- Not distinguishing read paths from write paths in incident response.
🔎Verification. Can you reason about consistency under failure
- Where is truth stored. Where do users read from.
- What happens when the message bus lags or replays.
- How do you detect staleness, not just errors.
🧾CPD evidence (keep it real)
- What I studied: architecture styles, integration patterns, quality trade-offs, and state/consistency behaviour.
- What I practised: one style choice justification, one integration flow with failure handling, and one consistency scenario write-up.
- What changed in my practice: one habit. Example: “I ask about retries and idempotency before I approve an integration.”
- Evidence artefact: a one-page design note with trade-offs and verification steps.