Design a URL Shortener (TinyURL)

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: What Is a URL Shortener?

You Already Know One: a Forwarding Address

When you move house, you can ask the post office to forward your mail. Letters still go to the old address, and the post office sends them on to the new one. A URL shortener is a forwarding address for web pages. It hands out a short, easy address, and anyone who visits it is sent on to the long one:

textCopy
https://hi.link/aZ9k2Lq
        │
        └──► https://shop.example.com/products/winter-jacket?utm_source=newsletter&utm_medium=email&utm_campaign=winter_sale_2026&utm_content=hero_banner

The part after the slash, aZ9k2Lq, is the short code. The service keeps one record per code: this code forwards to that long URL. When a browser asks for hi.link/aZ9k2Lq, the service answers with a redirect: an HTTP response whose status is in the 3xx range and whose Location header holds the long URL. The browser then goes there on its own.

What Makes It Interesting

Three things make a system this simple worth a whole loop:

• It is almost all reads. People click links far more often than they create them. We'll use 100 clicks per link created. Almost every component we add exists to make the redirect faster or cheaper.
• The code must be short, never reused, and not guessable. Short means few characters. Never reused means two links can never get the same code, not even years apart. Not guessable means nobody can walk through every link we have by trying codes in order.
• A redirect must feel instant. The user clicked to go somewhere else. Every millisecond we add is pure waiting.

The Question the Whole Loop Answers

How do we hand out short codes that never collide, and answer every click in milliseconds, at any scale?

The answer gets sharper every round:

• Round 1: a counter that can't repeat, turned into a 7-character code, and a cache in front of one table.
• Round 2: the same counter scrambled so codes can't be guessed, an edge cache for viral links, click analytics that never slow a redirect, and abuse control.
• Round 3: codes created in every region without talking to each other, custom domains, takedowns everywhere in minutes, and a bill where the CDN is most of the cost.

---

Round 1 · Mid-level · "Short Links for Our Marketing Team"

~35 min · SDE II (L5) · 1 region, 3 AZs · ~1M links/month · ~2K redirects/s peak · 99.9%

R1.1 Establish Design Scope

The interviewer says: "Our marketing team wants short links for their campaigns. Design the service." Before we draw anything, we ask questions, and we say out loud what each answer changes.

Out of scope for this round:

• Custom aliases. They mean codes chosen by users, which can collide with each other and with ours.
• Analytics. Counting clicks sounds free. It isn't, and Round 2 shows why.
• Public sign-up. Only employees create links, so abuse isn't a problem yet.

R1.2 Functional Requirements, Derived Step by Step

We read the request one phrase at a time and turn each phrase into a requirement:

Not yet: custom aliases, click counts, and sign-up for the public. The interviewer may bring these back.

R1.3 Non-Functional Requirements: the Questions

Numbers come in R1.7. For now, the questions and why each matters:

• Redirects must be fast and always up. A broken short link on a printed flyer can't be fixed. If we are down, every campaign is down.
• Codes must never collide. A collision sends one campaign's customers to another campaign's page. That's a silent, embarrassing bug.
• Durability: a link must never be lost. Once a code is printed on 100,000 flyers, its record must outlive any server.
• Codes should be short. Short enough to print and type, which sets a hard limit on how many codes we can have.

R1.4 The API

Create a link (internal; the caller signs in with the company's single sign-on token):

httpCopy
POST /v1/links HTTP/1.1
Host: api.hi.link
Authorization: Bearer <company SSO token>
Content-Type: application/json

{
  "long_url": "https://shop.example.com/products/winter-jacket?utm_source=newsletter&utm_campaign=winter_sale_2026",
  "expires_at": "2026-12-31T23:59:59Z"
}

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json
Location: https://api.hi.link/v1/links/015FTGg

{
  "code": "015FTGg",
  "short_url": "https://hi.link/015FTGg",
  "long_url": "https://shop.example.com/products/winter-jacket?utm_source=newsletter&utm_campaign=winter_sale_2026",
  "created_at": "2026-09-26T12:00:00Z",
  "expires_at": "2026-12-31T23:59:59Z"
}

expires_at is optional. We reject a long_url that isn't http or https, that is longer than 2,048 characters (a limit we choose), or that points back at hi.link itself, which would create a redirect loop.

Follow a link (public, no sign-in):

httpCopy
GET /015FTGg HTTP/1.1
Host: hi.link

httpCopy
HTTP/1.1 302 Found
Location: https://shop.example.com/products/winter-jacket?utm_source=newsletter&utm_campaign=winter_sale_2026
Cache-Control: private, no-store

Which 3xx status to send, and what Cache-Control to send with it, is a real decision with real consequences. Step 1.4 makes it.

Recap

• Two calls: create a link, follow a link.
• About 1 million links a month and 100 clicks per link; peaks of about 2,000 redirects per second on one campaign link.
• Codes: short (7 characters), never reused, generated by us.
• Links never change target; they may expire, and must stop working on time.
• Redirects are the product. They must be fast and always up.

Let's build it, starting with the simplest thing that works.

R1.5 Design Evolution: From a Table Lookup to a Cached Redirect Service

Every step below follows the same pattern: a problem, your turn to think, the answer, and what the answer costs us. The cost is always the next problem.

Step 1.0: The Baseline

One server and one table. The table maps a code to a long URL.

Synthesizing vector architecture diagram...

What's good about it: it works, and it's easy to explain. For a few hundred links, this is the right answer.

What it costs us: everything below. We haven't said how codes are made, one server is a single point of failure, and every click is a database query.

Step 1.1: How Do We Make the Code?

Primitive: Distributed Unique ID Generators

How many codes do 7 characters give us? Each character has 62 choices, so:

$$62^7 = 62 \times 62 \times 62 \times 62 \times 62 \times 62 \times 62 = 3{,}521{,}614{,}606{,}208 \approx 3.52 \text{ trillion codes}$$

How long that lasts depends on how fast we create links. The table shows each length at each round's rate:

The arithmetic for the bold row: at 1M links a month we make $12 \times 10^6$ links a year, and $3.52 \times 10^{12} / 1.2 \times 10^{7} \approx 293{,}468$ years. Six characters would be enough for Round 1. We choose 7 because the company may grow, and because the interviewer told us printed materials already use 7: the table shows 7 still lasts nearly 300 years at a thousand times our traffic.

Encoding one number by hand. Base62 works exactly like writing a number in base 10, just with 62 digits:

textCopy
digit value:  0-9 → '0'-'9'    10-35 → 'a'-'z'    36-61 → 'A'-'Z'

To encode, divide by 62 again and again; each remainder is one digit, read from last to first. Take counter value 1,000,000,000:

Reading the digits from step 6 back to step 1 gives 15FTGg, six characters. We pad on the left with the zero digit to reach 7: 015FTGg. Check it by multiplying back: $1 \times 62^5 + 5 \times 62^4 + 41 \times 62^3 + 55 \times 62^2 + 42 \times 62 + 16 = 916{,}132{,}832 + 73{,}881{,}680 + 9{,}771{,}448 + 211{,}420 + 2{,}604 + 16 = 1{,}000{,}000{,}000$.

The same thing as pseudocode:

textCopy
ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

encode(n):                      # requires 0 ≤ n < 62^7
    code = ""
    repeat 7 times:
        code = ALPHABET[n mod 62] + code
        n = n div 62            # whole-number division
    return code                 # always exactly 7 characters

Running the loop exactly 7 times does the padding for us: once n reaches 0, each remaining step adds a 0.

Step 1.2: Several App Servers Need Counter Values Without Clashing

The counter row, and the lease as a DynamoDB UpdateItem request:

jsonCopy
{
  "TableName": "counters",
  "Key": { "name": { "S": "links" } },
  "UpdateExpression": "ADD next_id :block",
  "ExpressionAttributeValues": { ":block": { "N": "1000" } },
  "ReturnValues": "UPDATED_NEW"
}

DynamoDB answers with the new next_id; the server's block is [next_id − 1000, next_id − 1]. No condition is needed: ADD on a number is applied atomically, one request after another.

How often does this happen? At our average of 0.39 links a second, all servers together lease a block about every $1{,}000 / 0.39 \approx 2{,}600$ seconds, roughly every 43 minutes. The counter row is almost idle.

Step 1.3: Redirects Hit the Database Every Time

How big is the cache? A campaign's clicks mostly happen within weeks of sending. So we plan for the links created in the last 30 days (1 million) plus as many older links still being clicked, about 2 million entries:

$$2{,}000{,}000 \times 600 \text{ B} = 1.2 \text{ GB}$$

600 bytes per record is our estimate: the long URL averages about 500 bytes (marketing URLs carry long tracking parameters), plus the code, times and bookkeeping. With the cache's own per-key overhead, this fits comfortably on the smallest production node type we'd use, a cache.t4g.medium with 3.09 GiB.

At Round 1's scale, be honest in the interview: the table alone could serve our average load, and the cache costs more per month than the table reads it saves (R1.7). We add it for the hot link and for the latency of every click. In Round 2 it becomes essential.

Primitive: Distributed Cache Patterns & Eviction

Step 1.4: 301 or 302?

Step 1.5: An Expired Link Still Redirects

textCopy
redirect(code):
    record = cache.get(code)
    if record is missing:
        record = table.get(code)                 # eventually consistent read
        if record is missing: return 404
        cache.put_if_absent(code, record,                  # SET ... NX EX: never replaces a newer entry
                            lifetime = min(1 day, record.expires_at − now))
    if record.status ≠ active:
        return 410                               # disabled by an admin
    if record.expires_at is set and now ≥ record.expires_at:
        return 410
    return 302 with Location = record.long_url

A refill only writes the cache if the key is empty (SET ... NX), and disabling a link overwrites the cache entry with the disabled record instead of deleting it. That closes a race: a redirect that read the table just before an admin disabled the link can't put the old "active" record back, because the key is no longer empty.

Step 1.6: The Table Needs to Scale

The links table

The GSI by_owner has partition key owner_id, sort key created_at, and projects only code and long_url, so it stays small.

Primitive: Database Sharding & Partition Keys

Round 1 Step Summary

Sequential codes, from step 1.1, are the first thing Round 2 must fix.

R1.6 Architecture v1

Now the concepts get AWS names.

Synthesizing vector architecture diagram...

Follow a click from the top: the load balancer picks an app server, which asks the cache first (1) and the links table only on a miss (2). The dotted arrows are off the click path: servers lease counter blocks rarely, and only when creating links.

The pieces:

• Application Load Balancer (ALB): terminates HTTPS and spreads requests over the app servers in three AZs. It checks each server's health and stops sending to a failed one.
• App servers: three EC2 instances in an Auto Scaling group, one per AZ, each a c7g.medium (1 vCPU). The same process serves both POST /v1/links and GET /{code}, and keeps its current counter block in memory.
• Cache: ElastiCache for Valkey, one primary and one replica in different AZs, with automatic failover.
• Tables: DynamoDB links and counters, on-demand capacity (pay per request, no capacity to plan).

Trace 1: creating a link.

Synthesizing vector architecture diagram...

Most creates never touch the counter table: the number comes from memory. The only write on the normal path is the new link. Check the encoding: $14 \times 62^2 + 51 \times 62 + 22 = 53{,}816 + 3{,}162 + 22 = 57{,}000$, and 14, 51, 22 are e, P, m. The next link gets 0000ePn, which is exactly the guessability problem Round 2 fixes.

Trace 2: a redirect, cache hit and cache miss.

Synthesizing vector architecture diagram...

A hit costs one sub-millisecond cache read. A miss adds one table read and one cache write, and only the first click on a link in a day pays it.

R1.7 Numbers

Traffic. We use a 30-day month, 2,592,000 seconds.

Storage.

$$12{,}000{,}000 \text{ links/year} \times 600 \text{ B} = 7.2 \text{ GB per year}$$

DynamoDB already stores three copies across three AZs, and its storage price includes them, so we don't multiply by 3.

Cache: about 2 million entries × 600 B ≈ 1.2 GB (step 1.3), on a 3.09 GiB node.

Code space: 3.52 trillion 7-character codes last about 293,000 years at this rate (step 1.1).

App servers. We plan on 2,000 redirects per second per c7g.medium, an assumption we confirm with a load test. Three servers give 6,000/s; after losing an AZ, two give 4,000/s against a 2,000/s peak.

Availability budget. 99.9% of a 30-day month (43,200 minutes) allows 43.2 minutes of downtime.

Latency. A cache hit is one sub-millisecond read inside the region; a miss adds a DynamoDB read, typically a few milliseconds. The P99 target of 50 ms leaves room for the ALB and TLS.

Monthly cost (us-east-1, on-demand, 730 hours a month):

An eventually consistent read of an item up to 4 KB costs half a read unit; that's where the 0.5 comes from. Say it plainly: the table costs about $4 a month; the cache costs $76. We keep the cache for the hot campaign link and for latency, not to save money.

R1.8 Trade-Offs

How to make codes

Redirect status

DynamoDB vs PostgreSQL at this size. Either works. PostgreSQL gives SQL, joins for ad-hoc questions and a unique index on code; we'd run RDS or Aurora with a standby in another AZ. DynamoDB gives single-digit-millisecond key lookups, no servers or failovers to manage, and growth to Round 2 without resharding. We choose DynamoDB for the growth path, not because PostgreSQL would fail here.

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Asks for the read-to-write ratio and the traffic shape, and says the ratio means "optimize the read path".
• Does the code-length math: $62^7 \approx 3.52$ trillion, and how many years that lasts.
• Rejects hash truncation with the birthday bound, not just "it might collide".
• Makes codes from a counter, and shares it with leased blocks.
• Chooses 302 over 301, and explains the browser cache.
• Checks expiry on read and knows TTL deletion is lazy.

Follow-up questions

1. "Why Base62 and not Base64?" Answer: standard Base64 uses + and /, which mean something in URLs. But there's a URL-safe Base64 variant (RFC 4648 calls it "base64url") that uses - and _ instead, so "Base64 isn't URL-safe" isn't the real reason. The real reasons are practical. Codes are read aloud, typed from paper and selected with a double-click, and in many text fields a double-click stops at -, and an underline hides _. And the gain is small: $64^7 / 62^7 = (64/62)^7 \approx 1.25$, only 25% more codes at the same length. Some services do use base64url alphabets (YouTube's video IDs contain - and _), so either is defensible. If people will type codes, consider going further and dropping look-alike characters (0/O, 1/l/I), as Base58 does.

2. "Two people shorten the same URL. Do they get the same code?" Answer: no. Each create takes a new counter value, so they get two codes. That's what we want here: two campaigns pointing at the same page want separate expiry dates, and in Round 2, separate click counts. If a user wants "give me my existing link for this URL", we can add an index on (owner, hash of the long URL) and look it up first, per owner, never across owners.

3. "How long do 7 characters last?" Answer: $62^7 = 3{,}521{,}614{,}606{,}208$ codes. At 1 million links a month, about 293,000 years; at 100 million a month, about 2,900 years; at a billion a month, about 293 years. Length is not what forces a change. Round 3 shows that guessability is.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "A Public Shortener With Analytics"

~40 min · Senior SDE (L6) · 1 region, 3 AZs + CloudFront edge · 100M links/month · ~12K redirects/s peak, viral bursts of 50K/s · 99.99% · redirect P99 < 10 ms

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "We built an internal shortener for the marketing team: about a million links a month, 100 clicks per link, so about 40 redirects a second on average and 2,000 at a campaign's peak, in one region across three AZs at 99.9%. Codes come from a counter written in Base62 with 7 characters, which gives $62^7 \approx 3.52$ trillion codes, nearly 300,000 years at that rate. The counter must stay below $62^7$, about 41.7 bits, which is why we don't use 64-bit IDs. App servers lease blocks of 1,000 counter values with one atomic ADD on a DynamoDB row, so the counter is almost idle and a crash only leaves a gap. Links live in a DynamoDB table keyed by code, with an index by owner. Redirects read ElastiCache first, then the table. We answer 302 with no-store, never 301, so expiry and disabling work on the next click, and we check expires_at on every read because DynamoDB's TTL deletes lazily. About $195 a month. Open costs: codes are sequential and guessable, there are no analytics or custom aliases, there's no edge, and nothing stops abuse."

Architecture v1, compact

textCopy
 browsers ──► ALB ──► 3 app servers (one per AZ): create + redirect
                          │ 1. ElastiCache (Valkey): link:{code} → {long_url, expires_at}
                          │ 2. on miss: DynamoDB links (key = code; GSI by owner)
                          │ check expires_at on every read → 302 (no-store) or 410
                          └── rarely: DynamoDB counters, ADD next_id 1000 → a block of codes

Round 1 step summary

Open costs: guessable codes; no analytics; no custom aliases; one region and no edge; no abuse control.

R2.1 The Scope Raise

Interviewer: "Marketing loved it. Now we're turning it into a public product, like Bitly. Anyone on the internet can create links, 100 million a month. Business customers want click counts, top referrers and countries for each link. They also want custom aliases like hi.link/summit-2026. Last month a celebrity posted one of our links and it got 50,000 clicks a second for twenty minutes. Attackers have started using shorteners to hide phishing pages. We need redirects under 10 ms at P99, and 99.99% availability."

A scope raise is not the end of scoping. Before we fix anything, we ask back, and we say what each answer changes, just as in R1.1.

Scope change

The "Not yet" list from R1.2 is now mandatory: custom aliases, click counts and public sign-up. The public sign-up changes the design most, because it makes guessable codes and abuse into real problems.

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

Create, with an optional alias (API key required for aliases and bulk):

httpCopy
POST /v1/links HTTP/1.1
Host: api.hi.link
Authorization: Bearer hk_live_8f2a...
Content-Type: application/json

{
  "long_url": "https://events.example.com/summit/2026/register",
  "alias": "summit-2026",
  "expires_at": "2026-11-30T00:00:00Z"
}

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{
  "code": "summit-2026",
  "short_url": "https://hi.link/summit-2026",
  "safety_status": "pending",
  "created_at": "2026-09-26T12:00:00Z",
  "expires_at": "2026-11-30T00:00:00Z"
}

Stats for one link (owner's API key only):

httpCopy
GET /v1/links/summit-2026/stats?window=7d HTTP/1.1
Host: api.hi.link
Authorization: Bearer hk_live_8f2a...

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json

{
  "code": "summit-2026",
  "window": "7d",
  "total_clicks": 14290,
  "top_referrers": [ { "host": "t.co", "clicks": 6120 }, { "host": "news.ycombinator.com", "clicks": 2210 } ],
  "top_countries": [ { "country": "US", "clicks": 8010 }, { "country": "DE", "clicks": 1330 } ],
  "updated_at": "2026-09-26T12:01:00Z"
}

updated_at tells the caller how fresh the numbers are: we promise within about two minutes (step 2.2).

API keys and quotas. Every business customer gets API keys. A key is sent as a bearer token; we store only a hash of it. Each key has a creation quota (for example 100 links a minute on the free plan, more on paid plans), and anonymous creation through the web form is limited per IP and protected by a bot challenge.

The analytics data model: raw events, then pre-aggregated windows. Two stores, for two different questions:

Parquet is a columnar file format: values of one column are stored together, which compresses well and lets a query read only the columns it needs. Athena runs SQL directly over files in S3 and charges by the data scanned.

R2.4 Design Evolution: Viral Links, Analytics, Enumeration and Abuse

Step 2.1: A Viral Link's Cache Entry Expired, and 50K Requests Hit the Table at Once

Synthesizing vector architecture diagram...

The spike is spread over hundreds of edge caches, each of which asks us about once a day. The origin sees a handful of requests for the viral code, not 50,000 a second.

Primitive: Distributed Cache Patterns & Eviction · Drill: Caching a hot product page

Step 2.2: Counting Clicks Costs More Than Serving Them

Why the aggregator writes the Parquet files, not Amazon Data Firehose. Firehose is the usual no-code way to land a stream in S3 as Parquet, and it would work with a Lambda transform to JSON: its Parquet conversion accepts only JSON input, and CloudFront's real-time log records aren't JSON. And Firehose bills a stream record by its size rounded up to the nearest 5 KB. Our records are about 500 bytes, so we'd pay for ten times the data: at 10 billion clicks a month, about 51 TB billed instead of 5 TB. Since the Flink job already reads every record, it writes the files itself. If producers batched events into records near 5 KB, Firehose would be the simpler choice.

Primitive: Message Queues vs Event Streams

Step 2.3: Anyone Can Walk Through Every Link

The permutation, as pseudocode

textCopy
DOMAIN = 62^7                          # 3,521,614,606,208 codes

feistel(x):                            # a keyed permutation of 0 … 2^42 − 1
    L = x div 2^21 ; R = x mod 2^21    # two 21-bit halves
    for round in 0, 1, 2, 3:
        f = first 21 bits of HMAC-SHA256(SECRET_KEY, round, R)
        L, R = R, L XOR f
    return L × 2^21 + R

scramble(counter):                     # counter < DOMAIN
    y = feistel(counter)
    while y ≥ DOMAIN:                  # cycle walking
        y = feistel(y)
    return y                           # also < DOMAIN, and unique per counter

code = encode(scramble(counter))       # encode() from step 1.1

A worked example, with toy numbers you can check by hand. Real halves are 21 bits; here they're 4 bits, so numbers run 0 to 255, and our pretend code space is 0 to 199 (78% of 256, close to the real 80%). Three rounds, with round function $f_i(R) = (5R + k_i) \bmod 16$ and round keys $k = 3, 7, 11$.

Counter value 50 is L = 3, R = 2 (because $50 = 3 \times 16 + 2$):

The result is $15 \times 16 + 8 = 248$. That's above 199, not a valid code, so we walk: permute 248 (L = 15, R = 8):

Result $3 \times 16 + 14 = 62$, which fits. So counter 50 becomes 62, and its neighbour 51 becomes something unrelated. Running all 200 inputs through this toy gives 200 different outputs, all below 200: a permutation, as promised. (The toy's round function is far too weak for real use; the real one is a keyed hash.)

Go deeper: NIST standardizes a format-preserving encryption mode, FF1 (SP 800-38G), built from the same Feistel idea over any radix, including base 62. It's the "use a reviewed construction" answer if the interviewer pushes on the strength of a home-made Feistel network. Either way, treat the permutation as protection against enumeration, not as encryption of anything secret.

Step 2.4: Our Domain Got Blocklisted for Phishing

Primitive: Distributed Rate Limiting · Bot Defense & Registration Abuse · Drill: Rate limiting a partner API · Loop: Design a Distributed Rate Limiter

Step 2.5: Custom Aliases Collide, and Bulk Imports Throttle the Table

The alias claim:

jsonCopy
{
  "TableName": "links",
  "Item": {
    "code":          { "S": "summit-2026" },
    "long_url":      { "S": "https://events.example.com/summit/2026/register" },
    "owner_id":      { "S": "cust_7731" },
    "owner_shard":   { "S": "cust_7731#9" },
    "kind":          { "S": "alias" },
    "safety_status": { "S": "pending" },
    "created_at":    { "N": "1790424000" },
    "expires_at":    { "N": "1795996800" }
  },
  "ConditionExpression": "attribute_not_exists(code)"
}

Primitive: Database Sharding & Partition Keys · Drill: Sharding tenant hotspot

Step 2.6: Random Codes That Don't Exist Are Hammering the Table

Primitive: Bloom Filters & Counting Filters

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Two independent paths. The click path runs top to bottom on the left: edge first, origin only on a miss, and nothing on it waits for analytics or scanning. Clicks are counted from the edge's log on the right, so the redirect never writes anything.

Trace 1: a viral redirect at the edge.

Synthesizing vector architecture diagram...

Trace 2: a create, then the scan.

Synthesizing vector architecture diagram...

Trace 3: a stats read. GET /v1/links/summit-2026/stats?window=7d → the app checks that the API key owns the link → one Query on click_stats with code = summit-2026 and sort key between HOUR#2026-09-19T12 and HOUR#2026-09-26T12 → 168 rows of a few hundred bytes → the app sums clicks and merges the referrer and country maps → 200. The raw lake is never touched.

Cache key patterns (ElastiCache)

Analytics schemas

We store the referrer's host and a device class, not full referrer URLs or raw IP addresses: the stats never need them, and not storing them is the easiest privacy decision we'll make.

R2.6 Numbers and Cost

Traffic (30-day month = 2,592,000 s)

The 12K/s is the everyday peak. A viral link's 50K/s comes on top of it, for minutes, on one code, and the edge absorbs it.

Counter. At 38.6 creates a second and blocks of 1,000, all servers together lease a block every 26 seconds: about 0.04 writes a second on the counter row.

Storage

$$12 \text{ billion links} \times 600 \text{ B} = 7.2 \text{ TB after 10 years} \qquad (1.2 \text{ billion} \times 600 \text{ B} = 720 \text{ GB after year 1})$$

DynamoDB keeps three copies across AZs inside that price; we don't bill 21.6 TB.

Cache (hot set). An upper bound: assume at most 20% of a day's clicks are to distinct codes (the rest are repeats of popular links). Then:

$$333\text{M} \times 0.20 \approx 67\text{M codes} \times 600 \text{ B} \approx 40 \text{ GB}$$

ElastiCache recommends keeping about a quarter of each node's memory free for its own work, so we need about $40 / 0.75 \approx 53$ GB of node memory: 3 shards of cache.r7g.xlarge (26.32 GiB each, 79 GiB in total), each with one replica in another AZ.

Edge hit ratio and origin load. How often a click finds its link already cached at its edge location depends on how clicks spread over links and locations, which we can't derive; we assume 70% and measure it from the real-time logs (x-edge-result-type).

App servers. We plan on 5,000 redirects a second per c7g.large (an assumption to load-test) and size the fleet for the whole 12K peak, in case the CDN serves nothing (a bad cache policy deploy, say): 2 per AZ, 6 in total. After losing an AZ, 4 × 5,000 = 20,000/s.

Kinesis shards. One real-time log record per click, about 500 bytes. A shard takes 1,000 records a second, so records, not bytes, set the count: 12K/s everyday peak plus a 50K/s viral burst is 62K/s, so 64 shards. We provision shards rather than use on-demand mode, because an on-demand stream only absorbs up to double its previous peak instantly, and a viral burst is four times ours.

Availability. 99.99% of a 30-day month is 4.3 minutes. The edge helps here too: during a short origin outage, CloudFront keeps serving cached links, and for expired entries stale-if-error could extend that if we chose to add it.

Monthly cost (us-east-1; CloudFront at United States prices)

Three things to say about this bill:

• The CDN is about 70% of it, almost all of it the per-request fee. CloudFront bills every viewer request, hit or miss. We're paying for speed near users and for absorbing viral spikes, not to save origin cost: serving the same 10 billion requests from the ALB would cost far less in fees. Say that trade-off out loud.
• The cache costs 80 times the table reads it saves ($1,530 against $19 of reads). It's there for the 10 ms P99 and for hot keys, not for money.
• click_stats uses provisioned capacity because its writes are steady; on-demand would be about $0.625 per million writes, roughly 2.8 times the provisioned cost for this flat load.

R2.7 Trade-Offs

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a senior (L6) answer adds over L5

• Sees that the everyday peak and the viral spike are different problems, and solves the viral one at the edge instead of with a bigger database.
• Knows the per-partition limits (1,000 writes, 3,000 reads a second) and uses them to explain why a counter per click, a hot item or a single-owner index fails.
• Moves counting off the read path and knows the edge hides clicks from the origin.
• Keeps "unique by construction" and adds unguessability with a permutation, and can explain why a Feistel network plus cycle walking is still one-to-one.
• Treats abuse as a design requirement: async scans, a fail-closed status, creation limits, 403 vs 451.
• Finds the subtle races: two alias claims, and a negative-cache entry that hides a brand-new link.
• Prices the design and can say which line dominates and why it's worth it.

Follow-up questions

1. "Why not let browsers cache the redirect for a minute? It would cut our CloudFront bill." Answer: it would cut requests from returning visitors, but we'd lose control over those browsers: a link blocked for phishing would keep working in every browser that cached it, for a minute or however long it chose to keep it, and we'd never see those clicks. Browser caches can't be invalidated. The edge cache can.

2. "Your permutation key leaks. What now?" Answer: an attacker can compute the code for any counter value, so they can walk every link again. We can't change existing codes; they're printed. We stop issuing 7-character codes under that key and move new links to a new key and a new code length (8 characters, Round 3), so new codes can't collide with old ones. For existing links, we lean on the limits: 404 and request-rate limits per IP, and moving customers' sensitive links to long random tokens.

3. "A customer wants to change where their link points. Round 1 said targets never change." Answer: we can offer it for business customers, but every copy must be updated: the table (a conditional update by the owner), the cache (delete the key), and the edge (an invalidation, or wait out the edge TTL). The cost of edits is exactly the cost of revocations, which is why they come together in Round 3's edge TTL decision.

Interview gotchas from this round

---

Round 3 · Architect · "Global, Custom Domains, Takedowns in Minutes"

~45 min · Principal (L7) · 3 regions active-active + edge · ~1B links/month · ~200K redirects/s peak · 99.999% for redirects · takedown within 5 minutes worldwide

R3.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 3. If you're starting here, it's everything you need from Rounds 1 and 2.

Round 2 in 60 seconds. "We run a public shortener in us-east-1: 100 million links a month, about 3,860 redirects a second on average and 12,000 at peak, plus viral bursts of 50,000 a second on one link, at 99.99%. Codes come from a counter leased in blocks of 1,000, scrambled by a keyed Feistel permutation over 42 bits with cycle walking into $62^7$, then written as 7 Base62 characters: unique by construction and not walkable. CloudFront caches 302s for a day (s-maxage=86400, stale-while-revalidate=3600) while browsers get no-store, and the origin uses a cache with single-flight in front of DynamoDB. Clicks are counted from CloudFront real-time logs through Kinesis and Flink into hour rows, with raw Parquet in S3. Links start pending and are scanned asynchronously; blocked links get a 403 and an invalidation. Every create is a conditional write; aliases are never reassigned; bulk imports are queued. A negative cache stops probes, and a create overrides it. About $16,100 a month, about 70% of it CloudFront. Open costs: one region for writes and for the counter; aliases arbitrated by one table; edge copies that live a day; one domain."

Architecture v2, compact

textCopy
 browsers ──► CloudFront (302s cached 1 day; real-time logs) ──misses──► ALB ──► 6 app servers (us-east-1)
                                                                              │ ElastiCache: link:, neg:
                                                                              │ DynamoDB links (conditional writes), counters
 API ──► WAF + ALB ──► create: counter block → Feistel → Base62 → PutItem if not exists → SQS scan
 edge logs ──► Kinesis (64 shards) ──► Flink ──► click_stats hour rows + S3 Parquet ──► Athena

Steps so far

Open costs: one region; aliases and the counter live in one region's tables; a blocked link can live a day at the edge unless invalidated; only hi.link.

R3.1 The Scope Raise

Interviewer: "We're global now. Users on every continent click and create links, and both must be fast everywhere. About a billion new links a month, and 200,000 redirects a second at peak. Enterprise customers want links on their own domains, like go.acme.com/summit. When we get a court order or a confirmed phishing report, the link must stop working worldwide within five minutes. Enterprises want unique visitors per link, not just clicks. When a customer leaves, their links and click data must be deleted. And we must survive losing a whole region."

Again, we ask back before we design:

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

Custom domain onboarding

httpCopy
POST /v1/domains HTTP/1.1
Host: api.hi.link
Authorization: Bearer hk_live_ent_...
Content-Type: application/json

{ "domain": "go.acme.com" }

httpCopy
HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "domain": "go.acme.com",
  "status": "pending_dns",
  "dns_instructions": { "type": "CNAME", "name": "go.acme.com", "value": "d1a2b3c4example.cloudfront.net" },
  "certificate": "pending_validation"
}

GET /v1/domains/go.acme.com reports pending_dns → pending_validation → active. Links on a custom domain are created with "domain": "go.acme.com" in POST /v1/links, and every link is now identified by domain plus code: go.acme.com/summit and hi.link/summit are different links.

Takedown

httpCopy
POST /v1/links/hi.link/aZ9k2Lq:takedown HTTP/1.1
Host: api.hi.link
Authorization: Bearer <trust-and-safety staff token>
Content-Type: application/json

{ "reason": "legal_order", "reference": "case-2026-0917-114" }

httpCopy
HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "takedown_id": "td_01J8Z6K3",
  "status": "propagating",
  "accepted_at": "2026-09-26T12:00:00Z",
  "deadline": "2026-09-26T12:05:00Z"
}

GET /v1/takedowns/td_01J8Z6K3 shows each region's cache update, the edge invalidation, and the result of verification probes, ending in verified. reason is legal_order (the link then answers 451) or phishing (it answers 403).

Stats with unique visitors (enterprise links): the Round 2 response gains "unique_visitors_approx": 11804 and "unique_visitors_error": "±1.6% (95%)".

Customer data deletion

httpCopy
DELETE /v1/tenants/ten_acme HTTP/1.1
Host: api.hi.link
Authorization: Bearer <account owner token, confirmed>

202 Accepted with a job ID; the job's status lists each store and when it was cleared (step 3.6).

R3.4 Design Evolution: Global Reads, Global Writes and Fast Takedowns

Step 3.1: Creates Happen in Every Region, and Codes Must Still Never Collide

The far-region miss. Because the code comes from a counter slice, any region can tell which region made a code, without asking anyone:

textCopy
home_region(code):                       # generated codes only
    n = decode_base62(code)
    counter = unscramble(n)              # the Feistel rounds run backwards; cycle-walk backwards until < 62^7
    slice = counter div 440,201,825,776
    return REGION_OF_SLICE[slice]        # e.g. slice 2 → ap-northeast-1

redirect on a local miss (cache and local replica both empty):
    if code is alias-shaped (contains "-", or length is not 7 or 8):
        claim = strongly consistent GetItem(code) from alias_claims   # MRSC, step 3.2
        if claim is missing: return 404
        record = GetItem(code) from the claim's home region's replica
        return 302 if found, else 404
    home = home_region(code)
    if home == this region: return 404
    if counter > published_high_water_mark[home] + 1,000,000: return 404   # never issued yet
    record = GetItem(code) from the home region's replica        # one cross-region read
    return 302 if found, else 404

Each region writes its counter's high-water mark (the end of its last leased block) into a small item in the global table once a minute; only that region ever writes it, so last-writer-wins can't lose anything. A published mark lags the real counter: at us-east-1's average of about 154 creates a second (40% of 386), a block of 1,000 lasts about 6.5 seconds, so a minute-old mark can be about 9 blocks behind, and about 46 behind at a 5× peak. Comparing against the bare mark would 404 exactly the new links the fallback exists for, so we compare against the mark plus a margin of 1,000,000, which covers over 20 minutes even at us-east-1's peak (about 770 creates a second). A random probe still almost always decodes to a counter far above every mark plus margin, because each slice has 440 billion values and a region issues about 5 billion a year. Alias-shaped codes never go through this path: they're looked up in the strongly consistent alias_claims table (step 3.2), which records each alias's home region. So probes still stop at the local region, and only genuinely new links pay the cross-region read.

Primitive: Distributed Unique ID Generators · Cloud Disaster Recovery & Multi-Region Active-Active · Loop: Design a Distributed Unique ID Generator

Step 3.2: Two Regions Accepted the Same Custom Alias

The same last-writer-wins rule applies to every later update of a link row. If a trust-and-safety update in Paris and a target edit in Virginia hit the same item in the same second, one whole item version wins, and the other change is lost. So we keep mutable facts out of the shared row: link records are written once (plus the owner's rare edits, which go to the link's home region from step 3.1), and takedowns are separate items in a separate takedowns global table, keyed by domain/code. A takedown item is only ever inserted, never updated, so there's nothing for last-writer-wins to lose.

Drill: Multi-region replication consistency

Step 3.3: A Takedown Must Be Global in 5 Minutes, but the Edge Caches for a Day

How each response is cached at the edge

Drill: CDN edge image delivery · Primitive: Change Data Capture & Outbox

Step 3.4: Thousands of Customer Domains Need HTTPS

Step 3.5: Unique Visitors per Link, Over Billions of Clicks

Primitive: Bloom Filters & Counting Filters (the same family of probabilistic sketches)

Step 3.6: A Customer Leaves, and Their Data Must Go

Round 3 Step Summary

R3.5 Global Architecture

Synthesizing vector architecture diagram...

Each region is complete for redirects and generated creates: its own app servers, cache, counter slice and table replicas. Only three things cross regions: table replication (asynchronous), alias claims (synchronous, rare), and the edge log, which CloudFront delivers to one analytics stream.

The analytics pipeline is central, not per region. Clicks are recorded by CloudFront, which is global, and a real-time log configuration names the stream it delivers to. So the edge log arrives in one place, us-east-1, where Flink, click_stats and the lake live. Stats are allowed to be minutes stale and are not part of the 99.999% promise. If us-east-1 is down, stats stop updating; as a backfill source we also enable CloudFront standard access logs to an S3 bucket in eu-west-1.

Trace 1: a link created in Tokyo, clicked in Paris a moment later.

Synthesizing vector architecture diagram...

The code Qx81bTe is illustrative; what matters is that any region can run the permutation backwards and find the slice, and so the home region, without asking anyone.

Trace 2: a takedown. 12:00:00 the takedown API in eu-west-1 inserts takedowns: hi.link/aZ9k2Lq → 12:00:00.8 the item is in us-east-1 and ap-northeast-1 → each region's stream Lambda overwrites link:aZ9k2Lq with "taken down (451)" by 12:00:03 → the court order triggers create-invalidation for /aZ9k2Lq → probes in three regions get 451 through CloudFront → verified at, say, 12:01:10. Had the invalidation failed, the last edge copy would still have expired by 12:03:03 (180 s after the regional overwrites at 12:00:03).

Trace 3: us-east-1 fails. Route 53 health checks on origin.hi.link fail for us-east-1 within a minute or two, and CloudFront's origin requests go to eu-west-1 and ap-northeast-1. Edge copies keep serving meanwhile. Redirects for any link replicated before the failure keep working. Links created in us-east-1 in its last second or so before failing may not have replicated; they 404 elsewhere until the region returns (the RPO the interviewer accepted). API creates are routed to the surviving regions, which use their own counter slices, so nothing collides. Alias claims keep working: MRSC needs two of its three regions. When us-east-1 returns, its replica catches up, and its counter resumes from its own durable row, never behind any block it leased.

R3.6 Numbers and Cost

Traffic

Per region (a planning split of the peak: 40% Americas, 35% Europe, 25% Asia)

Edge hit ratio against TTL (assumed, to be measured by replaying real-time logs against each TTL before we switch):

App servers per region. Still planning 5,000 requests a second per c7g.large. We run 15 per region, 5 per AZ (75K/s capacity):

• AZ loss in the busiest region: $10 \times 5{,}000 = 50{,}000 \ge 40{,}000$ (80% busy).
• Region loss: if us-east-1 fails and Route 53 sends about 25K/s of its origin traffic to eu-west-1 and 15K/s to ap-northeast-1, eu-west-1 carries $35 + 25 = 60$K/s on 75K (80% busy), ap-northeast-1 carries $25 + 15 = 40$K/s. Auto Scaling adds instances within minutes if it lasts.

Caches. In Round 2 the cache held the whole hot set. At this scale, that would be about $3.33\text{B} \times 20\% \times 600 \text{ B} \approx 400$ GB per region. But a cache miss here costs two eventually consistent item reads (the link and its takedown item), $0.125 per million misses: the cache is worth it for latency and hot keys, not for everything. We run a smaller cache as a shield: 2 shards of cache.r7g.2xlarge plus replicas per region (about 80 GB usable), and assume an 80% hit ratio at the origin.

DynamoDB reads: origin average $38{,}580 \times 50\% \approx 19{,}300$/s; 20% miss the cache ≈ 3,860/s; each miss reads the link and its takedown item (2 items × 0.5 unit):

$3{,}860 \times 2{,}592{,}000 \approx 10\text{B misses} \times 2 \times 0.5 = 10\text{B read units} \times \$0.125/\text{M} \approx \$1{,}250/\text{month}$

Replication. Each link is written in its home region and replicated to two others: $1\text{B} \times 600 \text{ B} \times 2 = 1.2$ TB a month of cross-region transfer.

The code space with region slices. Each slice holds 440.2 billion counter values:

Length doesn't force 8 characters for a century. Guessability does, much sooner. After $N$ years at 12 billion links a year, a random 7-character guess hits a real link with probability $12N \times 10^9 / 3.52 \times 10^{12}$: 0.34% after one year, 1% after about three. We decide in advance: when the issued share passes 1%, new links get 8-character codes ($62^8 \approx 2.18 \times 10^{14}$, where even 120 billion links are 0.055% of the space), under a new permutation key over 48 bits ($62^8 / 2^{48} \approx 0.78$, so about 1.3 passes of cycle walking on average), with the same 8-slice split. Old 7-character codes stay valid forever; the length tells the two apart, so the change needs no flag day.

Analytics. 3.33B clicks a day; at ~50 bytes per click in Parquet, about 167 GB a day, 5 TB a month, about 65 TB with 13 months kept. Kinesis needs one shard per 1,000 records a second: 200K/s peak plus a 50K/s viral burst, so 256 shards. HLL: we assume about 10% of the ~667M codes clicked each day belong to enterprise customers, ~67M daily sketches, each written once, over the hour after the day closes, into the on-demand visitor_sketches table; most are sparse and under 1 KB.

Monthly cost (CloudFront at each geography's own rates; everything else at us-east-1 rates, and the other regions cost somewhat more)

The CDN is nearly three quarters of the bill (≈ $120,000 of ≈ $163,000), and nearly all of that is the request fee, which the edge TTL doesn't change. The architect's lever is not the TTL; it's the price per request (committed-use pricing, which AWS negotiates at this volume) and the question of whether every redirect needs a CDN at all (R3.7).

R3.7 Trade-Offs

The opening question was: how do we hand out short codes that never collide, and answer every click in milliseconds, at any scale? The answer is now: codes are a counter, never a guess (sliced by region, scrambled by a permutation, so collisions are impossible by construction and codes can't be walked), and clicks are answered from the closest copy (edge, then regional cache, then local replica), with every copy given a lifetime short enough that revocation is a proof, not a hope.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals OPS 8 · REL 6

Takedown procedure (legal order) SEC 10

1. Record the order in the takedown API with its reference; the API writes the insert-only takedown item.
2. Invalidate the path on the right distribution or distribution tenant.
3. Watch the takedown status: three regional overwrites, the invalidation, three probes.
4. Verify the audit record shows verified within 5 minutes, and attach it to the case.
5. If a probe still sees a redirect after 4 minutes, page the on-call and re-send steps 2 and 3; the 180 s edge bound means a stale edge copy is not the cause, so look at the regional caches.

Phishing-wave playbook OPS 10

1. Contain creation: lower anonymous per-IP limits, require the bot challenge on every form submission, and pause the API keys that created the flagged links.
2. Hold new links: switch anonymous links from "interstitial while pending" to "blocked while pending" until the queue drains.
3. Scale scanning: raise scanner concurrency within the reputation service's quota.
4. Invalidate only what's being clicked: takedowns of links with clicks in the current hour; the 60 s TTL handles the rest.
5. Tell the blocklists: report our own takedowns to the safe-browsing providers that flagged us, so hi.link itself isn't listed.
6. Learn: a Correction of Error (COE) with the creation path the attacker used and the limit that should have caught it.

Go deeper: CLI lines

Plain commands an on-call engineer runs, one at a time. Replace the IDs with real ones.

textCopy
# 1. Insert a takedown record (insert-only; fails if one already exists)
aws dynamodb put-item --region eu-west-1 --table-name takedowns --item '{"link_key": {"S": "hi.link/aZ9k2Lq"}, "reason": {"S": "legal_order"}, "reference": {"S": "case-2026-0917-114"}}' --condition-expression "attribute_not_exists(link_key)"

# 2. Invalidate one path on the hi.link distribution
aws cloudfront create-invalidation --distribution-id E1A2B3C4D5E6F7 --paths "/aZ9k2Lq"

# 3. Invalidate one path on a customer's distribution tenant
aws cloudfront create-invalidation-for-distribution-tenant --id dt_2wjDZi3hD1ivOXf6rpZJO1AB --invalidation-batch '{"Paths": {"Quantity": 1, "Items": ["/summit"]}, "CallerReference": "takedown-td_01J8Z6K3"}'

# 4. Check that an invalidation has completed
aws cloudfront get-invalidation --distribution-id E1A2B3C4D5E6F7 --id I2J0I21PCUYOIK

# 5. Which regions hold replicas of the links table
aws dynamodb describe-table --region us-east-1 --table-name links --query "Table.Replicas"

# 6. Replication latency from us-east-1 to ap-northeast-1 over the last hour
aws cloudwatch get-metric-statistics --region us-east-1 --namespace AWS/DynamoDB --metric-name ReplicationLatency --dimensions Name=TableName,Value=links Name=ReceivingRegion,Value=ap-northeast-1 --start-time 2026-09-26T11:00:00Z --end-time 2026-09-26T12:00:00Z --period 60 --statistics Maximum

# 7. The edge-log stream's shard count and status
aws kinesis describe-stream-summary --region us-east-1 --stream-name edge-logs

# 8. How many links are waiting to be scanned
aws sqs get-queue-attributes --region us-east-1 --queue-url https://sqs.us-east-1.amazonaws.com/111122223333/scan-queue --attribute-names ApproximateNumberOfMessages

# 9. Alarms currently firing
aws cloudwatch describe-alarms --region us-east-1 --state-value ALARM --alarm-name-prefix shortener

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Makes regions independent by construction (counter slices), and knows exactly which data may be eventually consistent (link records) and which may not (the counter, alias claims).
• Knows what DynamoDB global tables actually guarantee: last writer wins per item, conditions checked locally in the default mode, and MRSC's three-region, no-TTL, no-transaction limits, and designs around them (region-local counters, insert-only takedowns).
• Turns "within 5 minutes" into a proof with a budget, instead of a hope that invalidations land.
• Uses the platform's multi-tenant features for customer domains, and knows the quotas that come with them.
• Chooses approximate answers deliberately (HLL) and states the error and the definition of a visitor.
• Designs storage for deletion from the start.
• Finds that the CDN request fee dominates, notices the TTL doesn't change it, and names the real lever.

Follow-up questions

1. "Why not make the whole links table MRSC and skip the home-region fallback?" Answer: every write, including a billion generated creates a month, would wait for a cross-region acknowledgment, and MRSC doesn't support TTL, which we still use to clean up expired generated links. Generated codes don't need strong consistency, because the counter slices already make them unique. Only aliases do, and they're a small table.

2. "A court asks us to prove a link was down everywhere by 12:05." Answer: the takedown's audit record: accepted at 12:00:00, each region's cache overwrite with its time, the invalidation ID and completion time, and the three probe results through CloudFront with their times. Plus the design argument: the edge TTL guarantees that no edge copy could have been older than 180 seconds, even without the invalidation.

3. "We want to add a fourth region, in São Paulo." Answer: redirects and generated creates are easy: give it counter slice 3, a links replica and its own app servers. Aliases are the problem: our MRSC table can't take a fourth replica, and São Paulo isn't on MRSC's region list at the time of writing. São Paulo's alias claims would go to one of the three MRSC regions, paying the round trip, which is acceptable for a rare operation. We'd also check whether the region is worth it from the edge-hit data: many South American clicks may already be answered at the edge.

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint.

The Two Sentences That Matter Most

• Opening a round: "Before I design, let me ask about the read-to-write ratio and the shape of the traffic, because this system is almost all reads, and I want to know how spiky those reads are."
• When the scope is raised: "Here's what breaks in the current design, and here's the order I'll fix it in, starting with anything that could give two links the same code or keep a bad link alive."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels