Free lesson · AWS Solutions Architecture
How to read a requirement and produce an architecture
The Failure That Precedes All The Others
Someone describes a system. Within two minutes, services are on the whiteboard.
Important: Reaching for services before understanding requirements is the defining failure of inexperienced architecture, and it is invisible from the inside - the design looks decisive and it is a guess with a diagram attached.
The reason it happens is that services are the familiar part. You know what Lambda does; you do not yet know what this system needs. Naming services feels like progress and defers the harder work.
The discipline: no service names until the non-functional requirements are written down. That single rule changes the quality of the output more than any amount of service knowledge.
Functional requirements tell you what the system does. Non-functional requirements determine what it looks like. Two systems that do the same thing - one serving a hundred users at 500 ms, one serving ten million at 50 ms with a four-nines target - share almost no architecture.
The Sequence
graph TD
R[**Requirements** - functional<br/>and non-functional] --> C[**Constraints** - budget, timeline,<br/>team, compliance, existing systems]
C --> Q[**Quality attributes** - which<br/>matter most, and their conflicts]
Q --> D[**Decisions** - each with a<br/>stated trade-off]
D --> A[**Architecture**]
A --> V[**Validate** against every<br/>requirement and assumption]
V -->|Gap or bad assumption| R
V -->|Holds| DOC[**Document** - ADRs,<br/>assumptions, trade-offs]
This diagram shows the architecture method. Requirements, both functional and non-functional, lead to constraints covering budget, timeline, team, compliance, and existing systems. Those produce quality attributes, identifying which matter most and where they conflict. Quality attributes drive decisions, each with a stated trade-off, which produce the architecture. The architecture is validated against every requirement and assumption; a gap or a bad assumption sends you back to requirements, and a design that holds is documented as architecture decision records with assumptions and trade-offs.
The loop matters. Validation that finds a gap is the method working, and an architecture that never returns to requirements was not validated.
The Questions To Ask
In roughly this order, because later answers depend on earlier ones.
Function. What does it do? Who are the actors? What are the critical paths - the operations whose failure matters most?
Scale and shape. How many users, from where? What is the traffic shape - peak to mean ratio, growth rate, and whether spikes are predictable? What is it today, and in eighteen months?
Data. Volume, growth, and shape. What are the access patterns - every query the system will make? Sensitivity and classification. Retention and deletion obligations.
Latency. Per operation, not overall. A p99 target for the checkout path and for a background report are different numbers, and treating them as one produces an over-engineered background job or an under-engineered checkout.
Availability. The target, and - the question that actually determines it - what does an hour of downtime cost? Module 01 Topic 3.
Consistency. Where is eventual consistency acceptable, and where is it not? This is a business question phrased technically, and it needs a business answer.
Budget. For infrastructure, and separately for engineering. Module 03 Topic 4.
Team. Size, skills, on-call capability. The strongest architecture the team cannot operate is worse than a simpler one they can.
Timeline. What must ship when, and what can follow.
Constraints. Compliance, data residency, existing systems, licensing, contractual obligations, organisational structure.
The Requirements Nobody Volunteers
Tip: The requirements that determine architecture are the ones stakeholders do not think to mention, because to them they are assumptions rather than requirements.
The specific ones worth asking for every time:
What is the traffic shape, not just the volume? "A million requests a day" is compatible with a steady 12 per second and with a million in one hour. Those are different systems.
What happens when it is down? Not the availability target - the actual consequence. It calibrates everything.
What must never be lost? Some data can be regenerated. Some cannot. Nobody states this unprompted, and it determines the durability and backup architecture.
Who else uses this data? An analytics requirement discovered after launch changes the data architecture.
What regulatory obligations apply? Frequently answered with "none" and then, on a specific question, with a data residency requirement that eliminates half the design.
What are the existing systems this must work with? The integration constraint is usually larger than the greenfield problem.
Asking these is the single highest-return activity in early architecture, and the answers routinely change the design.
Quality Attributes And Their Conflicts
You cannot maximise everything. The architect's job is knowing which trade you are making and saying so.
| Wanting more | Costs |
|---|---|
| Availability | Cost, and complexity |
| Strong consistency | Latency, and availability under partition |
| Low latency | Cost, and often consistency |
| Security | Operational friction, and sometimes latency |
| Low cost | Usually resilience or performance |
| Operational simplicity | Flexibility, and sometimes cost |
| Speed to deliver | Almost everything else |
Important: Rank the quality attributes explicitly with the stakeholders, before designing.
A ranked list - availability first, then cost, then latency, then everything else - resolves every subsequent argument by reference rather than by seniority. Without one, each decision is relitigated and the loudest person's preference wins.
The ranking is a business decision and it must come from the business. An architect who ranks them alone has substituted their judgement for the organisation's priorities, and the design will be right for a problem nobody has.
Decisions And Their Trade-Offs
Every architectural decision costs something. A decision presented without its cost has not been analysed.
The form that forces it: "We will use X. This gives us A and B. It costs us C. We accept C because of requirement R. The alternative was Y, which we rejected because Z."
Write it down as an ADR - an architecture decision record:
| Section | Contains |
|---|---|
| Context | The requirement or force driving this |
| Decision | What we are doing |
| Alternatives considered | And why each was rejected |
| Consequences | Both positive and negative |
| Status | Proposed, accepted, superseded |
Tip: The consequences section is the one that earns its keep, and it must include the negative ones.
An ADR listing only benefits is a justification rather than a record, and it fails at the moment it is most needed - eighteen months later, when someone asks why the system works this way and whether the reason still holds.
Recording the accepted cost is what makes the decision revisitable. "We chose DynamoDB, accepting that adding a new access pattern requires an index or a migration" tells a future engineer both what was decided and what to check when the requirement changes.
ADRs are cheap - a page - and they are the highest-return documentation an architect produces.
Assumptions
Every architecture rests on assumptions, and unrecorded assumptions are how designs fail silently.
Keep an assumption register. For each: what was assumed, why, what happens if it is wrong, and how you would find out.
The assumptions that matter most are usually about scale ("traffic will grow 20% annually"), about behaviour ("users access recent data far more than old"), about the organisation ("the team will grow to eight"), and about dependencies ("the partner API will remain available").
Validate the load-bearing ones. An assumption about the access pattern distribution can be checked against existing data in an afternoon, and if it is wrong the entire storage design changes.
Validating The Design
Before committing, walk it against the requirements explicitly.
| Check | Question |
|---|---|
| Requirement coverage | Does each stated requirement have a mechanism? |
| Failure walk | For each component: what happens when it fails? |
| Load walk | At 10× traffic, what breaks first? - Module 03 Topic 2 |
| Cost model | What does this cost at expected and at peak volume? |
| Operational walk | Who operates it, and can they? |
| Security walk | What does a compromise of each component give an attacker? |
| Day-two walk | How is it deployed, monitored, and changed? |
Warning: The failure walk is the one that finds the most, and it is skipped most often because the design looks complete.
Take each component and ask: what happens when this fails, when it becomes slow, and when it returns wrong answers? The third question is the one nobody asks, and a dependency returning plausible wrong data is a failure mode most designs have no answer for.
A component whose failure has no designed response is a single point of failure regardless of how many instances it has.
Sizing And Growth
Design for the scale you will have, plus one order of magnitude. Not three.
Tip: Designing for 100× current scale is a common and expensive error, and it is usually justified as future-proofing.
The costs are real: complexity that slows delivery, operational burden the team cannot carry, cost for capability nobody uses, and a design optimised for a shape the business may never take.
A rewrite at 10× is a normal and healthy event. The system that got you to 10× taught you what the next one needs - knowledge you did not have at design time and could not have guessed.
Design for 10×, and make the decisions that are expensive to reverse correctly. Data models, partition keys, account and network topology, and API contracts are hard to change. Compute choices, caching, and most service selections are not. Spend the architecture effort on the irreversible half.
Common Failure Modes
Warning: Services chosen before requirements are written.
Non-functional requirements never elicited. The ones that determine the design.
Traffic shape unknown. Volume without shape is not a requirement.
Quality attributes unranked. Every decision relitigated.
Decisions without stated costs. Not analysed.
No ADRs. Rationale lost within a year.
ADRs listing only benefits.
Assumptions unrecorded and unvalidated.
No failure walk. Components with no designed failure response.
Designed for imagined scale. Complexity for capability nobody uses.
The team's capability ignored. An architecture nobody can operate.
Architecture treated as a one-shot artefact.
Why This Matters In An Interview
Interview: This is the meta-skill every system design interview is actually testing, and the strongest signal is asking questions before designing.
What interviewers are listening for:
- Requirements and constraints elicited before any service is named.
- Traffic shape, not just volume.
- Trade-offs stated explicitly for each decision.
- Designing for 10×, not 100×.
Common follow-ups:
- "Design a system for X." → Ask before designing: scale and shape, latency per operation, availability target and what downtime costs, consistency requirements, data access patterns, budget, team, and constraints. Candidates who start drawing are answering a question they have not understood.
- "Why did you choose that?" → State the requirement it serves, the alternative rejected, and what this choice costs. A decision without a cost has not been analysed.
- "What if traffic is 100× what you designed for?" → It would need rearchitecting, and that is correct. Designing for 100× today means carrying complexity for capability nobody uses. The decisions worth getting right now are the irreversible ones - data model, partitioning, topology.
- "What assumptions did you make?" → Name them, say which are load-bearing, and say how you would validate each. An architect who cannot list their assumptions has not identified them.
Practice
Exercise: Starter. Take a system you know and write its non-functional requirements as they would have been stated at design time. Note how many were never explicitly agreed.
Intermediate. Write an ADR for a significant decision in an existing system, including the alternatives and the negative consequences. Ask whether the reasoning still holds.
Advanced. Run a failure walk on an existing architecture: for each component, what happens when it fails, when it is slow, and when it returns wrong answers. The third column will be mostly empty.
Related Topics
- Topic 2 - Well-Architected as the review lens
- Topic 3 - Availability requirements and their cost
- Module 03 Topic 4 - Cost as a design constraint
- Module 04 Topic 2 - Reference architectures as starting points