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?

Judging Signups Without Seeing the Person

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

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

The diagram has two panels. What each fake account costs the attacker lists five costs: requests and compute, IP addresses, challenge solutions, inboxes and phone numbers, and surviving after signup. What each check costs a real user lists four levels of friction: nothing for invisible checks, a second for a small puzzle, a click or a task for a challenge, and a code for email or phone verification. The lines pair each defense with what it costs on both sides: invisible checks raise the attacker's request and compute cost at no cost to the user, a challenge makes the attacker pay for solutions while the user pays a click, and a verification code makes the attacker buy an inbox or phone number. Each defense adds to the attacker's panel. The design goal is to add a lot to it for traffic that looks automated, while most real users only ever meet the first level, "Nothing: invisible checks".

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 (an ordered list of checks, each rung harder to pass than the one before) 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), where p99 is the latency that 99% of signups stay under.
• 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...

Every accepted registration starts in PENDING. If the owner clicks the emailed link within 7 days, the account becomes ACTIVE; if not, it becomes EXPIRED and is removed. An ACTIVE account that shows abuse signals moves to RESTRICTED, and a review can clear it back to ACTIVE. 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: the script can create the account, but the account can do nothing until someone clicks a link in a real mailbox.

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

The baseline is an open form. Browsers, apps and scripts all send their requests to the load balancer, which passes every one of them to the signup service. The signup service writes an account to the user store and asks the email sender to send a message, for every request, with no check in between. Nothing on this path tells a script from a person, so the scripts and the people look the same, and the number of accounts created is limited only by how fast the attacker sends requests.

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 Fake Accounts

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

A request from a browser or app first reaches CloudFront for auth.example.com. In the Edge panel, AWS WAF applies the volume rule per IP, IP reputation and bot labels, and only then passes the request through the ALB. In the One Region, three AZs panel, the signup service on ECS Fargate runs its cheap checks, reserves its rate-limit counters in ElastiCache, and keeps the disposable-domain file it reloads from S3 every 5 minutes. Only for risky requests does it call Turnstile's siteverify, outside the Region. It then writes the user, email, idempotency and outbox items to DynamoDB. The email goes out afterwards: the table's stream delivers the outbox item, written in the same transaction as the account, to the email sender Lambda, which sends through Amazon SES.

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 diagram shows the item types of the table and how they relate. Each user claims exactly one EMAIL_UNIQUE item, gets zero or more verification tokens, and triggers zero or more outbox items. Each idempotency record creates at most one user. The EMAIL# item, not a secondary index, is what makes two concurrent signups with the same address impossible: both transactions try to write it with attribute_not_exists(PK), so only the first succeeds and the second is cancelled. A global secondary index can't enforce uniqueness, because it is updated after the write and accepts duplicate keys.

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:

pseudocodeCopy
register(request, key):
    # 1. stateless checks
    check the form_token HMAC (constant-time compare) and its age
    check that the honeypot field is empty
    check the email syntax
    check the email domain against the disposable-domain screen
    # 2. rate-limit reservations (step 1.1)
    if a reservation is over its limit and the request carries no challenge_token:
        return CHALLENGE_REQUIRED
    # 3. claim the idempotency key
    claimed = PutItem IDEM#key {status=IN_PROGRESS, owner=my_id, lease_until=now()+10 s, request_hash=h} only when attribute_not_exists(PK)
    if not claimed:
        item = strongly consistent read of IDEM#key   # an eventually consistent read can miss the item just written or show an older status
        if item.status = DONE and item.request_hash = h:
            release this request's rate-limit reservations   # so a retry never counts twice
            return item.response
        if item.request_hash != h:
            return 422   # key reused with another body
        if item.status = IN_PROGRESS and item.lease_until > now():
            return 409 IN_PROGRESS   # the original is still working
        if item.status = IN_PROGRESS and item.lease_until <= now():
            UpdateItem IDEM#key set owner=my_id, lease_until=now()+10 s, only when lease_until = item.lease_until   # take over
    # 4. challenge, only when needed
    if a challenge is needed:
        if challenge_verdict is recorded on IDEM#key:
            use the recorded verdict
        else:
            call siteverify (with its own idempotency_key)
            record the verdict on IDEM#key
    # 5. one transaction, all or nothing
    TransactWriteItems:
        Put USER#id   (new)
        Put EMAIL#email   only when attribute_not_exists(PK)
        Put VERIFY#token_hash
        Put OUTBOX#id
        Update IDEM#key set status=DONE, response=202   only when owner = my_id
    # 6. the address already has an account
    if the EMAIL# condition failed:
        Update IDEM#key set status=DONE
        queue a "someone tried to sign up" notice
    return 202

register creates at most one account for one signup form, however many times the browser retries it, and it places the durable guard before any call to an outside system. request is the submitted form: the email, display name and password, the form_token the page was served with, and the hidden honeypot field. key is the Idempotency-Key the browser sends, the same on every retry of one submission. h is a hash of the request body, stored as request_hash so that a reused key with a different body can be recognised. my_id identifies the signup task that runs this call, and lease_until is the time, on that task's clock, until which the task owns the claim: 10 seconds after the claim. Steps 1 and 2 are the cheap checks and the rate-limit reservations; a reservation over the limit means a challenge is required. Step 3 claims the key with a conditional PutItem on the IDEM#key item. If the claim is lost, a strongly consistent read of the item decides the answer: the stored response for a finished request with the same body, 422 for a different body, 409 while another task's lease is still running, or a conditional takeover when that lease has expired. Step 4 calls the challenge check (Turnstile's siteverify) only when needed, and records the verdict in challenge_verdict so that a retry does not ask again. Step 5 writes the user, the email claim, the verification token and the outbox item, and marks the IDEM#key item DONE with the response 202, all in one transaction that fails if another task now owns the key. Step 6 handles an email that already has an account: the key is marked done and the owner of that address gets a notice. The function returns 202 in both of these cases, so the response does not reveal whether the email address already has an account.

• 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...

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

Synthesizing vector architecture diagram...

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 37 cents per 1,000 real signups ($556 ÷ 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 $556 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...

This is Round 1 in one picture. Clients reach CloudFront and WAF, where the volume rule per IP stops floods. The signup service runs its cheap checks and reserves counters keyed on IP and email domain, and calls Turnstile only when the request looks risky. It stores users, idempotency records and outbox items, and the outbox item leads to the verification email. Nothing the account does works until that email is verified. Every limit in this picture is keyed on an IP address or an email domain, which is the weakness Round 2 starts from.

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

Every request is scored first. A score from 0 to 29 goes straight to Allow. A score from 30 to 59 goes to LightPoW and is allowed once the puzzle is solved. A score from 60 to 79 goes to PoWAndChallenge and is allowed once both the puzzle and the challenge are passed. A score of 80 or more goes to Verify and is allowed once an email or phone code is entered. Separately, a request on which several hard signals agree goes to Block. A request only climbs as far as its score demands, so most real users take the first arrow to Allow 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...

In the panel Signals, each weak alone, five families of signals are computed for every signup: network (ASN and reputation), TLS (JA4 cluster velocity), device (accounts per device), behavior (fill time and path) and identity (domain and phone type). All five feed one points model, which produces a score from 0 to 100 together with the reasons that added points. The score then picks a rung of the ladder: allow, proof-of-work, challenge, verify or block. No single family decides on its own; the score picks the rung, and the recorded reasons explain the decision later.

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

The bars show the mean time a low-end phone, assumed to compute 300,000 hashes a second, needs to solve a puzzle of difficulty D16 to D22: 0.22, 0.44, 0.87, 1.75, 3.5, 6.99 and 13.98 seconds. Each extra bit doubles the expected number of hashes, so each bar is twice the one before it. Our phone cap is D17, a mean of 0.44 s. Two bits past the cap (D19) take 1.75 s on average, and four bits past it (D21) take about 7 s on average, long enough to use noticeable battery and to make people abandon the signup. That is why the difficulty for phones stops at 17 and a challenge is added above it.

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: Bots Trigger Expensive SMS Messages

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 diagram is the edge funnel we plan for, in requests per second during a 100,000/s wave. Of the 100,000 requests, the reputation and IP rules block 30,000 (30%). The other 70,000 reach the JA4 and Bot Control rules, which stop 69,500 of them (99.3%) with a challenge or a block. The remaining 500 a second reach the origin, which is the target set in R2.1. 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...

Browsers, apps and bots behind proxies reach CloudFront for auth.example.com. In the panel Edge: AWS WAF, cheapest first, four rules run in order: IP reputation, rate by IP, rate by JA4 with a Challenge action, and Bot Control at the targeted level. These rules need no state of ours, so the edge stops volume before it costs us origin compute. What passes goes through the ALB into the panel Origin Region, three AZs, where the signup service computes the risk score, checks proof-of-work and picks a rung of the ladder. It keeps limits, JA4 counters, PoW seeds and the SMS budget in ElastiCache, and users, devices and idempotency records in DynamoDB. SMS goes through its own gate with country, prefix and budget limits before AWS End User Messaging SMS sends it; challenges are checked with Turnstile, email goes through SES, and every decision is also written to Kinesis as a security event, 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...

Trace 2: a risky signup, score 64

Synthesizing vector architecture diagram...

Trace 3: an SMS pumping attempt

Synthesizing vector architecture diagram...

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

The pie divides Round 2's monthly bill into four parts: SMS ($49,440), Bot Control's targeted level inspecting attack traffic ($25,200), the other WAF charges ($4,946: the fixed fees, request fees, Bot Control on normal traffic and Challenge responses) and everything else ($1,913: servers, cache, database, stream, email, load balancer and cross-AZ traffic). The first two parts together are about 92% of the bill ($74,640 of $81,498): text messages, and inspecting attack traffic at the edge. The servers and databases are about 2% of it. So the cost decisions that matter in this round are when we send SMS and which traffic reaches a paid edge rule, not how many servers we run.

Two lessons from the table. First, every attack request that reaches a paid inspection rule adds to 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 adds a cost per attempt but doesn't stop a paying attacker: 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...

This is Round 2 in one picture. Clients and bots pass the edge, with its WAF rules and Bot Control, before they reach the signup service. The signup service reads signals, computes a score, picks a rung of the ladder, sends verification by email or gated SMS, and writes the account. Every box in the picture is about signup: the checks at account creation are strong now, but nothing in this design looks at logins, posts or payments, which is where Round 3 starts.

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

An appeal starts as Submitted, becomes Queued once its evidence is attached, and moves to InReview when a reviewer claims it. The claim is a lease: if the reviewer leaves without deciding and the lease expires, the appeal returns to Queued for another reviewer. A review ends in one of two states: Overturned, when the enforcement decision was wrong, or Upheld, when it stands. Both outcomes become labels for the feedback loop (step 3.3), so every appeal teaches the scoring system something, whichever way it is decided.

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 Signup Checks to a Platform-Wide Trust System

Step 3.1: Fakes Got Through Signup

Synthesizing vector architecture diagram...

In the panel A cluster on strong links, Accounts 1 and 2 share device d8c1, Accounts 2 and 3 share card p41a, and Accounts 3 and 4 share one phone number. No single thing is shared by all four accounts, but this chain of shared devices, cards and phones links them into one cluster. In the panel Weak links, not used to cluster, a carrier IP prefix is used by Account 1, Account 4 and a stranger on the same carrier. If that weak link were used for clustering, the stranger would join the cluster too, and so would everyone else on that carrier. That is why only strong links 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...

Step 3.3: Attackers Adapt Weekly

Synthesizing vector architecture diagram...

A new rule or model starts as a Draft. Deployed, it runs in Shadow: it scores live traffic but never acts. If it beats the current version on the audit sample, it moves to Canary and enforces for part of the traffic. If its guardrails hold for 24 hours, it becomes Enforced. If a guardrail trips in Canary or in Enforced, it moves to RolledBack and goes back to Draft for another attempt. An enforced version is Retired when a newer one replaces it. 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...

This first diagram shows the path a request takes while the user waits, and the continuous feature updates behind it. Traffic passes the Edge panel (CloudFront and WAF, with Bot Control and rate rules) and reaches one of the four services in the Products panel: signup, login, posting and messaging, or payments. Before a sensitive action, the product asks the trust service to score it, and the trust service reads hot features from ElastiCache and trust scores, enforcement records and appeals from DynamoDB. Separately, every product streams what happened to Kinesis, and the feature aggregator reads that stream and keeps the features in ElastiCache and DynamoDB up to date, so the next score uses the latest behavior.

Synthesizing vector architecture diagram...

This second diagram shows the slower loops that learn from what happened. Kinesis also writes every event to S3, which holds the event and graph data. Once a day, the graph job on EMR Serverless reads S3, finds clusters and writes them to DynamoDB. Enforcement actions and appeals in DynamoDB go to review and appeals, and the reviewers' decisions come back to S3 as labels. Once a week, training reads the events and labels from S3, and a new version reaches the trust service only after it has passed shadow and canary. So features update continuously, clusters update daily, and the scoring model updates weekly.

The trust data (a design that fits)

Synthesizing vector architecture diagram...

The diagram shows how the trust data relates. Many accounts can use many devices and many payment instruments, and can verify many phone numbers; these three are the strong links that build clusters. Accounts are also seen from many IP prefixes, but those links are weak and kept as context only. Each account belongs to at most one cluster. Each account can receive many enforcement actions, and every enforcement action can carry at most one appeal, which is how a wrongly restricted person gets a review.

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

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

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

Answering the opening question. 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 signup 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)

bashCopy
# 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).