AWS Senior-Level System Design cheat sheet · AWS

1.Designing a System on AWS, Worked Through

A senior design answer is not a diagram produced from memory. It is a short sequence: establish the requirements and the scale, derive the read and write shape from them, choose the data model, and only then pick services. Doing it in that order means every box on the final diagram has a reason, and the reasons are what is actually being assessed.

Key features

Start by separating functional requirements from non-functional ones — latency, availability, consistency and durability targets shape more of the design than the feature list does
Derive traffic numbers explicitly, including the read-to-write ratio, because a read-heavy system and a write-heavy one diverge at the first decision
Choose the data model before the database: the access patterns decide whether a key-value store or a relational one fits
Name what may be eventually consistent and what may not, because that single line determines caching, replication and queue placement
State the failure behaviour for each dependency — timeout, retry bound, and what a user sees when it is unavailable
Finish with the trade-off you made and what would change your mind, which is what distinguishes a design from a preference

The six steps, and the question that unlocks each one

The six steps, and the question that unlocks each one
Step	Ask	What the answer decides
Requirements	What must be true, and what may be approximate?	Which guarantees you are buying, and which you are not
Scale	How many, how big, how fast growing, read or write heavy?	Whether this is one instance or a fleet — and every choice after
API	What operations exist, and which block a user?	What must be synchronous, and therefore what must be fast
Data model	What are the access patterns, in order of frequency?	Key-value or relational, and the partition key
Services	Which managed service fits the shape already derived?	Compute, storage, cache, queue — as consequences, not preferences
Failure and operations	What breaks, what does a user see, what does it cost?	Whether the design survives contact with production

Six steps, in an order that cannot be rearranged

Each step is answerable only once the one above it has been. Starting at services — the usual instinct — means every later answer is a rationalisation of a choice already made.

Signature

requirements → scale → API → data model → services → failure and operations

Requirements, scale, API, data model, services, failure and operations — in that order, downward only. Do the arithmetic before naming a service, separate what blocks a user from what does not, state what may be eventually consistent, and finish with the trade-off you made and what would change it.

2.Nine System Shapes, and What Each One Is Really About

The systems that come up repeatedly are not nine unrelated problems. Each one is a familiar architecture plus one hard part, and naming the hard part is most of the answer. A URL shortener is a caching problem; a payment workflow is an idempotency problem; multi-tenant SaaS is an isolation problem. Recognising which is which is what makes the design fast.

Key features

Read-heavy systems with small datasets are caching and latency problems, not storage problems
Anything that moves money is an idempotency and auditability problem before it is a throughput problem
Fan-out systems are about per-consumer isolation — one queue and one dead-letter queue each
Multi-tenant systems are about isolation and per-tenant cost attribution, both of which are hard to retrofit
Ingestion systems are about backpressure and reprocessing: land raw, then transform
Real-time systems are about connection state and delivery semantics, which is a different problem from request throughput

Nine systems, the hard part, and the shape that answers it

Nine systems, the hard part, and the shape that answers it
System	The hard part	The shape
URL shortener	Read latency at volume over a tiny dataset	CloudFront → API Gateway/Lambda → DynamoDB, conditional write on code allocation
Notification system	Fan-out with per-consumer retry and isolation	EventBridge/SNS → one SQS queue per channel → workers, each with a dead-letter queue
File-processing pipeline	At-least-once delivery at every hop	Presigned upload → S3 → event → SQS → worker → deterministic output key
E-commerce platform	Inventory correctness under concurrency	Conditional writes for reservation, synchronous checkout, everything else on events
Payment workflow	Idempotency, auditability, reconciliation	Idempotency keys, atomic record-and-mutate, an append-only ledger, a daily reconcile job
Image processing	Bounded per-object work and cost	S3 event → Lambda for small work or ECS for large, output to a derived prefix
Multi-tenant SaaS	Isolation, and knowing what a tenant costs	Tenant in the partition key and in every IAM condition; tenant tag on every resource
Analytics ingestion	Backpressure and the ability to reprocess	Kinesis or S3 → raw zone → transform writing whole partitions → curated zone
Real-time API	Connection state and delivery semantics	API Gateway WebSockets or AppSync, connection registry, fan-out through a topic

What each system is really a problem about

Mostly asynchronousMostly synchronous

Hard because of correctnessHard because of volume

URL shortener: Read latency at volume; tiny dataset. A caching problem.
Real-time API: Connection state and delivery semantics, not request throughput.
E-commerce: Inventory correctness under concurrency, plus a long asynchronous tail.
Payment workflow: Idempotency, auditability, and reconciliation. Hard at any volume.
Multi-tenant SaaS: Isolation and per-tenant cost — both painful to retrofit.
Notification system: Fan-out with per-consumer isolation and retry.
Image processing: Bounded work per object; the pipeline shape is the answer.
File-processing pipeline: At-least-once everywhere; deterministic outputs.
Analytics ingestion: Backpressure and reprocessing. Not hard until the volume arrives.

Signature

shortener→caching · notifications→fan-out · payments→idempotency · SaaS→isolation · ingestion→backpressure

Ask what would still be hard at ten users. Correctness problems — payments, multi-tenancy, real-time semantics — earn design time immediately. Volume problems — shorteners, analytics, media pipelines — stay simple until the numbers say otherwise. The same box diagram can hide either.

3.The Sixteen Dimensions a Design Has to Cover

A complete design covers sixteen dimensions, and the ones people skip are always the same: failure modes, cost, RPO and RTO, and who operates it. Going through the list explicitly turns "we did not think about that" into "we decided that, and here is the reason" — which is the only difference that matters six months later.

Key features

The Well-Architected Framework's six pillars — operational excellence, security, reliability, performance efficiency, cost optimization and sustainability — map onto these dimensions and are the standard AWS review lens
Operational ownership is a design decision: a system with no named owner has its reliability decided by whoever is available
RPO and RTO are numbers agreed with the business, not properties discovered from the backup configuration
Cost belongs in the design because architecture dominates it — NAT, cross-AZ traffic, data transfer and logging volume are design choices
Observability is designed alongside the system: a signal nobody emits cannot be added during the incident that needs it
Naming the trade-off and what would change it is what makes a design reviewable rather than merely readable

Each dimension, the question, and the answer that is too vague

Each dimension, the question, and the answer that is too vague
Dimension	The question	Not an answer
Requirements	What must be true, and what may be approximate?	"It should be fast and reliable"
Scale	How many, how big, growing how fast?	"It needs to scale"
API	Which operations block a user?	A list of endpoints with no criticality
Data model	What are the access patterns, most frequent first?	"We will use Postgres"
Network topology	Which subnets, which egress path, which endpoints?	"It runs in a VPC"
IAM	Which roles, with which permissions, and where are the boundaries?	"Least privilege"
Compute	Why this, and why not the two alternatives?	"Containers"
Database	Why this engine and this instance class?	"It is what we know"
Cache	What is cached, for how long, and what a miss costs	"We will add Redis"
Queue	What is it absorbing, and what does a backlog mean?	"It is asynchronous"
Failure modes	For each dependency: timeout, retries, user impact	"It retries"
Observability	Which signals, and which alarm?	"CloudWatch"
Cost	What are the top three drivers?	A monthly total with no breakdown
Security	Classification, encryption, access, audit	"Everything is encrypted"
RPO / RTO	Agreed numbers, and when they were last tested	"We take backups"
Operational ownership	Which team, on call, with which runbook?	"The platform team"

Sixteen dimensions, in four groups

What it must do

Requirements

functional and non-functional, separated

Scale

rates, sizes, growth, read:write

API

operations, and which block a user

Data model

access patterns before storage

What it is built from

Network topology

VPC, subnets, egress, endpoints

IAM

roles, boundaries, least privilege

Compute

and why not the alternatives

Cache and queue

what each absorbs, and what it must not own

What happens when it breaks

Failure modes

per dependency: timeout, retry bound, user impact

Observability

metrics, logs, traces, correlation ids

RPO and RTO

agreed numbers, then tested

Security

data classification, encryption, audit

What it costs to keep

Cost

the drivers, not the total

Operational ownership

a named team, on call

Deployment and rollback

including migrations

The trade-off

and what would change it

Signature

requirements · scale · API · data model · network · IAM · compute · database · cache · queue · failure · observability · cost · security · RPO/RTO · ownership

Sixteen dimensions, and the four most often silent are failure modes, cost drivers, RPO and RTO, and operational ownership. Answer each with something that could be wrong — a number, a named driver, an agreed target, a named team — and finish by stating the trade-off you made and what would change it.