Chapter 27 Flashcards — The Laws of Software Architecture, Revisited
flashcards fsa laws-of-architecture trade-offs
The Two Laws
Q: What is the First Law of Software Architecture?
A: Everything in software architecture is a trade-off. No architectural decision gains something in one dimension without costing something in another.
Q: What is the Second Law of Software Architecture?
A: Why is more important than how. The code shows how a decision was implemented; only explicit documentation preserves why it was made that way.
Q: What is the First Corollary to the First Law?
A: If an architect thinks they have discovered something that isn’t a trade-off, they just haven’t identified the trade-off yet. Hidden costs are still costs.
Q: What is the Second Corollary to the First Law?
A: You can’t do it just once. Architectural decisions are context-dependent and must be revisited as team size, scale, business domain, and technology ecosystem change.
Trade-Off Analysis: Shared Library vs. Shared Service
Q: What is a shared library in the context of code reuse, and what is its main advantage?
A: A shared library packages reusable logic as a deployable artifact (JAR, NuGet, npm package) imported at build/runtime. Main advantage: no network overhead — the call is in-process with strong compile-time typing.
Q: What is the primary disadvantage of using a shared library for code reuse?
A: Deployment coupling — when the library changes, all consumers must upgrade and redeploy together, creating coordination overhead and versioning challenges.
Q: What is a shared service in the context of code reuse, and what is its main advantage?
A: A shared service packages reusable logic as an independently deployed service consumed over a network. Main advantage: independent deployability — consumers are unaffected by service-internal changes.
Q: What is the primary disadvantage of using a shared service for code reuse?
A: Network latency on every call, availability dependency (the service must be running), and significantly higher operational overhead (deployment, monitoring, scaling, security).
Q: What is the most important question to ask when deciding between shared library and shared service?
A: How often does the shared logic change? High change frequency strongly favors a shared service; infrequent change favors a library.
Q: When should you prefer a shared library over a shared service? (Give two factors.)
A: (1) The shared logic changes infrequently, so deployment coupling rarely triggers coordination. (2) Performance is critical — the call is in a hot path where network latency is unacceptable.
Q: When should you prefer a shared service over a shared library? (Give two factors.)
A: (1) Consumers must remain independently deployable and cannot coordinate upgrades. (2) Consumers run in different technology stacks where a shared artifact format is impractical.
Trade-Off Analysis: Synchronous vs. Asynchronous Messaging
Q: What is synchronous communication and what is its defining characteristic?
A: The caller makes a direct request and blocks until the callee responds. The defining characteristic is temporal coupling — the callee must be available when the call is made.
Q: What is asynchronous communication and what is its defining characteristic?
A: The caller publishes a message to a broker (queue or event stream) and continues without waiting. The defining characteristic is temporal decoupling — the callee can be unavailable; messages accumulate.
Q: Name two advantages of synchronous communication.
A: (1) Simple request/reply mental model — easy to reason about. (2) Errors surface immediately to the caller, making error handling straightforward.
Q: Name two disadvantages of synchronous communication.
A: (1) Temporal coupling — the consumer must be available at call time. (2) Lower throughput under load — callers queue up waiting for responses.
Q: Name two advantages of asynchronous communication.
A: (1) Temporal decoupling — the system remains resilient if the consumer is down. (2) Higher throughput — callers are never blocked.
Q: Name two disadvantages of asynchronous communication.
A: (1) Complex error handling — requires dead-letter queues, poison-message strategies, and idempotency. (2) Harder to debug — requires distributed tracing and correlation IDs; eventual consistency complicates verification.
Q: When should you choose synchronous over asynchronous communication?
A: When the caller requires immediate confirmation of success or failure, when the operation must complete before proceeding, or when simplicity and debuggability are the top priorities.
Q: When should you choose asynchronous over synchronous communication?
A: When decoupling is paramount, when the system must remain resilient to consumer downtime, when high throughput is required, or when the operation is naturally fire-and-forget.
The Second Law in Practice
Q: What is the Out of Context Antipattern?
A: A pattern where an undocumented architectural decision is later “fixed” by a developer who lacks the original context — and that fix recreates the exact problem the original decision was designed to prevent.
Q: What are the four stages of the Out of Context Antipattern?
A: (1) An architect makes a context-specific decision. (2) The context is forgotten or the architect leaves. (3) A future developer finds the decision “wrong” and removes it. (4) The system breaks in the way the original decision was designed to prevent.
Q: How do ADRs (Architecture Decision Records) prevent the Out of Context Antipattern?
A: ADRs capture the context in which a decision was made, the decision itself, the consequences (benefits and costs), and the status — giving future architects the “why” that the code alone cannot convey.
Q: What four elements should an ADR capture?
A: (1) Context — the situation and constraints at the time. (2) Decision — what was chosen. (3) Consequences — both benefits and accepted costs. (4) Status — active, superseded, or deprecated.
Q: What does it mean that architectural decisions exist on a spectrum between extremes?
A: Most decisions (e.g., monolith vs. microservices) are not binary — they exist on a continuum. Good documentation captures why a specific point on that spectrum was chosen, not just which extreme was rejected.
The Second Corollary in Practice
Q: Name three context factors whose change should trigger revisiting an architectural decision.
A: Any three of: team size growth, scale change (users or data volume), new regulatory requirements, emergence of new technology that makes a workaround obsolete, or organizational restructuring (Conway’s Law).
Q: Why is the Second Corollary not a license for constant architectural churn?
A: Changing architectural decisions has real costs — migration effort, risk of instability during transition, and team disruption from re-learning and re-tooling. Revisitation should be triggered by evidence, not speculation.
Q: How do architectural fitness functions relate to the Second Corollary?
A: Fitness functions act as automated sentinels for architectural properties. When a previously passing fitness function begins to fail, it signals that the architectural decision it encodes may need revisiting given the current context.
Parting Advice
Q: What is the 20-minute rule recommended in the book’s closing advice?
A: Spend at least 20 minutes each day reading about new technologies, patterns, and approaches to keep your technical knowledge current and prevent recommendations from calcifying around an outdated landscape.
Q: Why do the authors say soft skills are as important as technical skills for architects?
A: Architecture succeeds through influence, not authority. An architect must communicate trade-offs, build consensus, negotiate constraints, and mentor developers — technically correct decisions that cannot be communicated or adopted provide no value.
Q: Complete the authors’ closing thought: “Being a software architect is a _____, not a _____.”
A: “Being a software architect is a journey, not a destination.” There is no final state of mastery — the field, context, and problems continuously evolve.
Total Cards: 28
Review Time: ~35 minutes
Priority: HIGH
Last Updated: 2026-05-29