DDoS protection and abusive traffic

Defending a service against denial-of-service attacks: volumetric, protocol and application-layer attacks, absorbing traffic with anycast and CDNs, scrubbing, web application firewalls, rate limits and challenges, protecting origins, autoscaling cost traps, and designing APIs that are cheap to reject.

Reading is half of it. See this used in a real interview: walk through Design a Rate Limiter →

A distributed denial-of-service (DDoS) attack floods a service with traffic from many sources until real users cannot get through. Attacks range from terabits per second of junk packets to modest numbers of expensive, legitimate-looking requests aimed at a slow endpoint. Interviewers ask about it for public-facing systems (URL shorteners, ticketing, APIs), usually as "what if someone floods this?". The answer is layered: absorb at the edge, filter, rate-limit, and make expensive work hard to trigger.

Kinds of attacks

Application-layer attacks are the hardest, because each request looks valid.

Absorb at the edge

• Anycast networks and CDNs spread attack traffic across hundreds of locations with enormous combined capacity, so no single site is overwhelmed. See global traffic management.
• Scrubbing services filter malicious packets before they reach your network.
• TLS termination at the edge means handshake floods hit the provider, not your servers.
• Cache everything cacheable: cached responses cost the origin nothing, even under attack. See CDN and edge.

Protect the origin

• Accept traffic only from the CDN or load balancer (allowlist their IPs, or use authenticated origin pulls); keep origin IPs private. Attackers who find the origin bypass every edge defence.
• Separate public, partner and internal endpoints onto different entry points.

Filter and rate-limit

• Web application firewall (WAF) rules block known bad patterns, abusive user agents and suspicious geographies during an attack.
• Rate limits per IP, per network, per API key and per account, at the edge where possible. See rate limiting algorithms.
• Bot detection and challenges (JavaScript challenges, proof-of-work, CAPTCHAs) for suspicious clients, rather than blocking outright.
• Reputation: known botnets, data-centre ranges and proxies get stricter limits.

Make work expensive to request

Application attacks target costly operations. Reduce the cost or the access:

• Require authentication for expensive endpoints (search, exports, code execution).
• Validate and reject cheaply before doing work: size limits, schema checks, early auth.
• Cap query complexity (page sizes, GraphQL depth), and make deep pagination require cursors. See pagination.
• Put heavy work behind queues with per-tenant limits, so floods back up in a queue instead of crushing databases. See load shedding and backpressure.
• Timeouts against slow-request attacks that hold connections open.

For code execution platforms, sandbox limits and per-user quotas double as DDoS protection. See Design LeetCode.

Autoscaling is not a defence by itself

Scaling up to serve attack traffic costs money ("denial of wallet") and still fails if a shared dependency (the database) saturates. Cap autoscaling, shed load at the edge, and rely on cheap rejection. See autoscaling.

During an attack

• Detect via traffic anomalies at the edge and saturation in services.
• Switch to stricter modes: tighter rate limits, challenges for all anonymous traffic, serve stale cache, disable non-essential expensive features with flags.
• Prioritise known-good traffic (logged-in users, paying customers, API keys with history).
• Communicate status; review afterwards. See incident response.

Designing for it

• Public, unauthenticated, cacheable read paths (like URL redirects) should be served from the edge. See Design a URL Shortener.
• High-demand events (ticket drops) need waiting rooms that also absorb bot floods. See Design Ticketmaster.
• Rate limiting is a core component, not an afterthought. See Design a Rate Limiter.

In the interview

"All traffic enters through an anycast CDN with a WAF; the origin only accepts CDN traffic. Redirects are cached at the edge, so floods hit cache. Per-IP and per-key rate limits apply at the edge, with JavaScript challenges for suspicious clients. Expensive endpoints require auth and run through queues with per-tenant limits; autoscaling is capped so an attack cannot run up unlimited cost."

Checklist

• Volumetric and protocol attacks absorbed by anycast CDN and scrubbing.
• Origin hidden and locked to edge traffic.
• WAF, rate limits, reputation and challenges at the edge.
• Expensive operations authenticated, validated early, queued and capped.
• Capped autoscaling; cheap rejection over scaling.
• Attack-mode switches and prioritised good traffic.