Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages. Closed-book first, then open-book to fill gaps.

Current Module Questions​

Question 1: What Makes a Decision Architectural​

In one paragraph, state the two properties that make a decision architectural, and give one concrete example of a decision that looks architectural but is not.

Answer: A decision is architectural when it is (1) structural, shaping the topology, interfaces, or component boundaries of the system, and (2) hard to reverse, with high blast radius if changed later. Both properties usually coincide: structural choices propagate through code, data, and operational tooling. Example of a decision that looks architectural but is not: picking Jackson vs Gson for JSON serialization inside one service. It feels weighty because it is a library choice, but it is local, swappable module-by-module, and does not shape the system's structure; it is a design decision at best and a personal-preference decision at worst.

Question 2: Architect Roles​

Name the three archetypal architect roles in this module and give one failure mode when any single role is over-weighted.

Answer: Technical, strategic, and communicator. Over-weighted technical: the architect becomes a solo star, designs in a vacuum, produces correct but unused artifacts; nobody internalizes the decisions. Over-weighted strategic: the architect produces roadmaps and "north stars" detached from engineering reality; decisions drift from what is buildable with current teams and code. Over-weighted communicator: beautiful diagrams, confident talks, but no falsifiable fitness functions and no technical depth to catch mistakes. The role must oscillate; the mode is context-dependent, not a personality.

Question 3: Architecture vs Design vs Code​

Draw the blur line. For each of the following, classify as architecture, design, or code, and defend in one sentence: (a) switching from a monolith to two services, (b) adding an index on orders.customer_id, (c) introducing a repository pattern in one service, (d) choosing to run on Kubernetes instead of ECS.

Answer: (a) Architecture - changes deployment topology, team ownership, and failure surfaces. (b) Code/design, leaning design - local to one service's data layer; reversal cost near zero. (c) Design - affects one service's internal shape; does not change interfaces to others. (d) Architecture - changes deployment, operations, scaling primitives, and hiring; reversal cost is high. The line blurs most on (c); the test is whether the decision survives past the next refactor without anyone noticing it changed.

Question 4: Functional vs Quality Requirements​

What is the smallest rewrite that turns "the system should be fast" into a quality-attribute scenario, and why is the rewrite necessary?

Answer: Example rewrite: stimulus - a user requests a video manifest; environment - peak traffic, US region; response - manifest returned; measurable response - p95 ≤ 120 ms end-to-end. It is necessary because "fast" cannot be verified, cannot fail a test, and cannot be traded against another quality. A scenario can be monitored, alarmed, fitness-tested, and argued over with numbers. Without it, engineering has nothing to build against and no signal that performance has regressed.

Question 5: Operational Qualities Distinguished​

Distinguish performance, scalability, availability, and reliability in a single sentence each. Then give a case where a system is highly available but unreliable.

Answer: Performance = how fast one request is served. Scalability = how performance holds under load. Availability = the fraction of time the system is reachable. Reliability = the system behaves correctly when reached. Highly available but unreliable: a banking front-end that returns HTTP 200 for every request but occasionally silently loses deposit transactions; reach is 99.99%, but a percentage of successful-looking deposits are wrong, which is catastrophic. The two are different kinds of failure and need different treatments.

Question 6: Evolutionary Qualities Distinguished​

Modifiability, testability, deployability - which is usually the bottleneck for weekly releases in a 5-year-old codebase, and why?

Answer: Deployability. Modifiability is often fine locally (engineers can change code); testability is frequently improvable with targeted fakes; but deployability is systemic: shared CI, shared artifacts, shared release cycles, database migrations with production downtime, feature flags bolted on late. Weekly releases require that deploying service A does not require coordinating services B, C, D, which is a structural property of the system, not of individual modules. Fixing deployability is usually the highest-leverage evolutionary investment in a mature codebase.

Question 7: Scenario - Top-3 Characteristics (Payments)​

Given these requirements, what are the top-3 architectural characteristics? Defend.

"A payment-processing platform for a regional bank. Processes teller-initiated deposits, withdrawals, and transfers. Regulated. 99.95% availability target. Must reconcile to the cent daily. Handles up to 500 concurrent tellers. New regulatory reporting requirements arrive yearly."

Answer: Top 3: reliability (correctness is non-negotiable; a wrong transaction is a regulatory and financial event), availability (99.95% stated, and tellers cannot serve customers without it), and auditability (implicit but mandatory - regulators demand it, and "reconciles to the cent daily" is an auditability scenario). Performance and scalability are minimum-bar: 500 tellers is low, so they are acceptable-but-not-optimized. Modifiability is an important second-tier concern (yearly regulatory reporting) but does not displace auditability.

Question 8: Scenario - Top-3 Characteristics (Streaming)​

Given these requirements, what are the top-3 architectural characteristics? Defend.

"A video-streaming service with 40 million monthly active users. Users expect instant playback. Content teams need to publish and rotate metadata multiple times per day. 99.9% availability. Fault-tolerant to a single-region cloud outage."

Answer: Top 3: performance (instant-playback expectation translates into p95 manifest latency of a hundred-ish ms), availability (99.9% plus regional fault tolerance), and scalability (40 M MAU with concurrent peaks). Modifiability is a strong second tier because "publish and rotate metadata multiple times per day" demands fast iteration on the catalog layer, but the three stated are what the architecture must first support. Reliability is a minimum-bar concern here; an occasional playback retry is fine in a way it is not in banking.

Question 9: Scenario - Top-3 Characteristics (IoT)​

Given these requirements, what are the top-3 architectural characteristics? Defend.

"An IoT smart-building platform. Supports buildings with up to 50,000 devices. Operations needs better observability when devices go offline. Security is critical - penetration-test finding last year. Product ships a feature every two weeks. Integrates with many device vendors, new ones added quarterly."

Answer: Top 3: security (explicit, and the penetration-test finding makes it a known gap), modifiability/extensibility (new device vendors quarterly - this is an interface-design characteristic, not a nice-to-have), and observability (explicit - "better visibility when devices go offline"). Availability and scalability are below the line but have clear minimum bars (50K devices at sane scale, reasonable uptime). Deployability is supported by the modifiability choice rather than being a separate top-3 pick.

Question 10: Fitness Function for a Real Scenario​

Write a fitness function for this scenario: "The teller module must not depend on ledger storage internals." Include check, failure signal, and pipeline wiring.

Answer:

# import-linter contract
[importlinter]
root_packages = payments

[importlinter:contract:teller-isolated-from-ledger-internals]
type = forbidden
source_modules = payments.teller
forbidden_modules =
    payments.ledger.storage
    payments.ledger.domain.internal

Run lint-imports in CI on every pull request; build fails with the exact forbidden import and file. The signal is any new import from payments.teller into the forbidden paths. The why is that teller must talk to ledger through its public API only, to preserve the ability to replace the ledger with a different implementation or split it into a service. Ownership: architecture guild revisits the contract quarterly.

Question 11: No Right Answers​

A colleague says "microservices are objectively better than monoliths for our system." Rebut in one paragraph, without advocating for either side.

Answer: The claim is category-confused. "Better" is only meaningful against a concrete set of top-3 characteristics in a specific context: team size, change rate, deployment cadence, operational maturity, team autonomy, data coupling. Microservices buy independent deployability, scalability of individual parts, and team autonomy; they spend simplicity, local consistency, and operational overhead. A modular monolith makes the opposite trade. For a 3-engineer team on a tightly-coupled product, microservices are usually a net negative; for a 300-engineer org with independent product lines, a monolith is usually a net negative. The right first question is "which top-3 characteristics drive this system?", not "which style is better in the abstract?"

Question 12: Common Tradeoff Pair​

A system currently offers strong single-region consistency for a product catalog. The business wants the same catalog served with low latency in five regions. What changes, in one paragraph?

Answer: The system is choosing on the consistency ↔ availability (or consistency ↔ latency) axis. Strong consistency across five regions synchronously costs latency (cross-region quorum) or availability (can't write during partitions). Choosing eventual consistency in the catalog buys low-latency reads everywhere and keeps writes available locally, at the cost of windows where regions disagree briefly. For a product catalog (read-heavy, not financial, seconds of disagreement acceptable), eventual is usually right. The architectural move is to make the disagreement window explicit and bounded (e.g., "≤5 s p99 staleness") and to add a fitness function that measures it, so "eventual" does not become "unbounded."

Question 13: Reversibility Classification​

Classify as one-way or two-way and estimate reversal cost for each: (a) choosing Protobuf as the internal event format, (b) introducing a feature-flag service, (c) moving authentication from per-service to a central identity service, (d) choosing URL path versioning (/v1/...) for a public API.

Answer: (a) One-way in practice: reversing would re-encode years of historical events and update every producer and consumer; weeks to months. (b) Two-way: feature flags can be migrated between providers or removed; days, sometimes less. (c) One-way in expectation: migrating auth back out means reintroducing per-service trust stores, redistributing secrets, re-auditing; weeks, with high blast radius. (d) One-way toward the public: the URL is a public contract; the cost of changing it is the cost of migrating every client plus a deprecation runway; months to years. Changing the internal implementation behind /v1/ is two-way; changing the URL shape is not.

Question 14: Diagramming Discipline​

A colleague sends you a diagram with five unlabeled boxes connected by unlabeled arrows. What three questions do you ask before trusting it to inform an architectural decision?

Answer: (1) "Who is the audience and what decision does this support?" - without an audience, shape and detail are arbitrary. (2) "What is the scope and what is deliberately left out?" - a diagram without explicit scope is a diagram without a frame; readers fill the gaps with guesses. (3) "What do the boxes and arrows mean individually?" - is a box a process, a team, a service, a logical module? Is an arrow a network call, a data flow, a dependency, an event? Without a legend, two readers will infer two different systems from the same picture. A diagram that cannot answer these is a prompt for conversation, not an architectural artifact.

Question 15: Architectural Risk and First Principles​

Your team proposes introducing Kafka between the order service and the shipping service "because event-driven is more scalable." From first principles, what is the minimum evidence you need before accepting the proposal?

Answer: From first principles: (1) the problem - what failure or quality gap is this solving? Coupling during shipping outages? Back-pressure? Replayability? "More scalable" is not a problem. (2) the current measure - what is the current coupling cost or latency under shipping slowness, and what is the target? (3) the top-3 characteristic it supports - availability? modifiability? performance? The characteristic decides whether the move is right. (4) the spends - operational complexity, eventual consistency in shipping state, schema governance of events, the new failure modes of Kafka itself. (5) alternatives considered - timeout + retry + circuit breaker? bulk-sync? queue-as-library? Without at least these five, the proposal is cargo-culted; with them, the same proposal might be unambiguously right or wrong depending on the numbers.

Interleaved Review Questions​

Prior Module Question 1 (S6M4: Consistency models)​

How does the choice between strong and eventual consistency show up as a quality-attribute tradeoff in this module?

Answer: Consistency ↔ availability under partitions is the most common architectural tradeoff pair. Strong consistency prioritizes reliability and correctness; eventual consistency prioritizes availability and latency. The module's framing extends this beyond "CAP theorem trivia" into architectural practice: the tradeoff is picked per-subsystem (strong for ledger, eventual for catalog), and each choice is expressed as scenarios with measurable bounds on the disagreement window.

Prior Module Question 2 (S6M3: Distributed systems failure modes)​

Failures in distributed systems are partial and concurrent. Which architectural characteristics from Cluster 2 does this primarily force into the top-3 in that kind of system?

Answer: Availability and reliability move into the top-3 almost by default, because every remote call is a potential partial failure. Observability also moves up implicitly - without it, partial failures are invisible until customers notice. The module's approach is to make that implicit explicit: add observability as a characteristic with a fitness function, not just as a monitoring backlog item.

Prior Module Question 3 (S3M2: API design and versioning)​

Why is "we'll ship /v2 when we need to change the contract" a quality-attribute decision, not just an API decision?

Answer: It is a statement about modifiability (how you make the contract evolve) and compatibility (an implicit quality in any system with external consumers). Versioning strategy is an architectural decision because it is hard to reverse once external clients depend on it, it affects gateway, caching, and routing infrastructure, and it shapes the team's ability to make changes without cross-team coordination. The module's lens forces that framing: the API decision is a quality-attribute decision.

Prior Module Question 4 (S3M4: Scaling patterns)​

A team says "we need to make the system scale." Rewrite that as a quality-attribute scenario and name what the team actually needs to decide.

Answer: Scenario shape: stimulus - peak traffic of 50k RPS during a retail event; environment - full production with caches cold; response - all endpoints return within their current SLOs; measurable response - p95 < 150 ms and error rate < 0.5%. What they actually need to decide: which subsystem must scale (not "everything"), which scaling axis (stateless compute, data store, event throughput), and what the budget is (cost and complexity). "Make it scale" is an adjective; the scenario forces structural choices.

Prior Module Question 5 (S6M1: Testing and coverage)​

How does testability in this module differ from "write more tests"?

Answer: Testability is a structural property: how easily you can verify the system's behavior in isolation and at speed. Writing more tests is a consequence; architectural choices that enable it are the cause. Pure functions, small seams between modules, configurable side effects, and replaceable external dependencies (fakes for databases, queues, time) are the architectural moves that make testing feasible. A system can have 90% line coverage and zero testability if every test must stand up a Kafka cluster and a Postgres instance to pass.

Self-Assessment and Remediation​

Mastery Level (90-100% correct): Ready to advance to Module 2 with confidence. You treat "architectural" as a property (structural + hard to reverse), can extract a defensible top-3 from requirements, and think in scenarios with measurable responses. Continue to Module 2 on module boundaries and DDD framing.

Proficient Level (75-89% correct): Review the concept pages you missed, then redo either Practice 2 (Characteristics-from-Requirements Workshop) or Practice 3 (Tradeoff Analysis Clinic) depending on where the misses cluster. If the misses are in scenarios (Q7-Q9), redo Practice 2. If they are in tradeoffs (Q11-Q13), redo Practice 3.

Developing Level (60-74% correct): Rework Clusters 2 and 3 from the concept pages. The weakness is usually confusion between quality attributes (the general catalog) and architectural characteristics (the system-specific top few). Redo Practice 1 and Practice 2 in sequence, then retake the quiz, focusing on the scenario questions. Expect "scenario form with measurable response" to feel unnatural at first - that is the specific skill this level lacks.

Insufficient Level (< 60% correct): Restart from Cluster 1 Concept 1. The most likely root cause is treating architecture as code patterns or framework choices, rather than as structure + hard-to-reverse decisions. Until "is this actually architectural, or is it design?" is a reflex question, Clusters 2-5 cannot land. After redoing Cluster 1, pair with Cluster 4 (Tradeoffs) before Cluster 2 or 3; without the tradeoff mindset, the -ilities feel like a memorization list rather than a decision framework.