# Design a Multi-Region Malicious-IP Detection System Design a service that detects malicious source IP addresses from application and network events and makes low-latency allow, challenge, rate-limit, or block decisions. Then extend it across multiple data centers. Address features, event ingestion, online state, rule and model rollout, false positives, shared intelligence, regional failures, privacy, and auditability. ### Constraints & Assumptions - Traffic volume is high and attackers rotate addresses or use shared proxies. - Each data center must continue making decisions during inter-region isolation. - A false positive can block many legitimate users behind one NAT. - Some signals are local and immediate; others require cross-region aggregation. - Lists, rules, and models change frequently and need rollback. ### Clarifying Questions to Ask - Which abuse outcome is being detected and how quickly do labels arrive? - What decision latency and false-positive budget apply? - Are IPv6 prefixes, authenticated account identity, and device signals available? - Which data may cross regions and how long may it be retained? ### What a Strong Answer Covers - Layered exact rules, rate features, reputation, and behavior rather than IP alone - Durable event streaming with windowed, deduplicated feature aggregation - A low-latency regional decision path and versioned policy distribution - Asynchronous cross-region intelligence with conflict and expiry semantics - Appeals, explainability, fail-safe degradation, and monitoring ### Follow-up Questions 1. How would you avoid blocking an entire university behind one public address? 2. What happens when two regions assign conflicting reputations? 3. How would you respond to an attacker rotating through IPv6 addresses? ```hint Keep the serving path regional Replicate compact, versioned intelligence asynchronously, but let each data center retain enough local state and policy to operate safely while disconnected. ```