beginnerintermediateadvanced

AWS · Section 64

AWS Senior-Level System Design

Level: advanced
Read: 40 min
Concepts: 3

A senior design answer is a derivation rather than a recollection, and it runs in an order that cannot be rearranged: requirements, scale, API, data model, services, then failure and operations. The arithmetic comes before any service is named — requests per second, object sizes, growth rate and the read-to-write ratio rule out most architectures before anyone proposes one — and the consistency allowance is stated explicitly, because that single line authorises every cache in the design and bounds how stale each one may be. A design built this way can be perturbed: change one requirement and the services change, which is the test that separates a derived answer from a remembered diagram. The systems that recur are not nine unrelated problems but nine familiar architectures each with one hard part, and the question that names it is what would still be difficult with ten users. Payments, multi-tenancy and real-time semantics answer yes and earn design time immediately; URL shorteners, analytics ingestion and media pipelines answer no and stay simple until the numbers demand otherwise — which is why an image pipeline and a payment workflow can draw identically on a whiteboard and share none of the actual difficulty. Finally, a complete design covers sixteen dimensions, and the four most often silent are always the same: failure modes per dependency, the top cost drivers, agreed RPO and RTO numbers, and a named operational owner. None of those produce a visible symptom before production, which is exactly why they have to be checked deliberately, and each one is only covered when its answer is specific enough to be wrong.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

Numbers before boxes: four figures narrow the design more than any preference.
The consistency allowance is what authorises and bounds every cache.
Each recurring system is a known architecture plus one hard part.
What would still be hard at ten users tells you where to spend the design.
Failure modes, cost, RPO/RTO and ownership are the dimensions people skip.

What you will be able to do

Derive a design from requirements and arithmetic rather than recalling a diagram
Work a full system end to end and justify every service from an earlier step
Name the hard part of a system before drawing anything
Review a design against sixteen dimensions and find the silent ones
State a trade-off and the condition that would reverse it

Derive, recognise, then check for the silent gaps

Derive the design

requirements → scale → API → data → services

Name the hard part

caching, idempotency, isolation, backpressure

Check all sixteen dimensions

especially failure, cost, RPO/RTO, ownership

AWS Senior-Level System Design

The order design questions have to be answered in, the nine recurring systems and what each is really a problem about, and the sixteen dimensions a complete design covers.

Designing a System on AWS, Worked Through

coreadvanced

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.

Think of it as

Numbers before boxes. Requests per second, object sizes, growth rate and read-to-write ratio narrow the service choice far more than any preference does — a hundred writes a second and a hundred thousand are different systems, and nothing about the diagram is decidable until you know which one you are drawing.

What we're doing: Design a URL shortener end to end, showing where each decision comes from.

url-shortener.txttext

1 REQUIREMENTS
  Create a short code for a URL; redirect fast. Codes never
  change once issued. Redirects may serve a value up to a minute
  stale. Creation must be strongly consistent — two users must
  never receive the same code. Target p99 redirect under 50 ms.

2 SCALE
  100M links, 5,000 redirects/sec at peak, 50 creates/sec.
  ~20 GB of data. Read-to-write ratio 100:1.
  → A read-latency problem over a small dataset.

3 API
  POST /links   {url} → {code}     synchronous, must be correct
  GET  /{code}         → 301        synchronous, must be fast
  Analytics on redirects: NOT on the critical path.

4 DATA MODEL
  One access pattern dominates: look up a URL by code. That is
  a key-value read, so DynamoDB with code as the partition key.
  No relational shape is needed and none is invented.

5 SERVICES — every one a consequence of steps 1 to 4
  CloudFront            5,000/sec of cacheable redirects, cached
                        at the edge; a minute of staleness was
                        explicitly allowed in step 1
  API Gateway + Lambda  50 creates/sec; per-request billing fits
  DynamoDB              key-value reads, on-demand capacity
  Conditional write     attribute_not_exists(code) makes code
                        allocation safe under concurrency
  Kinesis → S3          redirect events, off the critical path

6 FAILURE AND OPERATIONS
  DynamoDB unavailable → redirects still served from the edge
                         cache; creates fail loudly with a 503
  Cache miss storm     → 5,000/sec against DynamoDB, which
                         on-demand capacity absorbs
  Observability        → redirect latency p99, cache hit ratio,
                         create error rate, throttling
  Cost driver          → CloudFront requests, not DynamoDB

THE TRADE-OFF, STATED
  Caching redirects at the edge is what meets the latency target,
  and it is why a deleted link can still resolve for up to a
  minute. That was allowed in step 1. If it were not allowed,
  step 5 would be a different design — that is the sentence
  that shows the design was derived rather than recalled.

1: The staleness allowance in step 1 is what makes step 5 possible; without it the whole design changes.
7: The ratio, not the raw count, is what tells you this is a caching problem rather than a throughput problem.
13: Separating what blocks a user from what does not is the decision the rest of the design is built on.
20: One dominant access pattern means one store and one key — resisting a richer model is part of the answer.
28: Naming what would change the design is what turns a diagram into an argument, and it is what is actually being assessed.

Why this works: The finished diagram for a URL shortener is well known, which makes it a poor demonstration on its own. What is worth seeing is that every box is entailed by a number or a requirement stated earlier — and that changing one line in step 1 changes step 5. A design that cannot be perturbed like that was recalled, not derived.

Choosing services before doing the arithmetic

Wrong

text

# "We will use ECS behind an ALB with Aurora and Redis."
# (Said before anyone has asked how many requests per second.)

Better

text

# 5,000 reads/sec, 50 writes/sec, 20 GB, one access pattern.
# Those four numbers rule out most options and rule in the rest.

What you see: The design cannot answer "why not something simpler", because there is no derivation to point at — only a preference.

Why: Services chosen first become constraints that later requirements have to fit around, so the arithmetic ends up justifying the choice instead of driving it. Deriving the numbers first usually produces a simpler system, and always produces one whose choices can be defended when a requirement changes.

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.

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

Together

text

# The arithmetic that changes the answer, done out loud
100M short links, 10:1 read:write, 500 reads/sec average,
5,000/sec peak, ~200 bytes per record.

  storage   100M × 200 B  ≈ 20 GB   → small; not a constraint
  writes    ~50/sec                 → trivial for any store
  reads     5,000/sec peak          → the only real number here

# Conclusion, derived rather than assumed: this is a
# read-latency problem with a tiny dataset. That rules out most
# of the architectures people reach for first.

Remember: 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.

Nine System Shapes, and What Each One Is Really About

coreadvanced

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.

Think of it as

For any system, ask what would still be difficult if traffic were tiny. That residue is the actual problem. Payments are hard at ten transactions a day; analytics ingestion is not hard at all until the volume arrives. Knowing which kind you are looking at tells you where to spend the design.

What we're doing: Name the hard part for two systems that look similar and are not.

two-pipelines.txttext

IMAGE PROCESSING — looks like a pipeline, is a cost problem
  Upload → S3 → event → worker → resized images → notify.

  Hard part: the work per object is bounded but the volume is
  not, and the compute choice changes the bill by an order of
  magnitude. Lambda is right for a 2 MB thumbnail and wrong for
  a 200 MB source video, where the 15-minute ceiling and the
  memory limit both bind.

  So the design question is a routing question: size the object
  first, then choose the worker. One pipeline, two compute paths.

PAYMENT WORKFLOW — looks like a pipeline, is a correctness problem
  Request → validate → charge → record → notify.

  Hard part: every step can be retried, the external provider
  can time out ambiguously, and a duplicate is a customer being
  charged twice. Volume is irrelevant — this is exactly as hard
  at ten transactions a day.

  So the design question is an identity question: what makes two
  requests the same request? An idempotency key from the client,
  an atomic record-and-mutate, an append-only ledger, and a
  reconciliation job that compares your ledger with the
  provider's and alarms on any difference.

Same drawing on a whiteboard. Completely different work.

1: Routing by object size is the whole design, and it is invisible if the pipeline is drawn as one path.
12: Reconciliation is the step teams skip: without it, a divergence between your records and the provider's is discovered by a customer.

Why this works: Two systems with the same box diagram can require entirely different work, and the diagram is what people compare. Asking what remains hard at low volume separates them immediately: one needs a routing decision and a cost model, the other needs identity, atomicity and reconciliation. Getting that wrong means spending the design effort in the wrong place.

Recalling a diagram instead of deriving one

Wrong

text

# "A URL shortener is CloudFront, API Gateway, Lambda and
# DynamoDB." (Correct, and it demonstrates nothing.)

Better

text

# "100:1 read to write, 20 GB, sub-50 ms p99, up to a minute of
# staleness allowed → cache at the edge, key-value store behind.
# If staleness were not allowed, this is a different design."

What you see: The design cannot survive a single changed requirement, because nothing in it was derived from a requirement in the first place.

Why: The well-known diagram is the output of a derivation someone else did under assumptions that may not be yours. Reproducing it gets the right answer to a question that was not asked, and it collapses the moment a constraint differs — which in a real system it always does.

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.

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

Together

text

# The test that names the hard part
# "Which of these would still be difficult with 10 users?"

payments        yes  → correctness. Design for it from day one.
multi-tenant    yes  → isolation. Retrofitting is a migration.
real-time       yes  → connection state and semantics.

url shortener   no   → it is a volume problem.
analytics       no   → it is a volume problem.
image pipeline  no   → it is a volume and cost problem.

# The "yes" rows earn design time even in a prototype. The "no"
# rows can be simple until the numbers say otherwise.

Remember: 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.

The Sixteen Dimensions a Design Has to Cover

coreadvanced

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.

Think of it as

Treat the list as a checklist for gaps rather than a template to fill in. Most designs are strong on the first six dimensions and silent on the last four, and the last four are where the expensive surprises live — because they are the ones that only surface after the system is running.

What we're doing: Review a design that looks complete and find what is missing.

review.txttext

The document: 14 pages. Architecture diagram, request flow,
data model, capacity numbers, IAM roles, network layout. It
reads as thorough and it is strong on twelve dimensions.

Four questions expose what is missing.

1. "The order service calls the payment provider. What happens
   when that call takes nine seconds?"
   → Not stated. The timeout is the library default, which is
     none, so a slow provider consumes every request thread and
     the failure is total rather than partial.

2. "What are the top three cost drivers here?"
   → Not stated. The design routes all S3 traffic through a NAT
     gateway; a gateway endpoint would remove that data
     processing charge entirely. That is a design choice, and
     nobody costed it.

3. "What is the RPO and who agreed it?"
   → "We take daily snapshots." That is a backup configuration,
     not an agreement. Nobody has told the business it can lose
     up to 24 hours of orders, and nobody has ever restored one.

4. "Who is on call for this on a Sunday?"
   → "The platform team." Who have not seen this document, do
     not have a runbook, and did not agree to own it.

Twelve dimensions strong, four silent. The four silent ones are
where every expensive surprise in the first year will come from.

1: The document being good is the point — thorough designs are usually thorough about the same twelve things.
10: An unset timeout is the single most common gap here, and it converts a slow dependency into a total outage.
17: Architecture dominates cost, and the NAT-versus-gateway-endpoint choice is the recurring example.
24: Ownership assumed rather than agreed is how a system arrives on a rota nobody expected it to.

Why this works: The dimensions people skip are not random: they are the ones that produce no visible symptom during development. A missing timeout, an uncosted data path, an unagreed RPO and an assumed owner are all invisible until production, which is exactly why the checklist has to be applied deliberately rather than trusted to emerge.

Treating the list as a template to fill in

Wrong

text

# 16 headings, each with a paragraph.
# "Cost: this design is cost-optimised."
# "Failure modes: the system is resilient to failure."

Better

text

# Each dimension answered with something falsifiable:
# "Cost: 60% CloudFront requests, 25% NAT data processing,
#  10% DynamoDB. Adding an S3 gateway endpoint removes ~20%."

What you see: Every section is present and none of them can be wrong, so the review has nothing to examine and approves a design nobody has actually checked.

Why: A dimension is covered when its answer could turn out to be false. "Cost-optimised" cannot be wrong and therefore cannot be reviewed; a breakdown with percentages and a named improvement can be argued with, corrected, and measured against reality later.

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

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"

Together

text

# One dimension, done properly — failure modes for one dependency
DEPENDENCY   payment provider API
TIMEOUT      800 ms connect, 2 s total
RETRIES      2, exponential backoff with jitter, same idempotency key
BREAKER      opens after 20 consecutive failures, half-open at 30 s
DEGRADED     checkout accepts the order and queues the charge;
             the customer sees "payment processing"
ALARM        provider error rate > 5% for 2 minutes → page
OWNER        team-payments

# Eight lines. Compare with "it retries", which is what most
# designs say about their most important external dependency.

Remember: 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.