Katkat
Back

Design an IP Address Filtering Service

RemitlySoftware Engineer · Onsite
EasySoftware EngineerOnsiteSystem Design

Last updated

Design a low-latency service that allows or denies traffic using source or destination IP rules. Candidates must define conflict precedence, address normalization, versioned rollout, stale-state behavior, audit evidence, privacy-conscious logging, and safe rollback.

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.

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.

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.

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.

Hints

Hint 1

Decide the winning rule before choosing a tree: Longest prefix, explicit priority, and deny-overrides can produce different outcomes for the same overlapping rules.

Hint 2

Keep authoring separate from serving: Operators need an auditable rule model, while the hot path needs a validated, compact representation it can swap atomically.

Hint 3

Version every decision context: A decision log is only explainable if it records which exact rule snapshot the enforcement point used.

Hint 4

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.

Follow-up questions

  • How would you represent an arbitrary range that is not one CIDR block?
  • How quickly could an emergency deny rule reach every region, and how would you prove it?
  • What changes if enforcement must happen in the kernel or at an edge proxy?
  • How would you detect a rule that unexpectedly blocks a large customer network?