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

Practice

1. Which of the following is a primary goal of DDoS protection strategies?

easy

A. Keep the service available during attack

B. Increase the number of incoming requests

C. Slow down legitimate user traffic

D. Disable firewalls to allow all traffic

Solution

1. Step 1: Understand the purpose of DDoS protection

   DDoS protection aims to prevent attacks from making a service unavailable by handling malicious traffic.

2. Step 2: Evaluate each option against this purpose

   Increasing requests or slowing legitimate traffic harms availability. Disabling firewalls reduces security. Only keeping service available matches the goal.

3. Final Answer:

   Keep the service available during attack -> Option A

4. Quick Check:

   DDoS protection = Keep service available [OK]

Hint: DDoS protection means keeping service up, not blocking all traffic [OK]

Common Mistakes:

• Confusing DDoS protection with traffic blocking
• Thinking DDoS protection increases traffic
• Assuming firewalls should be disabled during attacks

2. Which component is commonly used to distribute incoming traffic and help mitigate DDoS attacks?

easy

A. Load balancer

B. Cache server

C. Database server

D. Application server

Solution

1. Step 1: Identify components that manage traffic

   Load balancers distribute incoming requests across multiple servers to prevent overload.

2. Step 2: Match component to DDoS mitigation role

   Load balancers help absorb and spread traffic, reducing attack impact. Other options do not distribute traffic.

3. Final Answer:

   Load balancer -> Option A

4. Quick Check:

   Traffic distribution = Load balancer [OK]

Hint: Load balancers spread traffic to avoid overload [OK]

Common Mistakes:

• Confusing cache or database servers as traffic distributors
• Thinking application servers handle traffic distribution
• Ignoring the role of load balancers in DDoS defense

3. Consider a system using a CDN and a firewall with rate limiting. Which of the following best describes the request flow during a DDoS attack?

medium

A. Requests go directly to the origin server, bypassing CDN and firewall

B. CDN absorbs traffic, firewall filters requests, then origin server processes allowed requests

C. Firewall blocks all requests, CDN caches nothing

D. Origin server handles all requests before CDN and firewall

Solution

1. Step 1: Understand CDN and firewall roles

   CDNs cache content and absorb traffic near users. Firewalls filter malicious requests before reaching origin.

2. Step 2: Trace request flow during attack

   Requests first hit CDN, which reduces load. Firewall then filters suspicious traffic. Only allowed requests reach origin server.

3. Final Answer:

   CDN absorbs traffic, firewall filters requests, then origin server processes allowed requests -> Option B

4. Quick Check:

   Request flow = CDN -> Firewall -> Origin [OK]

Hint: Traffic flows CDN -> Firewall -> Origin server during attack [OK]

Common Mistakes:

• Assuming requests bypass CDN or firewall
• Thinking firewall blocks all requests indiscriminately
• Believing origin server handles all traffic first

4. A system uses IP blacklisting to block attackers, but legitimate users are still affected. What is the likely issue?

medium

A. Firewall is disabled

B. Blacklist is empty, no IPs blocked

C. Blacklist is too broad, blocking shared IPs

D. System does not log blocked IPs

Solution

1. Step 1: Analyze impact of IP blacklisting

   Blacklisting blocks specific IPs. If too broad, it may block IPs shared by many users.

2. Step 2: Identify why legitimate users are affected

   Blocking shared IPs causes collateral damage to good users. Other options do not explain this effect.

3. Final Answer:

   Blacklist is too broad, blocking shared IPs -> Option C

4. Quick Check:

   Legitimate users blocked = Broad blacklist [OK]

Hint: Too broad blacklist blocks good users too [OK]

Common Mistakes:

• Assuming empty blacklist blocks users
• Ignoring shared IP usage in blacklisting
• Thinking firewall status causes this issue

5. You design a DDoS protection system combining CDN, rate limiting, and real-time traffic analysis. Which approach best balances user experience and attack mitigation?

hard

A. Apply strict rate limits globally, blocking many users during spikes

B. Allow all traffic and rely on origin server capacity

C. Disable CDN and rely only on manual IP blocking

D. Use CDN to absorb traffic, apply adaptive rate limits based on analysis, and alert admins on anomalies

Solution

1. Step 1: Evaluate each strategy's impact on users and attack defense

   Strict global limits block many users, hurting experience. Disabling CDN or manual blocking is slow and risky.

2. Step 2: Identify balanced approach

   Using CDN to absorb traffic reduces load. Adaptive rate limits adjust to traffic patterns, minimizing false blocks. Real-time alerts enable quick response.

3. Final Answer:

   Use CDN to absorb traffic, apply adaptive rate limits based on analysis, and alert admins on anomalies -> Option D

4. Quick Check:

   Balanced DDoS defense = CDN + adaptive limits + alerts [OK]

Hint: Combine CDN, adaptive limits, and alerts for best balance [OK]

Common Mistakes:

• Applying strict limits without adaptation
• Ignoring CDN benefits
• Relying only on manual blocking or server capacity