Design Bot Defense and Sybil-Resistant Registration

This page is one interview loop in three rounds. All three rounds design the same system: the part of a consumer platform that decides whether a signup (and later a login, a post or a payment) comes from a real person or from someone pretending to be many people. 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: Why Bot Defense?

A Bouncer Who Can't See Faces

Picture a club with a bouncer at the door, but the bouncer is behind a wall. All they get is a slip of paper pushed through a slot: a name, an email, a password. Most slips come from real people. Some come from one person with a printing press, pushing through ten thousand slips with ten thousand made-up names. The bouncer can't see faces. They can only look at the slips, how fast they arrive, what they're written on, and what happens after each person gets inside.

That is signup on the internet. A bot is a program that uses our site the way a person would, but automatically. A Sybil attack (named after a case study of a person with many identities) is one actor creating many fake identities so they count as many people: many votes, many free trials, many referral bonuses, many accounts to send spam from.

A few words we'll use all page:

What Makes It Hard

• The attacker adapts. Every rule we ship gets probed. What works this month may not work next month, so the design must be cheap to change and must measure itself.
• Identities are cheap. IP addresses, email addresses, browsers and phone numbers can all be rented or generated. Anything we key a limit on, the attacker tries to rotate.
• Every check costs real users something. A challenge adds friction. A strict limit catches a whole office behind one IP address. A visual puzzle can lock out a blind user. Collecting device signals raises privacy questions.
• Decisions are made on a live request path. Signup has to answer in well under a second, while the strongest evidence (what the account does next) arrives much later.

The Question the Whole Loop Answers

How do we make each fake account cost the attacker more than it's worth to them, while keeping signup nearly free for real people?

The idea underneath every round is an inequality. For an attacker, a fake account is worth it when

$$\text{Cost per fake account} < \text{Value of that account to the attacker}$$

We can't lower the value much (that's the product), so we raise the cost, and we raise it most for the traffic that looks least like a person. A rough estimate of the starting point, to show the scale: a script on a small cloud machine at $0.05 an hour (assumption) sending 10 signups a second makes 36,000 attempts an hour, about $0.0000014 per attempt. With a free throwaway inbox, a fake account costs the attacker around a millionth of a dollar. That figure is our order-of-magnitude estimate, not a measured market price, but the point stands: before we defend, fakes are almost free.

Synthesizing vector architecture diagram...

Each defense adds to the attacker's column. The design goal is to add a lot to the left for the traffic that looks automated, while keeping most real users in the top row on the right.

The answer grows every round:

• Round 1: rate limits keyed on what's cheap to check, a honeypot and timing check, email verification with a disposable-domain screen, and a managed challenge only when something looks wrong.
• Round 2: many signals combined into a risk score, a proof-of-work puzzle sized by risk, a ladder of challenges that escalates only as far as needed, defenses against SMS toll fraud, and edge filtering for volume.
• Round 3: detection after signup (clusters of accounts that share devices or payment cards), login defenses against stolen passwords, a feedback loop that retrains as attackers change, appeals for people we got wrong, and privacy and accessibility built in.

---

Round 1 · Mid-level · "Stop Scripted Signups on One App"

~35 min · SDE II (L5) · one app · 50,000 real signups a day, attacks of 1,000 attempts/s (assumptions) · real users sign up in under 30 s

R1.1 Establish Design Scope

The interviewer sets the scene: "We run a community app. New accounts get to post, message other members, and receive 50 free credits. For a few months, scripts have been creating accounts and using them to spam. Fix signup without making it painful for real people."

Out of scope for this round: device fingerprints and risk scores (Round 2), proof-of-work (Round 2), phone verification (Round 2), detecting fakes after signup (Round 3), login attacks (Round 3).

R1.2 Functional Requirements, Derived Step by Step

Not yet: device signals, proof-of-work, phone verification, graph detection.

R1.3 Non-Functional Requirements: the Questions

We name each quality first; the numbers come in R1.7.

• Friction. How many real users see a challenge? We set a budget: at most 5% of real signups (assumption).
• False positives. How many real users do we block outright? Blocks must be rarer than challenges, and a blocked person needs a way forward.
• Latency. The server's part of a signup (not counting the user's typing or a challenge) should finish in well under a second; we budget p99 < 500 ms (R1.7).
• Cost of verification. Every verification email and every challenge costs money, and an attacker can make us send them.
• Availability. If a dependency is down (the rate-limit cache, the challenge provider, the email sender), signup should degrade to a safer mode, not fail open and not fail closed for everyone.

R1.4 The API

Register

httpCopy
POST /v1/auth/register HTTP/1.1
Host: auth.example.com
Content-Type: application/json
Idempotency-Key: 5b0c2f0e-7a1d-4b8e-9f3a-2d6c1e8b4a70

{
  "email": "ana@example.org",
  "password": "<sent over TLS; the server hashes it with Argon2id>",
  "display_name": "Ana",
  "form_token": "1790500000.8f3c...hmac",
  "website": "",
  "challenge_token": null
}

• form_token is issued when the form is rendered: the render time plus an HMAC (a keyed hash only our servers can make). It lets us measure how long the form took to fill without trusting the client's clock. Because a token is only a timing signal, a count of submissions per form_token over its lifetime is a signal too: one render, many posts means a script.
• website is the honeypot: a field people never see and never fill (step 1.2). Its name is ordinary on purpose.
• challenge_token is empty the first time. It carries a managed-challenge token when we asked for one.
• Idempotency-Key names one attempt, so a retry after a lost response gets the same answer instead of a second account or a second email.

Responses

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

{ "status": "PENDING_VERIFICATION", "message": "Check your inbox to finish signing up." }

httpCopy
HTTP/1.1 403 Forbidden
Content-Type: application/json

{ "error": "CHALLENGE_REQUIRED", "challenge": { "provider": "turnstile", "site_key": "0x4AAAA..." } }

Why no 409 EMAIL_TAKEN? Because "this email already has an account" tells anyone which addresses are registered with us, which helps attackers who test stolen email lists. We answer 202 either way and send the existing owner an email ("someone tried to sign up with your address; if it was you, sign in here"), rate-limited per address. Some products accept that leak for usability; it's a product decision to make on purpose.

Why 403 and not 428 Precondition Required for the challenge? 428 is defined for requests that should be conditional (with If-Match and friends), not for "prove you're a person". A 403 with a clear error code is easier for clients to handle.

An account's states

Synthesizing vector architecture diagram...

A PENDING account exists but can't post, message or receive credits. That single rule removes most of the reward from scripted signups that can't read a real inbox.

Recap

• One write endpoint, idempotent by key, with an explicit challenge error the client knows how to handle.
• Accounts start PENDING and earn their powers by verifying email.
• We don't reveal whether an email is registered.

R1.5 Design Evolution: From an Open Form to Layered Checks

Each step is a problem, your turn to think, the answer, and what it costs us.

Step 1.0: The Baseline

Synthesizing vector architecture diagram...

An open form: every request that reaches the signup service creates an account and sends an email. The scripts and the people look the same.

At 1,000 attempts a second, this creates up to 3.6 million accounts an hour and asks our email provider to send 3.6 million emails, many to addresses that don't exist. The bounces alone threaten our ability to send email at all: Amazon SES places an account under review at a bounce rate of 5% and may pause sending at 10% (SES documentation, checked September 2026).

Step 1.1: One Script Creates Thousands of Accounts

Primitive: Distributed Rate Limiting · Drill: The Partner Whose Retry Loop Took Down Everyone Else (answered here: counters kept locally on N servers let a source through N times; a fixed window allows a double burst at the boundary) · Loop: Design a Distributed Rate Limiter (Round 1, steps 1.1–1.3, in depth)

Step 1.2: Scripts Fill the Form Instantly

Primitive: Honeypot Fields and Canary Traps · Drill: The Headless Scraper That Filled the Database with Garbage (answered here: why hidden fields fail against headless browsers that see what's visible, and why invisible traps beat a CAPTCHA for everyone)

Step 1.3: Throwaway Emails

Primitive: Disposable Email and Domain Blocklists · Primitive: Bloom Filters and Counting Filters · Drill: The 100,000 Free Trials That Vanished Overnight (answered here: why a hard-coded list goes stale within days, and why SMTP probing is the wrong tool)

Step 1.4: Still Too Many

Primitive: Cloudflare Turnstile Managed Challenges · Primitive: Google reCAPTCHA v2 and Enterprise Risk Analysis · Drill: The Flash Sale That Blocked 40% of Paying Mobile Shoppers (answered here and in R1.9: why challenges hit real users behind shared addresses, inside in-app browsers or with blocked scripts, and why a managed challenge beats an image puzzle for everyone)

Why challenges hit real people, and what we do about it. A challenge that fires on the wrong signal catches the wrong people:

• Shared addresses. A mobile carrier's shared IP address can hit a per-IP limit that no single person hit. That's why the per-IP rule challenges rather than blocks, and why its limit counts accounts, not requests.
• Scripts that can't run. In-app browsers (inside social apps), strict content blockers and some privacy settings can stop the challenge's script from loading or from keeping its token. We treat "the challenge failed to load" as a reason to offer another route (a code to the email address), never as proof of a bot.
• Expired tokens. A Turnstile token lasts 300 s. A person who solves the challenge, then spends six minutes choosing a display name, submits an expired token. The client refreshes the token when it expires instead of sending the dead one.

Round 1 Step Summary

R1.6 Architecture v1

Synthesizing vector architecture diagram...

Requests pass the edge's volume and reputation rules, then the signup service runs its cheap checks, its limits and (only for risky requests) the challenge check before writing anything. The email goes out afterwards, from an outbox item written in the same transaction as the account.

The data model (a design that fits)

One DynamoDB table holds several item types; the key design makes each check one read or one conditional write.

Synthesizing vector architecture diagram...

The EMAIL# item, not a secondary index, is what makes two concurrent signups with the same address impossible: a global secondary index can't enforce uniqueness.

The durable guard, placed before any outside call. A signup calls two outside systems: the challenge check (sometimes) and the email sender. The guard goes first:

textCopy
register(request, key):
  1. stateless checks: form_token HMAC (constant-time compare) and age, honeypot, email syntax, disposable screen
  2. rate-limit reservations (step 1.1); a reservation over the limit -> CHALLENGE_REQUIRED.
     A request whose claim finds a DONE record releases its reservation, so a retry never counts twice.
  3. claim: PutItem IDEM#key {status=IN_PROGRESS, owner=my_id, lease_until=now()+10 s,
            request_hash=h}  if attribute_not_exists(PK)
     - claim lost: read the item with a strongly consistent read (an eventually consistent
       read can miss the item just written or show an older status)
         status DONE and same request_hash    -> return the stored response
         different request_hash               -> 422, key reused with another body
         IN_PROGRESS and lease_until > now()  -> 409 IN_PROGRESS (the original is still working)
         IN_PROGRESS and lease expired        -> take over: UpdateItem set owner=my_id,
                                                  lease_until=now()+10 s  if lease_until = old value
  4. if a challenge is needed: if challenge_verdict is recorded, use it;
     else call siteverify (with its own idempotency_key) and record the verdict on IDEM#key
  5. TransactWriteItems, all or nothing:
       Put    USER#id                 (new)
       Put    EMAIL#email             if attribute_not_exists(PK)
       Put    VERIFY#token_hash, OUTBOX#id
       Update IDEM#key set status=DONE, response=202  if owner = my_id
  6. EMAIL# condition failed: the address has an account -> Update IDEM#key DONE and
     queue a "someone tried to sign up" notice; respond 202 either way

• now() is the signup task's clock. DynamoDB conditions have no server time; the writer supplies the value it compares against. A lease of 10 s against tasks whose clocks agree to well under a second is safe.
• An original request can outlive its retry. Suppose the original stalls for 15 s after claiming. Its lease expires; the retry takes over and finishes. When the original wakes, its transaction carries owner = my_id on the IDEM# item, which no longer matches, so the whole transaction is cancelled. The EMAIL# condition would stop a duplicate account anyway; the owner check also stops a duplicate email.
• TTL only tidies up. IDEM# and VERIFY# items carry a TTL so old ones disappear, but DynamoDB deletes expired items "within a few days of their expiration time". Every decision compares expires_at or lease_until in code.

Trace 1: a real person signs up

Synthesizing vector architecture diagram...

No challenge, no delay: Ana never learns there were checks. The email leaves after the commit, so a crash can't send an email for an account that doesn't exist.

Trace 2: the 4th signup from one IP in an hour

Synthesizing vector architecture diagram...

A request that passed a challenge is allowed past the per-IP limit. The verdict is stored on the idempotency record before the account is written, so a retry after a lost response doesn't need the single-use token again.

The email sender. The stream delivers each outbox item at least once, so an email can occasionally go out twice. That's harmless: both emails carry the same link. SES sends at $0.10 per 1,000 emails.

R1.7 Numbers

Figures marked published come from vendor documentation; the rest are assumptions or derived from them. Every monthly figure on this page uses a 30-day month: 720 hours, 2,592,000 seconds.

Traffic

What the limits let through

Rate-limit memory

Challenges and email

Latency: the server's part of a signup, every hop counted

Adding each hop's p99 overstates the true p99 of the whole path, because they rarely all hit their worst case at once. That makes it a safe upper bound for a budget. The user's own time (typing, solving the challenge, reaching the edge) is on top, and the 30-second target leaves plenty of room for it.

Cost (AWS list prices, us-east-1, checked September 2026)

That's about 38 cents per 1,000 real signups ($563 ÷ 1.5M signups), dominated by the cache and the email. The attacker's side of the ledger is what changed: every account beyond 150 an hour now costs them a solved challenge and a real inbox.

R1.8 Trade-Offs

Always-on CAPTCHA vs risk-based challenges

Build vs buy the challenge

Where to put the limits

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Keys limits on what's cheap to check (IP, email domain) and knows shared addresses make "block" the wrong action: over the limit means challenge.
• Counts accounts created, not requests, and keeps counters shared and atomic.
• Treats honeypots and timing as signals, not verdicts.
• Verifies email, and keeps a disposable-domain screen fresh automatically.
• Challenges only risky traffic, verifies tokens on the server, and handles single-use tokens across retries.
• Says what happens when each dependency fails, and chooses a safer mode over open or closed.

Follow-up questions

1. "Why not block every data-center IP address?" Answer: some real users come through corporate VPNs, privacy relays and cloud desktops, which use data-center addresses. A data-center label is a strong signal for a challenge, not proof of a bot. We block only when several signals agree.

2. "Your honeypot says bot but the challenge says human. Who wins?" Answer: the challenge, for that request: the honeypot's job was to decide whether to ask. We log the disagreement; a rising rate of honeypot hits that pass challenges means either autofill is filling the field (rename it) or attackers are paying for solves.

3. "Why store the challenge verdict instead of just verifying again on retry?" Answer: tokens are single use (Turnstile: "Each token can only be validated once"). A retry after a lost response would fail verification and block a real person who already proved themselves.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "Botnets on Residential Proxies at 100K Requests/s"

~40 min · Senior SDE (L6) · 10M real signups a month, peak 50/s · 100,000 malicious requests/s at the edge (planning figures) · edge decisions under 100 ms, at most 500 requests/s reach the origin

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. "Our app's signup was flooded by scripts: 1,000 attempts a second from about 50 cloud IPs. We layered cheap checks. At the edge, an AWS WAF rate-based rule stops floods per IP. In the signup service, shared sliding-window counters in ElastiCache limit accounts created per IP and per email domain, and going over a limit means a challenge, not a block, because offices and carriers share addresses. A honeypot field and a signed render-time token catch naive form-fillers, as signals, not verdicts. Every account starts PENDING and gets no powers until its owner clicks an emailed link, and a self-refreshing screen rejects disposable email domains. When any signal fires, we ask for a Cloudflare Turnstile challenge and check its token on the server; tokens are single use, so the verdict is stored on the request's idempotency record, which is claimed before any outside call. If the challenge provider is down we fail to a safer mode, not open. It costs about $563 a month. Open costs: everything keys on IP addresses and email domains, and a patient attacker with many addresses and real inboxes still gets through."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: cheap checks, limits keyed on IP and domain, a challenge only when a signal fires, and nothing works until the email is verified.

Round 1 step summary

Open costs: every limit is keyed on something the attacker can rent in bulk, and the only proof of a person is an inbox.

R2.1 The Scope Raise

Interviewer: "We grew. Ten million real signups a month now, and we added phone verification for some markets. The attackers grew too. They rent residential proxies, drive real browsers, buy CAPTCHA answers, and one weekend someone ran up an SMS bill we're still arguing with finance about. At peak we see 100,000 malicious requests a second at the edge. And our growth market is people on cheap Android phones: they must not be blocked."

Scope change

The "Not yet" list from R1.2 comes back: device signals and proof-of-work are in scope now.

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

1. A risk score, computed for every signup. An internal call inside the signup service's region (we show it as an API so the contract is clear):

httpCopy
POST /internal/v1/risk/score HTTP/1.1
Content-Type: application/json

{
  "action": "signup",
  "request_id": "req_01J9ZQ3C6X8R2M4T7V1B5N0K9D",
  "network": { "ip": "203.0.113.24", "asn_type": "residential", "waf_labels": ["bot-control:signal:automated_browser"] },
  "tls": { "ja4": "t13d1516h2_8daaf6150882_e5627efa2ab1" },
  "device": { "device_id": "dv_7c1e...", "waf_token_fingerprint": "fp_91a2..." },
  "form": { "fill_ms": 41000, "honeypot_filled": false },
  "identity": { "email_domain": "example.org", "domain_type": "freemail", "phone_type": null }
}

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

{
  "score": 64,
  "action": "POW_AND_CHALLENGE",
  "pow_difficulty_bits": 17,
  "reasons": ["ja4_cluster_velocity_high", "device_new", "asn_residential"],
  "model_version": "rules-2026-09-21"
}

2. A proof-of-work challenge. The client asks for a puzzle, solves it in a background thread (a Web Worker in the browser), and sends the answer with the signup.

httpCopy
POST /v1/auth/pow-challenge HTTP/1.1
Content-Type: application/json

{ "action": "signup", "request_id": "req_01J9ZQ3C6X8R2M4T7V1B5N0K9D" }

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

{
  "seed": "Jq3v8pX0cM4r2tQy9wLb1A",
  "difficulty_bits": 17,
  "expires_at": 1790500120,
  "signature": "hmac-sha256:4be1...c90a"
}

The signup then carries "pow": { "seed": "...", "nonce": 88213, "difficulty_bits": 17, "expires_at": 1790500120, "signature": "..." }.

3. Phone verification, behind the ladder.

httpCopy
POST /v1/auth/phone/start HTTP/1.1
Content-Type: application/json
Idempotency-Key: 0d2f4c1a-9b7e-4e3a-8f61-5c2b7a9d1e04

{ "account_id": "usr_8842", "phone": "+15550100123", "channel": "sms" }

POST /v1/auth/phone/verify takes the code; five wrong codes invalidate it.

The risk actions, as a ladder

Synthesizing vector architecture diagram...

A request only climbs as far as its score demands. Most real users stop at the first arrow and never see anything.

Recap

• Every signup gets a score with reasons and a model version, so decisions can be explained and replayed.
• Proof-of-work and phone verification are rungs on a ladder, not steps for everyone.
• SMS is gated, limited and can be switched off without breaking signup.

R2.4 Design Evolution: Signals, Cost and Escalation

Step 2.1: IPs Rotate Endlessly

Primitive: Bot Defense, Sybil Resistance and Registration Abuse

Synthesizing vector architecture diagram...

Five families of signals feed one score. The score picks the rung; the reasons explain it.

Step 2.2: Make Each Attempt Cost Something

Primitive: Hashcash and Client-Side Proof of Work · Drill: The Proof-of-Work Challenge That Melted Mobile Batteries (answered here and in R2.8: a fixed difficulty takes a phone many times longer than a desktop, and proof-of-work prices attempts without needing an identity, which is what a token bucket keyed on IPs can't do against rotation)

Synthesizing vector architecture diagram...

Each bit doubles the wait. Two bits past our cap turn a half-second puzzle into a two-second one; four bits turn it into a battery drain.

Step 2.3: One Challenge for Everyone

Primitive: Google reCAPTCHA v2 and Enterprise Risk Analysis · Drill: The Silent Fraud Ring That Maintained a 0.9 reCAPTCHA Score (answered here: why human-operated farms on real devices score as human, and why a continuous score beats a pass-or-fail checkbox)

Step 2.4: SMS Costs Exploded

Loop: Design a Notification System (Round 3, step 3.3: SMS routes and providers)

Step 2.5: Decide at the Edge

Primitive: API Gateway and Reverse Proxy · Loop: Design a Distributed Rate Limiter (Round 2, step 2.5: trusting only the edge's view of the client IP, and the layers at the edge) · Loop: Shopify: Pods, Flash Sales and Payment Resilience (Round 2, step 2.5: bots at checkout)

Synthesizing vector architecture diagram...

The edge funnel we plan for, in requests per second during a 100,000/s wave. The 30% and 99.3% are planning targets to be measured, not published rates; if the edge lets more through, the origin's scoring and proof-of-work still apply, at a higher compute cost.

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

The edge absorbs volume with rules that need no state of ours; the signup service scores what's left and picks a rung. SMS goes through its own gate with its own limits, and every decision is also written to a stream for tuning and for Round 3.

The device data (a design that fits)

Device IDs and phone numbers are stored as keyed hashes (an HMAC with a secret key), so the table alone doesn't reveal them.

Keeping the device limit honest under concurrency. "Read the count, check it, create the account" lets two concurrent signups from one device both see 2 and both succeed. Instead, the account transaction includes the device summary: read it with a strongly consistent read (an eventually consistent read or a global secondary index can lag and show an older count), drop entries older than 30 days, refuse if 3 remain, and write the new list with the condition version = <what we read>. If another signup changed it first, the transaction is cancelled and we retry once with a fresh read.

Trace 1: a real user on a phone, score 12

Synthesizing vector architecture diagram...

Nothing visible happened. The score came from counters read in parallel; the only writes are the idempotency claim and one transaction.

Trace 2: a risky signup, score 64

Synthesizing vector architecture diagram...

The cheap checks run before any cache call. A bot that pays for both the puzzle and a solved challenge gets through this rung, which is why the next rungs, and Round 3, exist.

Trace 3: an SMS pumping attempt

Synthesizing vector architecture diagram...

The attacker's 31st code in that prefix never leaves. The conversion alarm tells us to mark the prefix high-risk or block the country before the budget breaker is ever needed.

R2.6 Numbers and Cost

All figures are assumptions unless marked published or derived. Monthly figures use a 30-day month (720 hours, 2,592,000 s).

Traffic

Proof-of-work, both sides

Fingerprint and signal stores

SMS

The biggest lever is the 20%. Offering phone verification only on rung 3, to perhaps 5% of signups (assumption), would cut normal SMS spend to $12,000 a month.

False positives, measured

Latency at the origin (p99, every hop, assumptions)

The edge's own decision is inside the first 10 ms (assumption; AWS doesn't publish WAF's added latency), well under the 100 ms target.

Cost (AWS list prices, us-east-1, checked September 2026)

AWS WAF: $5 a web ACL, $1 a rule, $0.60 per million requests. Bot Control: $10 a month per web ACL; the common level includes 10M requests a month then costs $1 per million; the targeted level includes 1M then costs $10 per million. We assume normal auth traffic of 300 requests/s at the edge (50/s of them POSTs to the scoped paths), and 10 attack hours a month at 100,000/s = 3.6 billion requests, 30% of which cheaper rules block before Bot Control.

Synthesizing vector architecture diagram...

Two lines are about 92% of the bill ($74,640 of $81,504): text messages, and inspecting attack traffic at the edge. The servers and databases are rounding error.

Two lessons from the table. First, attack traffic that reaches a paid inspection rule runs up the bill: each million requests Bot Control's targeted level inspects costs $10, so rule order (cheap blocks first) and scope-down (only auth POSTs) are cost decisions, not only security ones. Rejecting the same requests at the origin would cost less in compute, about 40 tasks for a few hours, but the origin can't interrogate browsers and scales minutes late; we pay the edge for capability and speed, not price. Second, SMS is the most expensive way we verify people, and the attacker chooses when we use it.

Per real signup, the whole system costs about $81,500 ÷ 10M = $0.008.

R2.7 Trade-Offs

PoW vs CAPTCHA

We use both, on different rungs: they're beaten by different kinds of spending, so stacking them raises the attacker's cost more than doubling either.

Friction vs catch rate

Buy vs build the score

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

• Explains why IP limits fail against residential proxies with arithmetic (0.2 requests/s per IP), and moves to many weak signals compared with baselines.
• Does the proof-of-work math: $2^D$, the geometric tail, a difficulty cap from a device budget, and an honest attacker cost.
• Builds a ladder where each rung is beaten by a different kind of spending.
• Treats SMS as a cost an attacker controls, and caps it with the right kinds of counters.
• Splits work between edge and origin, and knows what the edge costs per request under attack.

Follow-up questions

1. "Why not make JA4 a hard block list?" Answer: a fingerprint identifies a TLS stack, not a person. Real users of the same browser build share it, and attackers can move to a stack that matches a popular browser. We use it for velocity against a baseline, with a Challenge action, so real users whose page or app already holds a WAF token pass.

2. "The attacker claims every request is from a phone to get $D = 17$. Now what?" Answer: that's expected. Claiming "phone" never lowers the score; it only swaps extra puzzle difficulty for a managed challenge at the same rung. The claim also becomes a signal: a JA4 or device profile that doesn't fit the claimed device raises the score.

3. "Why keep email verification if we have all these signals?" Answer: the signals decide how hard to make signup; verification decides what an account may do. A fake account that can't prove a real channel stays PENDING and harmless.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "Trust and Safety Across the Whole Platform"

~45 min · Principal (L7) · 200M accounts, 50M daily users (assumptions) · ≈ 3,150 scored actions/s on average, ≈ 29,500/s at the peak of a login attack (derived) · a measured fake-account rate, a measured false-positive rate, a friction budget per action

R3.0 Where We Left Off

Round 2 in 60 seconds. "Attackers moved to 500,000 residential IPs at 0.2 requests a second each, so IP limits stopped meaning anything. We combined weak signals, network, TLS fingerprint velocity against a baseline, device account counts, behavior and identity, into a points score with reasons and a version. The score picks a rung on a ladder: invisible, a Hashcash-style proof-of-work sized by risk and capped at 17 bits on phones so the slowest supported phone finishes in 2 s at P95, a managed challenge, a verified email or phone, or a block. Proof-of-work is a tax, not a wall: GPUs make each solve cost well under a millionth of a dollar, so the expensive rungs sit above it. SMS is gated by the ladder, blocked by country where we don't serve, capped per destination prefix and per hour of spend, and watched for conversion. The auth endpoints have their own CloudFront distribution, with WAF rules cheapest first and Bot Control's targeted level scoped to auth POSTs. It costs about $81,500 a month, about 92% of it SMS and edge inspection of attack traffic. Open costs: fakes that pass signup are never looked at again, logins are unprotected, rules are hand-tuned, and nobody can appeal a wrong decision."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: a strong front door. Everything after the door, logins, posts, payments, is still unguarded.

Round 2 step summary

Open costs: signup-only defense, hand-written rules, no feedback, no appeals.

R3.1 The Scope Raise

Interviewer: "Signup is much better. But the fakes that got through are now posting scams and messaging members. Last month, a wave of logins with stolen passwords took over thousands of real accounts. The attackers change tactics every week, and we find out from users. Legal wants us to show we handle personal data carefully, and we've had complaints from blind users about challenges. And people we blocked by mistake have nowhere to go. We want one trust system for the whole platform."

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

1. A trust score per account, updated over time. Every product asks the same service.

httpCopy
GET /internal/v1/trust/accounts/usr_8842?action=message_stranger HTTP/1.1

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

{
  "account_id": "usr_8842",
  "trust_tier": "NEW",
  "action_decision": "ALLOW_LIMITED",
  "limits": { "messages_to_strangers_per_day": 5 },
  "reasons": ["account_age_under_7_days", "email_verified"],
  "cluster_risk": "NONE",
  "model_version": "trust-2026-09-24.2",
  "evaluated_at": "2026-09-28T10:02:11Z"
}

2. Enforcement actions. Products don't ban accounts themselves; they ask the trust service to act, so every action is recorded, explained and appealable.

httpCopy
POST /internal/v1/enforcement/actions HTTP/1.1
Content-Type: application/json
Idempotency-Key: enf-cluster-77120-usr_8842

{
  "account_id": "usr_8842",
  "action": "RESTRICT",
  "scope": ["post", "message_stranger", "payout"],
  "reason_codes": ["cluster_shared_payment_instrument"],
  "evidence_ref": "cluster/77120/2026-09-28",
  "appealable": true
}

3. Appeals.

httpCopy
POST /v1/appeals HTTP/1.1
Content-Type: application/json
Idempotency-Key: 3c1b9e0a-44f2-4d61-b8e2-7a0c5d19f6b3

{ "enforcement_id": "enf_55120", "statement": "This is my only account. I share a laptop with my brother." }

Synthesizing vector architecture diagram...

A reviewer's claim on an appeal is a lease: if they walk away, it returns to the queue. Both outcomes become labels for the feedback loop (step 3.3).

4. A signal-sharing contract. Every product emits events in one schema, and each field says why we're allowed to use it and for how long.

jsonCopy
{
  "event_id": "evt_01J9ZT8Q2M",
  "event_seq": 1840021,
  "account_id": "usr_8842",
  "action": "payment_attempt",
  "occurred_at": "2026-09-28T10:02:10Z",
  "signals": {
    "device_id_hash": { "value": "d8c1...", "purpose": "abuse_prevention", "retention_days": 90 },
    "payment_instrument_hash": { "value": "p41a...", "purpose": "abuse_prevention", "retention_days": 180 },
    "ip_prefix": { "value": "203.0.113.0/24", "purpose": "abuse_prevention", "retention_days": 30 }
  },
  "outcome": "declined_by_issuer"
}

event_seq increases per account, so a consumer that sees an event twice can tell (step 3.3).

Recap

• One trust service answers "may this account do this action now?" for every product, with reasons.
• Enforcement goes through one API, so it's recorded and appealable.
• Signals carry their purpose and retention with them.

R3.4 Design Evolution: From a Front Door to a Trust System

Step 3.1: Fakes Got Through Signup

Synthesizing vector architecture diagram...

Accounts 1 to 4 never share one thing, but a chain of shared devices, cards and phones links them. The carrier address links them to a stranger too, which is exactly why weak links don't join clusters.

Step 3.2: Credential Stuffing on Login

Drill: The Credential Stuffing Wave That Bypassed IP Rate Limits (answered here: why per-IP limits fail at 0.2 attempts per IP, and why an SMS code on every login is the wrong trade) · Loop: Design a Distributed Rate Limiter (Round 3, step 3.3: the same attack seen from the gateway)

Synthesizing vector architecture diagram...

The password was right, and it didn't matter: a correct password from breach data on an unknown device earns a step-up, not a session.

Step 3.3: Attackers Adapt Weekly

Synthesizing vector architecture diagram...

A rule or model earns enforcement in stages, and either guardrail trip sends it back. Nothing goes from a draft straight to blocking people.

Step 3.4: A Real User Was Blocked

Step 3.5: Privacy and Accessibility

Step 3.6: Build or Buy?

Round 3 Step Summary

R3.5 Global Architecture

Synthesizing vector architecture diagram...

Products ask the trust service before sensitive actions and stream what happened. Features update continuously; clusters update daily; labels from review and appeals flow back into training, and new versions reach the trust service only through shadow and canary.

The trust data (a design that fits)

Synthesizing vector architecture diagram...

Strong links (device, card, phone) build clusters; IP prefixes are kept as weak context only. Every enforcement can carry one appeal.

Per-action safe defaults decide what happens when the trust service can't answer (R3.8):

Trace 1: a fake cluster is removed

Synthesizing vector architecture diagram...

Restriction first, bans only for accounts a person reviewed: the sample found 1 real account in 20, so the 220 unreviewed ones stay restricted and appealable rather than banned. The one real account is restored, and her link is cleared so the next run doesn't catch her again.

Trace 2: the credential-stuffing wave is step 3.2's sequence: the edge challenges most attempts, the login service steps up correct-but-breached passwords, and the failure-ratio rule then steps up every unknown-device login until the wave ends.

Trace 3: an appeal

Synthesizing vector architecture diagram...

The decision write is conditional on the reviewer still holding the claim, so a reviewer whose claim expired and was taken over can't overwrite the newer decision.

R3.6 Numbers and Cost

All figures are assumptions unless marked published or derived. Monthly figures use a 30-day month.

Scoring load

The scoring fleet

Scaling from 8 to 50 tasks takes minutes; until it does, the edge sheds most of the wave and actions fall back to their safe defaults (R3.8). That's a choice: 50 tasks all month would cost about $3,000 more (42 extra tasks × $0.09874 × 720).

The graph

Labels and people

Cost (AWS list prices, us-east-1, checked September 2026): what Round 3 adds to Round 2's $81,500

Notes on the rows: the feature cache holds about 30 GB of hot features (50M daily users' recent features plus device and IP aggregates) on three shards with a replica each (about 29 GiB usable, so we add a fourth shard at the first sign of evictions); 32 Kinesis shards take 32,000 records a second, enough for the wave; DynamoDB reads are eventually consistent (half a read unit each) because trust features tolerate a second of lag, while enforcement and appeal decisions use conditional writes, which always act on the latest item.

Why not AWS's account-takeover rules on every login? Fraud Control's per-request tiers run from $1,000 down to $50 per million requests analyzed (the first 10,000 free; then $0.001, $0.0007, $0.0004 and $0.0002 per request up to 30M, and $0.00005 beyond). The 576M wave requests alone would cost about $38,400 a month at the tiered prices ($28,800 even if every request were billed at the lowest tier), and attackers decide how many requests there are. If we use it, it goes behind the cheaper rules, scoped to login, where it sees only what they didn't stop.

R3.7 Trade-Offs

Friction vs abuse, per action

False positives vs catch rate

Centralized trust vs per-product (closing the loop)

The whole loop, in one line: Round 1 made fakes need a real inbox, Round 2 made them pay per attempt and per rung, and Round 3 makes them pay again after signup, because a fake that looks perfect at the door still has to behave like a person, alongside the other fakes it shares a device, a card or a phone with.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Signals OPS 8 · REL 6

Procedure: an attack is in progress SEC 10 · OPS 10

1. Name it. Signup wave, login wave, or SMS pumping? Which distribution, which paths?
2. Contain at the edge first. Add a new, stricter rate-based rule (by IP or by JA4) with a Challenge action (on POSTs, a check for a valid WAF token) rather than editing a live rule, which would reset its counts.
3. Raise the ladder, not the wall. Lower the score thresholds for the affected action for a fixed period (1 hour) with an automatic end, so a temporary change can't become permanent by accident.
4. Protect the money. For SMS, block the pumped countries or prefixes in the protect configuration; for logins, step up every unknown device.
5. Watch real users. Challenge pass rate and completion rate by segment: are we hurting a country, a browser, assistive technology users?
6. After the attack: revoke sessions opened from unknown devices during the wave, ask their owners to reset, remove the temporary thresholds, and write a correction-of-error review: which signal would have caught it sooner?

Go deeper: CLI checks (replace names and IDs with real ones)

textCopy
# 1. Which IPs a rate-based rule is limiting right now (CloudFront web ACLs live in us-east-1)
aws wafv2 get-rate-based-statement-managed-keys --scope CLOUDFRONT --region us-east-1 --web-acl-name auth-edge --web-acl-id 11111111-2222-3333-4444-555555555555 --rule-name register-rate-by-ip

# 2. A sample of requests one rule matched in a 15-minute window
aws wafv2 get-sampled-requests --scope CLOUDFRONT --region us-east-1 --web-acl-arn arn:aws:wafv2:us-east-1:111122223333:global/webacl/auth-edge/11111111-2222-3333-4444-555555555555 --rule-metric-name register-rate-by-ja4 --time-window StartTime=2026-09-28T10:00:00Z,EndTime=2026-09-28T10:15:00Z --max-items 100

# 3. The SMS protect configurations
aws pinpoint-sms-voice-v2 describe-protect-configurations --region us-east-1

# 4. Block SMS to one country during pumping (XX is the two-letter ISO country code)
aws pinpoint-sms-voice-v2 update-protect-configuration-country-rule-set --protect-configuration-id protect-0123456789abcdef --number-capability SMS --country-rule-set-updates '{"XX":{"ProtectStatus":"BLOCK"}}' --region us-east-1

# 5. The account's monthly SMS spend limits
aws pinpoint-sms-voice-v2 describe-spend-limits --region us-east-1

# 6. The feature cache's shards and which nodes are primaries now
aws elasticache describe-replication-groups --replication-group-id trust-features

# 7. Alarms currently firing for the trust system
aws cloudwatch describe-alarms --state-value ALARM --alarm-name-prefix trust-

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Moves from judging requests to judging accounts and clusters, and knows which links are strong and which are hubs.
• Defends logins without lockouts: breach data, velocity on distinct keys, device binding, step-up, with arithmetic for what gets through.
• Builds a feedback loop with labels, an unbiased audit sample, and a safe rollout path with automatic rollback.
• Treats false positives as a measured number, and knows appeals undercount them.
• Designs privacy and accessibility in, with claims kept to what the standards actually say.
• Decides build vs buy by capability, and prices vendor rules under attack.

Follow-up questions

1. "Why not run the graph job every hour?" Answer: it would cut the average delay for a brand-new cluster from 14 hours to about 2.5 (0.5 h average wait plus 2 h run), for 24 times the compute. The neighbor lookup already catches accounts joining known clusters in seconds, so the batch's job is finding new clusters. We'd first try an incremental job on just the last hour's new links.

2. "A card is shared by 12 accounts. Is that a fraud ring?" Answer: maybe a family, a small business, or a ring. The card crossed our hub threshold of 10, so it no longer merges accounts into one cluster, but it's a signal on each account. Their behavior decides: 12 accounts sharing a card that all message strangers on day one is a ring; 12 that buy groceries isn't.

3. "The trust service is a single point of failure for every product. Isn't that worse?" Answer: it is a shared dependency, so each action has a safe default that needs no trust service, and the edge keeps working without it. The alternative, five separate systems, fails more quietly: none of them sees the ring.

Interview gotchas from this round's wrong answers

---

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. For rate limiting in depth, see the rate limiter loop; for bots at a checkout rather than a signup, the Shopify case study; for idempotency and leases underneath all of this, the loop primitives on idempotency and leases and fencing.

The Two Sentences That Matter Most

• Opening any round: "Fake accounts are an economics problem: I'll raise the attacker's cost per account above what it's worth to them, spending friction only on traffic that looks automated, so real people see nothing."
• When scale arrives: "No single signal is proof, so I'll combine many weak ones, escalate friction one rung at a time, keep judging accounts after signup as evidence arrives, and measure my own false positives with an audit sample, because the attacker adapts and so must the system."

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

Sources

All sources used on this page, checked September 2026 unless a date is given.

• Back, A., Hashcash, proposed 1997: the original computational postage idea.
• Cloudflare, Turnstile: server-side validation: the siteverify endpoint, 300 s token validity, single use, timeout-or-duplicate, idempotency_key.
• Cloudflare, Turnstile widget types and Turnstile plans: managed, non-interactive and invisible modes; the free plan's 20 widgets and unlimited challenges.
• Cloudflare, Eliminating CAPTCHAs on iPhones and Macs using new standard, June 8, 2022: Private Access Tokens, supported OS versions, attester and issuer roles.
• Google, reCAPTCHA: verifying the user's response and reCAPTCHA v3: two-minute tokens verified once, the 0.0–1.0 score.
• Google Cloud, Interpret assessments for websites: 11 score levels, four without a billing account.
• AWS, AWS WAF Developer Guide: rate-based rule settings, rate-based rule caveats, aggregation options, request components including JA3 and JA4, Bot Control, the Bot Control rule group, CAPTCHA and Challenge and immunity times.
• AWS, AWS WAF pricing: web ACL, rule and request fees; Bot Control; CAPTCHA; Fraud Control.
• AWS, Adding CloudFront request headers: CloudFront-Viewer-JA3-Fingerprint and CloudFront-Viewer-JA4-Fingerprint.
• AWS, Amazon Cognito threat protection: compromised credentials, adaptive authentication, the Plus plan, no rate limits.
• AWS, What is Amazon Fraud Detector?: closed to new customers as of November 7, 2025.
• AWS, AWS End User Messaging SMS: country rule modes (artificially inflated traffic; Allow, Block, Monitor, Filter) and spending quotas.
• AWS, Amazon SES enforcement FAQ: bounce rate below 2% recommended; review at 5%, possible pause at 10%.
• AWS pricing pages and price list API for Fargate, ElastiCache, DynamoDB, Kinesis Data Streams, SES, Lambda, EMR Serverless, S3 and Elastic Load Balancing (us-east-1).
• FoxIO, JA4+ fingerprinting.
• Have I Been Pwned, API v3: Pwned Passwords: the k-anonymity range API, padding, no key, no rate limit.
• NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, 2025: password blocklists, no composition rules or forced periodic changes, minimum lengths, the 100-attempt ceiling and throttling techniques.
• IETF, RFC 9576: The Privacy Pass Architecture, June 2024, with RFC 9577 (the HTTP authentication scheme) and RFC 9578 (issuance protocols).
• W3C, Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum), WCAG 2.2, and success criterion 1.1.1 Non-text Content (its CAPTCHA provision).