Stress the design before the system
Evaluate an architecture with concrete scenarios, risk questions, and measurable experiments.
BY THE END, YOU CAN
- Identify a sensitivity point and a tradeoff
- Evaluate competing designs against a scenario
- Propose a reversible evolution with measurable evidence
Diagram description: Worker crashes mid-job → Lease timeout (depends on); Lease timeout → Shorter: faster recovery; Lease timeout → Shorter: more duplicates
Walk the hardest scenario
Choose a high-priority scenario and trace it through the proposed architecture.
In Relay, a worker can finish an external effect and crash before recording success. A retry can duplicate that effect. Ask which mechanism prevents, detects, or compensates for the duplication and what assumption it relies on.
Idempotency means that repeating the same intended operation has the same effect as doing it once; the Systems under pressure stage covers it in depth. If the external provider cannot enforce idempotency, a local unique row alone does not guarantee exactly one external action: the provider may have acted before the crash, and the retry asks it to act again. Naming that limitation is a stronger architectural result than drawing an extra box labeled reliability.
Look for decisions that move several qualities
A sensitivity point is a property of one or more components, or of their relationships, that is critical for achieving a particular quality attribute response, such as a queue capacity or a timeout.
A tradeoff point affects multiple qualities in competing ways. Larger batches might improve throughput while increasing waiting time and work lost on a crash. A review should expose the relationship and propose a measurement, not promise that a pattern always wins.
The SEI’s ATAM provides a structured evaluation approach; this laboratory uses a small scenario review inspired by those concerns, not a full ATAM assessment.
Evolve with evidence and a way back
When Relay’s workload or team changes, restate the drivers and compare the existing design with the proposed one.
Define a limited experiment, a success threshold, and a rollback path. For a database migration, consider compatibility during mixed versions, backfill, validation, cutover, and restore. Also consider what rollback means after new data has been written; switching the application back may not undo a schema change.
Architecture evaluation continues after deployment through measurements and change reviews. A diagram by itself is not evidence of performance or recoverability.
COMMON FAILURE MODE
Treating a design review as proof that the system will meet its targets. Scenarios reveal risks; measurements, implementation tests, and operational evidence must follow.
TRY IT YOURSELF
For Relay, compare a database queue and a broker under a worker-crash scenario. Name one untested assumption for each, then design a small experiment to investigate it.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Review Relay with three stress scenarios. Record risks, evidence still needed, a design revision, and a rollback or recovery plan.