Start with the qualities that matter
Translate “fast”, “reliable”, and “easy to change” into scenarios you can test.
BY THE END, YOU CAN
- Distinguish a feature from a quality requirement
- Write a measurable quality-attribute scenario
- Prioritize competing architectural drivers
Diagram description: Source → Stimulus; Stimulus → Artifact; Artifact → Environment; Environment → Response; Response → Measure
A feature leaves important questions unanswered
“Submit a job” describes an ability.
It does not say how long submission may take, what happens during an outage, who is allowed to submit, or how safely the feature can change. Architecture connects these expectations to structure: processes, data ownership, interfaces, and dependencies. Start by interviewing stakeholders about consequences.
A delayed thumbnail may be tolerable; a lost payment instruction may not be. The same job-queue API can therefore require very different designs. Write the context before selecting a pattern.
Make a quality scenario observable
Give the scenario a source of stimulus, an event, an operating condition, an affected part, a required response, and a measurable outcome.
For Relay: during normal operation, a client submits one of 100 jobs per second; the API durably records accepted work and returns a job ID within 250 ms for 95% of requests. That is an example target, not a benchmark result. Specify payload size, measurement window, and failure behavior before testing.
Another scenario might ask how much code must change to introduce a new job type.
Prioritize and expose the tension
A latency target may favor acknowledging quickly, while a durability requirement demands waiting for a storage acknowledgement.
Adding replicas can improve some failure tolerance while increasing cost and coordination. Choose a small set of drivers with the people who bear these consequences. Separate hard constraints, such as an existing data-residency policy, from preferences.
Record uncertainty as a question with an experiment, owner, and review point. Architecture is not a score that can be maximized on every dimension at once.
COMMON FAILURE MODE
Choosing microservices, a database, or a cloud provider before naming the problem and the qualities that the design must preserve.
TRY IT YOURSELF
Rewrite “Relay must scale” as two measurable scenarios: a traffic surge and recovery after a worker crash. State all assumptions you would need to test them.
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
Write three prioritized Relay quality scenarios: one performance, one availability, and one modifiability scenario. Name a stakeholder for each.