Enforce a Country's IP Ban List on Incoming Connections Using Its Lookup API

A country requires your service to refuse network connections from IP addresses it has banned. The country provides an API that, given an IP address, reports whether that address is banned. Design the system that enforces this across your whole fleet. The round is graded on two things beyond the design itself: whether you check your assumptions before building on them (for example, which IP versions are in scope, or how much infrastructure you have), and whether you drive the discussion, starting from a simple design and improving it step by step. ### Constraints and Clarifications - The country's lookup API is the source of truth, and you cannot change it. - A banned address must be refused when it tries to connect. - Nothing else is given: traffic volume, the API's behavior and limits, the size of your fleet and the freshness requirement must be asked for or stated as assumptions. ### Clarifying Questions - Is IPv6 in scope as well as IPv4? - Does the API only answer single-address lookups, or can it also return the full list or the changes since a given point? What are its rate limits, latency and availability? - Are bans individual addresses, or ranges such as CIDR prefixes? - How soon after a ban is added, or lifted, must enforcement reflect it? - Which traffic is covered: every inbound connection, or only users in that country, and over which protocols? - If the API is unreachable and an address has never been checked, does the country expect you to refuse it or to allow it? - Will you have to prove compliance later, for example with records of refused connections? ### Part 1 — Scope and a first design Pin down the scope and the requirements, then propose the simplest design that is compliant and explain where it breaks. ```hint Ask what the API can do Before scaling anything, find out whether the API can only answer one address at a time; the answer decides between caching lookups and mirroring the list. ``` #### What This Part Should Cover - Explicit scope decisions on IP versions, ranges and covered traffic, taken from questions rather than assumed - Functional and non-functional requirements, including freshness and behavior when a check cannot be made - A simple baseline and a clear account of its failure points: latency, rate limits, availability coupling ### Part 2 — Enforcement at scale Improve the design so every connection is checked quickly at your edge without calling the country's API each time. Cover where the check runs, which data structure holds the bans, and how ban data reaches every enforcement point. ```hint Ranges change the structure Think about which structure answers "is this address inside any banned range" in a bounded number of steps for both 32-bit and 128-bit addresses. ``` #### What This Part Should Cover - Placement of the check at the connection edge, against the real client address - A lookup structure that handles single addresses and prefixes for both IP versions - Distribution of versioned ban data to every node with atomic swaps - Memory and lookup cost estimates under stated assumptions ### Part 3 — Freshness, failure and proof Explain how new and lifted bans propagate within the freshness requirement, what happens to connections already open when an address becomes banned, how the system behaves when the country's API or your own sync pipeline fails, and how you demonstrate compliance. ```hint Two different unknowns Decide separately what you do with a list that may be stale and with an address you have never been able to check. ``` #### What This Part Should Cover - End-to-end propagation delay and how it is measured - Handling of existing long-lived connections - Fail-open versus fail-closed as an explicit, owner-approved policy - Audit records and alerting ### What a Strong Answer Covers - Asks about IPv4 versus IPv6, ranges and the API's capabilities before choosing a design - Labels every number as asked or assumed and never invents infrastructure counts - Iterates from a baseline to a scalable design, tying each change to the problem it fixes - Keeps the per-connection check local, bounded and fast - Treats compliance failure modes and auditability as first-class requirements ### Follow-up Questions - A second country introduces its own ban list with a different API. What generalizes and what does not? - The country bans a large IPv6 prefix that covers some of your own infrastructure or a major mobile carrier. How do you detect and handle it? - How would you test the system end to end without banning real users? - Clients reach you through a CDN or proxy. Which address do you check, and how do you know you can trust it?