DDoS protection strategies in HLD - System Design Exercise

Design: DDoS Protection System

In scope: Real-time detection, traffic filtering, rate limiting, IP reputation checks, analytics dashboard. Out of scope: Application code changes, upstream ISP filtering.

Functional Requirements

FR1: Detect and mitigate Distributed Denial of Service (DDoS) attacks in real-time

FR2: Handle up to 1 million requests per second during attack peaks

FR3: Minimize false positives to avoid blocking legitimate users

FR4: Provide detailed attack analytics and reporting

FR5: Integrate with existing web applications and APIs

FR6: Ensure system availability of 99.9% uptime

Non-Functional Requirements

NFR1: Latency impact on legitimate traffic must be less than 50ms

NFR2: System must scale horizontally to handle traffic spikes

NFR3: Mitigation actions must be automated with manual override option

NFR4: Support for multiple attack vectors: volumetric, protocol, and application layer attacks

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Traffic monitoring and anomaly detection module

Rate limiting and throttling engine

IP reputation and blacklist service

Web Application Firewall (WAF)

Load balancers and CDN integration

Alerting and analytics dashboard

Design Patterns

Rate limiting and token bucket algorithm

Traffic scrubbing and filtering

Blacklisting and whitelisting

Behavioral anomaly detection

Fail-open vs fail-closed strategies

Distributed mitigation using edge nodes

Reference Architecture

  Internet Users
       |
       v
  +-------------+      +-----------------+      +----------------+
  |  CDN/Edge   | ---> | Traffic Monitor | ---> | Rate Limiter   |
  |  Network    |      | & Anomaly Detect|      | & IP Reputation|
  +-------------+      +-----------------+      +----------------+
       |                      |                        |
       v                      v                        v
  +---------------------------------------------------------------+
  |                      Load Balancer                            |
  +---------------------------------------------------------------+
                               |
                               v
                      +-----------------+
                      |  Web App Server |
                      +-----------------+
                               |
                               v
                      +-----------------+
                      | Analytics &     |
                      | Alerting System |
                      +-----------------+

Components

CDN/Edge Network

Cloudflare, Akamai, AWS CloudFront

Absorb and filter large volumes of traffic close to users to reduce load on origin servers

Traffic Monitor & Anomaly Detection

Custom or third-party monitoring tools with ML-based anomaly detection

Analyze incoming traffic patterns to detect unusual spikes or attack signatures

Rate Limiter & IP Reputation Service

Redis-based token bucket algorithm, IP reputation databases

Throttle excessive requests and block known malicious IPs

Load Balancer

Nginx, HAProxy, AWS ELB

Distribute traffic evenly to backend servers and provide failover

Web Application Firewall (WAF)

ModSecurity, AWS WAF

Filter malicious HTTP requests and protect against application layer attacks

Analytics & Alerting System

Elastic Stack, Prometheus, Grafana

Provide real-time dashboards and alerts for attack detection and mitigation status

Request Flow

1. User sends request which first hits the CDN/Edge network.

2. CDN filters out known bad traffic and caches content to reduce load.

3. Filtered traffic is forwarded to Traffic Monitor which analyzes request patterns.

4. If anomalies are detected, Traffic Monitor signals Rate Limiter to throttle or block suspicious IPs.

5. Rate Limiter applies token bucket algorithm and consults IP reputation service to decide blocking.

6. Legitimate traffic passes through Load Balancer to Web Application Firewall.

7. WAF inspects requests for application layer attacks and blocks malicious payloads.

8. Clean traffic reaches the web application servers.

9. Analytics system collects logs and metrics from all components and triggers alerts if attack thresholds are exceeded.

Database Schema

Entities: - IPAddress (ip, reputation_score, last_seen) - TrafficLog (timestamp, ip, request_path, response_code, bytes_sent) - AnomalyEvent (event_id, detected_at, description, severity) - RateLimitRule (rule_id, ip_range, limit_per_minute, action) - Alert (alert_id, event_id, created_at, status) Relationships: - TrafficLog references IPAddress by ip - AnomalyEvent linked to multiple TrafficLogs - Alert linked to AnomalyEvent - RateLimitRules applied to IPAddress ranges

Scaling Discussion

Bottlenecks

Traffic Monitor overwhelmed by high volume during large attacks

Rate Limiter latency increases with large IP sets

WAF becomes a bottleneck under heavy application layer attacks

Analytics system struggles to process and store large logs in real-time

Solutions

Distribute Traffic Monitor across multiple edge locations with local detection

Use sharded Redis clusters for Rate Limiter to handle large IP sets efficiently

Deploy WAF in a scalable cluster with autoscaling and caching of rules

Implement log sampling and use scalable big data storage like Kafka + Hadoop for analytics

Interview Tips

Time: Spend first 10 minutes clarifying requirements and constraints, next 20 minutes designing architecture and data flow, last 15 minutes discussing scaling and trade-offs.

Emphasize importance of early traffic filtering at CDN/edge to reduce load

Discuss trade-offs between automated mitigation and false positives

Explain how rate limiting algorithms work and their impact on user experience

Highlight need for multi-layer defense: network, transport, application

Address scalability challenges and how to handle large attack volumes

Mention monitoring and alerting as critical for operational awareness