Block Malicious IPs at an API Gateway Across Data Centers

Design malicious-IP blocking at an API gateway, then explain how you would extend the design across multiple data centers. ### Constraints The source of malicious-IP decisions, rule volume, request rate, and propagation target are unspecified. Treat detection and enforcement as separate concerns and clarify the policy before choosing defaults. An IP address can be shared by many users, so blocking accuracy and false positives matter. ### Clarifying Questions - Who creates or removes a block, and does a rule have an expiration or scope? - Are rules exact addresses, network ranges, or both, and do they include IPv6? - What propagation delay is acceptable for a new block or an urgent unblock? - What should a gateway do if the control plane is unavailable or its local rule set is stale? ```hint Keep request enforcement local Consider how a versioned local rule set can avoid a remote lookup for every request while still receiving reliable updates. ``` ### What a Strong Answer Covers - Rule identity, trusted client-IP extraction, policy provenance, and fast gateway checks. - Durable control-plane updates, local caching, expiration, and observability. - Multi-data-center replication, stale-state behavior, and safe block/unblock propagation. ### Follow-up Questions - How would you detect that one region missed an unblock event? - How would you limit harm from a faulty rule that blocks a shared network?