Modularity
Composing a system from parts that can be understood and replaced independently.
4 to work through
-
intermediate
A developer platform composes Postgres, an auth service, storage, realtime subscriptions and an auto-generated API into one product. What makes that modular rather than merely multi-component, and what is the test?
1 min answer -
intermediate
A startup with 20 engineers and steady moderate traffic proposes moving to microservices to prepare for growth. What would you recommend and under what conditions would you change your mind?
3 min answer -
advanced
A team is splitting a monolith into services. How do you decide where the boundaries go?
3 min answer -
advanced
A travel platform integrates hundreds of suppliers, each with different APIs, latencies, reliability and data quality. How should modularity be applied, and what specifically goes wrong in platforms that get this boundary wrong?
2 min answer
4 terms in this topic
Big Ball of Mud
A system with no discernible structure, where every change requires understanding everything - usually the result of many locally rational decisions.
conceptInformation Hiding
Designing module boundaries around the decisions most likely to change, so that a change is contained within one module.
patternModularity via the Modular Monolith
A single deployable unit with strictly enforced internal module boundaries — the default most organisations should exhaust before distributing.
practiceReplaceability Test
The evidence-based check for whether a boundary is real - not how many services exist, but whether one implementation could be swapped without touchi…
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.