## Design an IP Address Filtering Service Design a service that decides whether network requests should be allowed or denied based on source or destination IP addresses. Clarify where enforcement happens, which address families and rule forms are supported, how conflicting rules are resolved, and how quickly updates must propagate. ### Part 1 — Define Rule and Decision Semantics Specify exact addresses, CIDR prefixes or ranges, IPv4 and IPv6 normalization, allow and deny actions, priority, defaults, scope, expiration, and the decision API. #### What This Part Should Cover - Canonical binary address representation and validated prefixes. - Deterministic precedence for overlapping rules. - Tenant, application, direction, and environment scope where required. - A fail-open or fail-closed policy tied to the protected traffic. ```hint Decide the winning rule before choosing a tree Longest prefix, explicit priority, and deny-overrides can produce different outcomes for the same overlapping rules. ``` ### Part 2 — Store, Compile, and Evaluate Rules Design the control-plane store and the data-plane representation used for low-latency decisions. Compare exact-match maps, prefix tries, interval structures, and compiled rule snapshots. #### What This Part Should Cover - Durable versioned rules with author, reason, and lifecycle state. - A representation matched to exact addresses, CIDRs, or arbitrary ranges. - Immutable compiled snapshots and atomic activation. - Bounded per-request work without scanning every rule. ```hint Keep authoring separate from serving Operators need an auditable rule model, while the hot path needs a validated, compact representation it can swap atomically. ``` ### Part 3 — Distribute Updates and Handle Failure Propagate rule versions to enforcement points across regions. Explain consistency, rollback, cache behavior, disconnected agents, emergency blocks, and protection against unauthorized changes. #### What This Part Should Cover - Signed or authenticated snapshots and monotonic versions. - Acknowledged rollout status by region or enforcement point. - Last-known-good behavior and maximum tolerated staleness. - Staged rollout, rollback, and a narrowly controlled emergency path. ```hint Version every decision context A decision log is only explainable if it records which exact rule snapshot the enforcement point used. ``` ### Part 4 — Audit, Test, and Operate Design explainability, privacy-conscious logging, conflict analysis, testing, metrics, and safe rule cleanup. #### What This Part Should Cover - Winning rule ID and version without unnecessary payload logging. - Tests for boundaries, nested prefixes, address normalization, and defaults. - Shadow evaluation and diffing before promotion. - Metrics for decision latency, update lag, stale agents, and rule-hit anomalies. ```hint Test the address just outside the prefix Boundary cases reveal off-by-one range conversion and incorrect prefix masks that ordinary in-range tests miss. ``` ### What a Strong Answer Covers - Resolves ambiguous filter semantics and conflict precedence. - Separates auditable rule management from fast local enforcement. - Uses immutable versioned rollout with explicit stale-state behavior. - Supports explanation, rollback, security, and address-boundary testing. ### Follow-up Questions 1. How would you represent an arbitrary range that is not one CIDR block? 2. How quickly could an emergency deny rule reach every region, and how would you prove it? 3. What changes if enforcement must happen in the kernel or at an edge proxy? 4. How would you detect a rule that unexpectedly blocks a large customer network?