How do you design abuse and access-control infrastructure?

In this article

1. Before you start
2. Why interviewers ask this
3. Abuse and access-control infrastructure from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is part of distributed systems interview questions and assumes the basics below.

Why interviewers ask this

Candidates report this question in several wordings: block requests from banned addresses supplied by an outside authority, stop bots and abuse on a chat product, intercept malicious requests on a social platform, or build a simple identity and access system. These prompts share one skeleton, so one answer covers all of them.

Interviewers use it to see whether you treat security as layers with costs, not as one clever filter. A weak answer says "add a rate limiter" or "block bad IPs". A strong answer names what each layer catches and misses, keeps the cheap check on the hot path, and says how a wrong block is corrected. A Staff-level answer adds distribution: how a banned-address list reaches hundreds of edge nodes, how long that takes, and what happens when one node has an old list.

Abuse and access-control infrastructure from first principles

Denylist

A denylist is a list of callers, such as addresses, address ranges or accounts, that a system refuses before doing any other work, usually pushed from a central source to the nodes that face the internet, so a block costs one lookup and no application code.

Risk score

A risk score is a single number a system computes from weak signals about a request, such as account age or browser traits, so that it can allow, challenge or block based on thresholds rather than on one rule.

Policy decision point

A policy decision point is the component that answers allow or deny for a request, given who is calling, what they want and the written policy, while a separate enforcement point applies that answer; the National Institute of Standards and Technology (NIST) describes this split in special publication 800-162.

In plain words

Picture an office building. A guard at the gate holds a list of banned visitors. A turnstile counts how often each person enters. A badge reader at each door checks who may open it. A logbook records everything.

Each part is simple, and each can be fooled alone. The analogy breaks in one place: in software, an attacker can change address and identity thousands of times a minute, so the guard's list never covers the whole problem.

In one precise sentence, abuse infrastructure decides whether to serve a request at all, and access control decides what a known caller may do. Authentication is proving who the caller is. Authorization is deciding what that caller may do.

Step 1: An edge denylist drops known-bad callers first

The edge denylist drops known-bad addresses before any other work. The list comes from an authority you trust, such as an internal security team, an outside feed or your own past decisions. A central service validates and versions the list, then pushes it to every node that faces the internet.

Each node holds the list in memory: a hash set for single addresses and a prefix lookup for ranges written in Classless Inter-Domain Routing (CIDR) notation, such as one network block. A request costs at most 33 lookups for IPv4 addresses, one hash lookup for each of the 33 prefix lengths from /0 to /32, the /32 being the exact match.¹ Production edges often use a longest-prefix-match trie instead. Input: a source address. Output: drop, or pass to the next layer. You now know the cheapest layer; its weakness, shared and rotating addresses, comes next.

Step 2: Rate limits and risk scores judge the rest

Rate limits and risk scores judge the remaining traffic. A rate limit throttles one loud caller. The Open Worldwide Application Security Project (OWASP) lists missing limits on resource use as an application programming interface (API) risk, and Request for Comments (RFC) 6585 defines the 429 status code and the Retry-After header that tell a client to slow down.

A limit alone is easy to dodge. In the worked example, a limit of 100 requests a minute per address never fires on an attacker who sends 90 a minute from each of 2,000 addresses, 180,000 requests a minute in total.¹ OWASP also describes abuse of business flows, such as scalping and bulk account creation, that no single request reveals (risk number six in the OWASP API list; automated threats). So add a risk score built from weak signals: account age, address type, browser traits, repeated payloads and failed logins. Input: request features. Output: allow, challenge or block.

Step 3: Authentication and an access check decide what a caller may do

The identity and access check decides what a known caller may do. First authentication proves who is calling, then the policy decision point answers whether this caller may perform this action on this resource. Policies can be written as roles, as attributes of the caller and resource, or as relationships between people and objects.

Google's Zanzibar paper describes the relationship style at global scale. It also shows the hard part: a permission change must take effect before later reads, or a removed person can still see new content. Zanzibar attaches a consistency token, called a zookie, to prevent that "new enemy" problem. The rule is that a read must not use a snapshot older than the permission change; for the related idea of reads that see earlier writes, see linearizable. Input: caller, action, resource. Output: allow or deny.

Step 4: An audit log feeds back into the denylist

The audit log feeds new bad addresses back to the denylist. Every block, challenge and access decision is written with the signals that caused it. Analysts and automated jobs read that log, confirm abusers and add them to the denylist, and they remove wrong blocks.

Two properties matter. First, every entry expires or is reviewed, so a shared address blocked today does not stay blocked for years. Second, an appeal path exists for people who were blocked by mistake. Input: decisions and signals. Output: updated list and thresholds. The loop turns four separate checks into one system that improves; the full flow is drawn below.

1 · Edge denylist2 · Limit and score3 · Access check4 · Audit logReplay

Step-by-step description

1. Known-bad addresses are dropped first.
2. Remaining traffic is judged.
3. Known callers get only what policy allows.
4. Decisions feed the denylist.

• The edge denylist drops known-bad addresses before any other work.
• The limiter and risk score judge the remaining traffic.
• The identity and access check decides what a known caller may do.
• The audit log feeds new bad addresses back to the denylist.

The edge denylist drops known-bad addresses before any other work. The limiter and risk score judge the remaining traffic. The identity and access check decides what a known caller may do. The audit log feeds new bad addresses back to the denylist.

Worked example

All numbers here are illustrative assumptions fed to arithmetic: a denylist of 4,000,000 single addresses and 1,000,000 ranges, 300 edge nodes and 100,000 requests per second per node.¹ Estimating like this is the habit taught in back-of-the-envelope estimation.

Memory. Each single IPv4 address is 4 bytes, so 4,000,000 of them take 16 megabytes raw. A hash set at an assumed 32 bytes per entry takes 128 megabytes (illustrative).¹ The 1,000,000 ranges sit in a compact sorted array, so at an assumed 8 bytes each they take 8 megabytes.¹ That fits in every edge node.

Lookup cost. At most 33 lookups per request times 100,000 requests per second is 3,300,000 lookups per second per node in the worst case, which matters for tail latency.¹

Propagation. Pushing through a tree with 10 children per node reaches 300 nodes in 3 levels; at an assumed 2 seconds per hop, a new list arrives everywhere in about 6 seconds.¹

Shared addresses. If one address is shared by 500 people (illustrative) and one abuses it, blocking the address blocks the 499 innocent others, 99.8% of that address.¹

Scoring. With illustrative weights (new account 20, datacenter address 25, headless browser 30, identical payloads 25, high failed-login ratio 20), a challenge threshold of 60 and a block threshold of 90, a request showing a new account, a datacenter address and identical payloads scores 70 and gets a challenge; one showing all five scores 120 and is blocked.¹

Text description of the diagram

• Raw single addresses take 16 megabytes.
• A hash set of the same addresses takes 128 megabytes at 32 bytes per entry.

Raw single addresses take 16 megabytes. A hash set of the same addresses takes 128 megabytes at 32 bytes per entry (illustrative).

Trade-offs and edge cases

Every layer misses something, so a design that relies on one layer fails. A rate limit misses callers who spread requests over many addresses. A denylist misses new addresses and wrongly blocks shared ones. A risk score misses careful, low-volume abuse and can mislabel real users. An access check misses a stolen valid login.

Text description of the diagram

• A rate limit misses callers who spread requests over many addresses.
• An access check misses a stolen valid login.

An access check misses a stolen valid login, which is why the risk score and the audit log watch behavior after login too.

Edge cases to name aloud. Fail open or fail closed: if the denylist node cannot load its list, serving everyone risks abuse while refusing everyone causes an outage; many systems keep the last good list and alert. Stale lists: a node may run an old version for seconds, so deny decisions are eventually consistent, and access revocation needs the stronger consistency Zanzibar addresses.

Wrong blocks: expire entries, prefer a challenge over a block for borderline scores, and keep an appeal path. Placement: check the denylist at the edge, but run the access check close to the data, because it needs the resource's current permissions. For how clients see these decisions, see API design interview questions; if the list outgrows one node's memory, shard it with consistent hashing.

How to answer it in an interview

The spoken structure: name the four layers in order, say what each misses, then give the shared-address trade-off. Mention a number from your estimate if the interviewer asks about scale.

Common mistakes

• "A rate limiter stops abuse." (wrong) It misses callers spread over many addresses. (right) "A rate limit is one layer; I add a risk score from behavior and identity signals."
• "I'll block the bad IPs." (wrong) Shared addresses cause false positives and attackers rotate. (right) "I deny known-bad addresses at the edge, expire entries and challenge borderline cases."
• "Authentication and authorization are the same check." (wrong) One proves identity, the other grants rights. (right) "I authenticate first, then a decision point authorizes each action."
• "Unauthorized and forbidden mean the same." (wrong) They answer different questions: RFC 9110 defines 401 (Unauthorized) as missing or invalid authentication credentials and 403 (Forbidden) as a refusal to fulfil an understood request (sections 15.5.2 and 15.5.4). (right) "A 401 means I do not know who you are; a 403 means I know and the answer is no."
• "The list update is instant everywhere." (wrong) Nodes see it at different times. (right) "A push tree reaches every node in seconds, and I design for a stale node."

Follow-up questions

What concrete signals would you use beyond basic rate limiting?

Use identity signals such as account age and verification, network signals such as address type, device and browser traits, and behavior signals such as repeated payloads, bursts and failed-login ratios. OWASP describes device fingerprinting and human detection as mitigations for abuse of business flows.

How would you flag people trying to trick the system?

Combine the signals into a risk score, send borderline scores to a challenge, and log everything. Review the log for patterns across accounts, such as many sign-ups sharing a device trait, and add confirmed abusers to the denylist.

How would you deny requests from banned IP addresses listed by an outside authority?

Validate and version the list centrally, push it through a tree to every edge node, and swap it in atomically so a node never serves a half-loaded list. Lookups use a hash set plus range matching, and a stale node keeps its last good version.

How would you build a simple version of identity and access management?

Store users, roles and resources, authenticate with a token, and route every action through one decision function that returns allow or deny, with each decision logged. Start with roles; add attributes or relationships when roles stop being enough. The backend interview questions cover token handling.

How would you use a given malicious-request detection service?

Call it synchronously after the denylist and limiter, so it only sees the survivors, with a short timeout. If it is slow or down, fail closed on sensitive endpoints such as login and posting, fail open on read-only ones, and alert. Cache verdicts per caller for a short time, sample low-risk traffic if the call is costly, and log every verdict for Step 4.

How would you design a cloud security and compliance monitoring system?

Collect the audit logs and configuration state from every service, evaluate them against written rules, and alert on violations. It is the fourth layer of this design grown into a product: logs in, policy checks over them, findings out.

Sources

1. OWASP API Security Top 10, API4: Unrestricted Resource Consumption (2023 edition) — OWASP, 1 Jun 2023
2. OWASP API Security Top 10, API6: Unrestricted Access to Sensitive Business Flows (2023 edition) — OWASP, 1 Jun 2023
3. OWASP Automated Threats to Web Applications project — OWASP, 26 Oct 2026
4. RFC 6585: Additional HTTP Status Codes — IETF, 1 Apr 2012
5. RFC 9110: HTTP Semantics — IETF, 1 Jun 2022
6. Zanzibar: Google's Consistent, Global Authorization System (USENIX ATC 2019) — Google Research, 1 Jul 2019
7. NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations — NIST, 1 Aug 2019