Design an IP Block Check Against a Government API With a 7-Day Grace Period

Design the access check for a service that may only be provided to clients whose IP address is not blocked by a government policy. **Functional requirements** 1. An external API operated by the government answers whether a given IP address is blocked. The service is provided to a request only if its IP is not blocked. 2. When the government updates its IP blocking policy, there is a grace period of 7 days in which the service may update its own policy to match. **Non-functional requirements** - Scalability: 10k queries per second. - Reliability. ```hint What the grace period buys Think about how long an earlier answer from the government API can be trusted, given 7 days to catch up with a policy change, and what that means for how often the API must be called. ``` ```hint The external API is the weak link Plan for it being slower and less available than your own systems. Decide what happens to a request from an IP that has never been checked while the API is unreachable. ``` ### Constraints and Clarifications - Given: the government API reports whether an IP is blocked; only non-blocked IPs are served; there are 7 days to adopt a policy change; 10k QPS; the system must be reliable. - Not given: the API's latency, rate limits and availability; whether it offers a bulk list or change notifications; whether blocks cover single addresses or ranges; whether IPv6 is in scope; what to do when an IP's status cannot be determined. Ask, or state assumptions. ### Clarifying Questions - Does the government API answer only per-IP queries, or can the full blocklist, or the changes since a version, be downloaded? - Does the API say when the policy last changed, or publish a policy version? - What are its rate limits, latency and availability, and does it charge per call? - Are blocks expressed as single addresses or as ranges (CIDR blocks), and is IPv6 in scope? - Is 10k QPS the request rate to our service, and how many distinct client IPs do we see per day? - When an IP's status is unknown and the API cannot be reached, should the request be denied or allowed? - Must every request be checked, or only the start of a session (login or connection setup)? ### What a Strong Answer Covers - Uses the 7-day grace period to bound how long a verdict may be cached, instead of calling the external API on every request - A fast decision path at 10k QPS: an in-process cache, a shared verdict store, and the API only on a miss - A refresh strategy that re-checks every cached verdict well within the grace period while staying under the API's limits - An explicit, agreed behavior for unknown IPs when the API is slow or down, and protection against bursts of calls to it - Range and IPv6 handling if in scope, and an audit trail of what each decision was based on - Reliability across zones, monitoring of verdict age, and alerts before the grace period is at risk ### Follow-up Questions - The government starts publishing a daily file with the full blocklist. How does your design change? - The API goes down for two days. What happens to IPs you already know, and to new ones? - A new block covers a whole /16 range. How does your cache handle it? - An auditor asks why a given IP was served on a given day. What can you show?