Modular Monolith
Enforced internal boundaries without a network between them.
5 to work through
-
intermediate
A product team of fifteen engineers must choose between a modular monolith and services. What should decide it?
2 min answer -
intermediate
A team adopts a modular monolith. What must they do forever, and what happens if they stop?
2 min answer -
intermediate
A team chooses a modular monolith over microservices. What makes the module boundaries actually hold, and what signals indicate it is time to extract a service?
3 min answer -
intermediate
What mechanically enforces module boundaries in a monolith, and what happens without enforcement?
2 min answer -
advanced
A productivity app keeps a full local database on each client and syncs deltas with the server. Why would a small team choose this over conventional REST, and how are optimistic updates, conflicts, permission changes and client schema migrations handled?
3 min answer
6 terms in this topic
Architecture Fitness Test
An automated check in the build that fails when code violates the intended module dependency rules - the mechanism that decides whether architectural…
patternModular Monolith Boundaries
A single deployable unit with strictly enforced internal module boundaries, giving domain separation without distribution.
practiceModule Dependency Enforcement
Automated checks that prevent one module from importing another's internals, giving a monolith the boundary discipline of separate services.
conceptModule Public Surface
The set of types a module lets other modules reach, which decides how much of it can be rewritten or extracted without touching anyone else's code.
case-studyShopify: A Monolith That Scaled
Shopify kept its Rails monolith and invested in enforced internal boundaries and horizontal sharding, rather than decomposing into microservices.
patternSync Engine
A client-side database kept continuously in sync with the server through deltas, so every read and write is local and instantaneous - moving the netw…
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.