Chapter 3 Flashcards — Architectural Modularity
flashcards saht modularity decomposition
What is a “modularity driver” in SAHT, and why must architects identify it before designing a decomposition?
?
A modularity driver is a specific, measurable business or technical goal (e.g., scalability, deployability) whose achievement requires modular architectural boundaries. Architects must identify the driver first because decomposition has real costs (network latency, distributed consistency, operational overhead); without a driver, those costs have no offsetting business benefit. Driver-first design prevents decomposing for fashion rather than need.
Name the five primary modularity drivers from Chapter 3.
?
- Maintainability — reduce cognitive load, clarify ownership, bound blast radius of changes
- Testability — enable isolated unit/component testing, faster CI pipelines
- Deployability — enable independent release cycles per team/component
- Scalability — enable independent scaling of hot-path components
- Availability / Fault Tolerance — isolate failures so one component’s crash doesn’t take down others
Which modularity drivers can often be satisfied by a well-structured modular monolith (no deployment separation)?
?
Maintainability and testability can frequently be satisfied without separate deployment units. Good internal package/component boundaries, clear interfaces, and encapsulation within a single deployable artifact address these drivers. Architects should resist the cost of full service decomposition unless deployability, scalability, or availability drivers are also present.
Which modularity drivers require actual deployment separation (separate runtime processes)?
?
Deployability, scalability, and availability/fault tolerance all require separate deployment units because:
- Deployability: independent release requires independent deployment artifacts
- Scalability: independent scaling requires independent runtime processes
- Availability: fault isolation requires process-level boundaries (a crash in process A cannot kill process B)
What is the “modularity vs. complexity curve” insight from Chapter 3?
?
Decomposition benefits follow a curve with an optimal peak: as you add module boundaries, benefits initially rise (faster teams, independent scaling, fault isolation), but eventually the coordination overhead, network complexity, distributed consistency costs, and operational burden begin to outweigh the gains. Over-decomposition — adding service boundaries beyond what drivers require — produces negative net value. The goal is the minimum granularity that satisfies the identified drivers.
How does the availability math change when moving from a monolith to isolated services?
?
In a monolith, component availabilities multiply: five components at 99.9% each yield 0.999^5 ≈ 99.5% combined (~43 hours of downtime/year), because any single failure takes down the whole system. With proper fault isolation in distributed services, component failures become partial degradations rather than full outages — critical paths can maintain their own SLA independently of non-critical components. The math shifts from multiplicative failure to independent failure.
What is the “availability anti-pattern” of an un-hardened distributed system?
?
A distributed system without explicit resilience patterns (circuit breakers, bulkheads, timeouts, retries with backoff, health checks) can have worse availability than a monolith. Partial failures cascade in unexpected ways — a slow downstream service causes upstream threads to block, exhausting connection pools and crashing callers. Decomposition does not automatically improve availability; it requires deliberate fault-isolation design.
Why is premature decomposition (before domain boundaries are understood) dangerous?
?
Premature decomposition creates a distributed monolith — services that are separately deployed but still tightly coupled at the data or API level. This has the worst of both worlds: all the operational costs of distributed systems (network calls, distributed consistency, deployment pipelines) with none of the independence benefits (teams still block each other, failures still cascade). Domain boundaries should stabilize before service boundaries are cut.
What does the Sysops Squad saga use to justify decomposition in Chapter 3?
?
Penelope (the architect) maps each specific business pain to a modularity driver:
- Deployability: four teams block each other on releases
- Scalability: ticket routing overwhelmed during peaks, must scale entire monolith
- Availability: reporting component’s DB pool exhaustion takes down customer-facing ticket creation
- Maintainability: new developers take 3-4 months to become productive
She then quantifies the cost of the current situation vs. estimated decomposition cost, making a data-driven business case rather than an architectural opinion.
What is the “just enough” principle for modularity in SAHT?
?
Each modularity driver has a minimum decomposition level at which it is satisfied — decomposing further adds costs without additional benefit for that driver. For example: maintainability may be satisfied by modular internal structure (no deployment split); deployability requires at minimum separate deployment units; fine-grained microservices are only justified when multiple high-priority drivers apply simultaneously. Architects should deploy the minimum separation that satisfies all identified drivers.
What is a “breaking point” in the context of monolith decomposition?
?
The breaking point is the threshold at which the ongoing cost of NOT decomposing (lost velocity, downtime cost, scaling spend, etc.) exceeds the one-time and ongoing cost of decomposing. Architects use modularity driver analysis to calculate this threshold explicitly. Before the breaking point, the monolith is still the right answer; after it, decomposition has positive ROI.
How does scalability as a modularity driver differ from the other four drivers?
?
Scalability is distinct because it requires both application decomposition AND often data decomposition to be effective. If the bottleneck is the shared database rather than the application tier, decomposing services without partitioning the data yields minimal scaling benefit — the database becomes the new monolith. This is why the book dedicates Chapter 6 specifically to “Pulling Apart Operational Data” as a companion topic to service decomposition.
What is “coupling cost” and how does decomposition affect it?
?
Coupling cost is the price paid for every inter-module dependency — in latency (in-process ns vs. network ms), reliability (method calls don’t fail; network calls do), cognitive complexity, and operational overhead. Decomposition reduces domain coupling (unrelated features no longer share a codebase) but introduces network coupling (services depend on each other over the network). The net cost depends on whether the domain coupling being removed was more expensive than the network coupling being introduced.
What six steps does SAHT suggest for building the business case for decomposition?
?
- Identify business problems — document current pain in business terms (not tech terms)
- Map to architectural drivers — translate each pain to one or more of the five drivers
- Prioritize drivers — rank by business impact
- Identify architectural characteristics — determine what the drivers require (elasticity, fault tolerance, etc.)
- Map to components — identify which existing components block the required characteristics
- Quantify cost vs. benefit — estimate decomposition cost vs. ongoing pain cost for the executive case
Why might a company have a deployability problem even if their architecture is perfectly designed?
?
Deployability is a process problem as much as an architecture problem. Even with separate services, if teams share a deployment pipeline, require joint approval processes, or have implicit ordering dependencies (service B always deployed after service A), independence is illusory. Architectural decomposition is a necessary but not sufficient condition — it must be accompanied by team autonomy, independent CI/CD pipelines, and contract discipline (backward-compatible APIs).
What is the relationship between testability and deployability as modularity drivers?
?
Testability and deployability are complementary drivers that together form the CI/CD argument: independent deployability requires high confidence from automated tests, which requires testability. Systems with poor testability (long test suites, brittle integration tests, high false-positive rates) cannot safely achieve frequent independent deployments even if architecturally capable. The two drivers reinforce each other — solving one without the other gives partial benefit.
In SAHT Chapter 3, what does “maintainability” actually mean at an architectural level?
?
Maintainability means minimizing the cognitive load required to safely change a system. At the architectural level, this requires:
- Bounded blast radius: a change to module A cannot silently break module B
- Clear ownership: each component has an identifiable owning team
- Understandable interfaces: public contracts are explicit and stable
- Manageable scope: no single developer needs to understand the entire system to contribute
These can be achieved within a monolith through disciplined component architecture before committing to distributed deployment.
What is the key difference between how SAHT frames “scalability” vs. how it’s commonly understood?
?
Commonly, scalability means “can the system handle more load.” SAHT frames it more precisely as independent scalability of components with different load profiles. The business value is not just handling more total load, but efficiency: not scaling cold components alongside hot ones wastes money. The architectural requirement is therefore the ability to add resources to the specific component experiencing load without touching the rest of the system.
True or false: SAHT argues that microservices architecture is the correct solution whenever multiple modularity drivers are present simultaneously.
?
False. The authors explicitly argue that microservices (fine-grained services) are only justified when multiple high-priority drivers apply AND the team has the operational maturity to manage distributed systems. Even with multiple drivers present, a coarse-grained service decomposition (a few larger services rather than many small ones) may be the correct answer. The minimum granularity that satisfies all drivers is always the recommended starting point.
How does the Sysops Squad saga illustrate “selective decomposition”?
?
After identifying modularity drivers, Penelope’s team finds that different components need different levels of separation:
- Ticket creation and expert assignment: need independent scalability → full service separation
- Reporting component: needs fault isolation → separate runtime process
- Internal admin tools: no strong drivers → can remain more coupled, possibly in a modular monolith
This selective approach — decomposing to the minimum required by each component’s drivers — avoids the cost of uniformly fine-grained decomposition across the entire system.
What “threshold signals” indicate the scalability driver is present?
?
- Inefficient horizontal scaling: scaling idle components alongside hot ones to handle peak load
- Single-process limits: hitting memory or CPU ceilings that can’t be solved by adding instances
- Impractical auto-scaling: the monolith’s startup time is too slow for elastic scaling (minutes to start vs. seconds of load spike)
- Cost anomalies: infrastructure spend growing faster than load due to over-provisioning required by monolithic scaling
What “threshold signals” indicate the availability/fault tolerance driver is present?
?
- Unrelated component failures taking down customer-facing functionality (e.g., reporting crashes kill ticket creation)
- SLA targets being missed despite component-level reliability improvements
- Post-mortems revealing cascading failures from single-component bugs
- Full system restarts required to recover from partial failures
- Inability to run zero-downtime deployments because any deployment puts the whole system at risk
What does SAHT mean by the term “architectural characteristic” and how does it relate to modularity drivers?
?
An architectural characteristic (from earlier in the book, building on “software quality attributes”) is a measurable dimension of system behavior: elasticity, deployability, fault tolerance, testability, etc. Modularity drivers map business pain to architectural characteristics as an intermediate step:
- Business pain: “The system goes down when one thing fails” → Driver: Availability → Characteristic: Fault tolerance
- Business pain: “We can’t ship fast enough” → Driver: Deployability → Characteristic: Deployability/elasticity
Identifying the required characteristics then determines which decomposition patterns and deployment strategies are needed.
Why does SAHT emphasize that “no best practices exist” in the context of modularity?
?
Because the value of any modular boundary is entirely context-dependent. A boundary that dramatically improves one system (because a specific driver applies) may add pure cost to another system (where that driver doesn’t apply). Prescribing “always decompose to microservices” or “always use a monolith” ignores this context dependency. The book’s core thesis is that trade-off analysis against specific business drivers — not universal rules — is the correct architectural method.
Total Cards: 24
Priority: HIGH
Last Updated: 2026-05-30