# DDoS protection > DDoS protection keeps a service usable when many sources deliberately exhaust its bandwidth, connections, or application resources. In system design, the key is rejecting harmful traffic before it consumes the scarce resource, not simply adding servers or putting a rate limiter in front of the database. Source: https://sysround.com/concepts/ddos-protection Updated: 2026-11-05 ## How ddos protection works Identify what an attacker can exhaust. Volumetric attacks fill network links, protocol attacks consume connection state, and application-layer attacks trigger expensive work such as password hashing or database searches. Measure bandwidth, packets per second, concurrent connections, request rates, and backend cost separately. Stop network floods upstream. A DDoS mitigation provider can filter traffic before it reaches your network; an anycast edge spreads incoming traffic across multiple locations, though it does not provide unlimited capacity. If your internet link is already saturated, an application-level rate limiter behind that link cannot restore availability. Put public HTTP traffic through a protected edge or reverse proxy. Terminate connections there, enforce connection and request limits, and use a web application firewall or bot controls to filter suspicious requests. Cache safe public responses so repeated reads do not reach the origin; bound cache misses because randomized URLs can defeat caching. Protect expensive application paths with layered admission control. Apply coarse limits before authentication, then account, tenant, and endpoint limits once identity is available. For example, constrain concurrent password checks separately from cheap session validation, and reject oversized requests before parsing them. IP limits alone are insufficient because attackers distribute requests and legitimate users may share an address. Prevent bypass and contain overload. Restrict origin access to the trusted edge using network rules and, where appropriate, authenticated connections; accept forwarded client addresses only from trusted proxies. Bound queues and concurrency, reserve capacity for critical operations, and shed excess work before dependencies collapse. Keep request-path enforcement fast rather than making every edge request depend on one global counter. Operate mitigation as a feedback loop. Watch edge rejection rates alongside origin saturation, latency, successful legitimate requests, and cost. Adjust rules carefully, use challenges only for suitable clients, and define what happens when the filtering or rate-limit service fails. Test both attacks and legitimate traffic spikes because high volume alone does not prove abuse. ## Worked example: Protecting an expensive login endpoint Suppose a login service has 40 CPU cores available for password verification, and each check consumes 100 milliseconds of CPU time. Its theoretical ceiling is about 400 checks per second, before overhead or safety margin. A botnet sends 20,000 login requests per second from rotating IP addresses. Upstream mitigation handles network floods; the protected edge applies bot controls and coarse request limits. The gateway adds account and source limits, while the application caps concurrent password checks to stay within a load-tested budget below that ceiling. Cheap session validation uses a separate resource pool. Requests exceeding admission limits are rejected before hashing, and origin access is restricted to the edge. Monitor legitimate login success as well as rejection counts. ## Trade-offs - **Protection versus false positives.** Aggressive IP blocks, bot rules, and challenges reduce attack traffic but can exclude shared-network users, automated clients, or people with accessibility needs. - **Upstream protection versus cost and dependency.** A protected edge can absorb traffic your origin cannot, but adds provider dependency, configuration work, and potentially substantial traffic-processing costs. - **Precise global limits versus enforcement availability.** Globally coordinated counters improve quota precision but add latency and a dependency, while local limits or allocated regional budgets allow some overshoot. - **Fail open versus fail closed.** Allowing traffic when enforcement fails risks overload, while denying it risks an outage, so choose a policy per endpoint and retain bounded local safeguards. - **Caching versus origin exposure.** Caching protects repeatable reads but does little for uncacheable writes, personalized responses, or attacks that generate unique cache keys. - **Elasticity versus financial exposure.** Autoscaling can absorb legitimate bursts, but scaling without admission limits may turn an attack into a large bill without protecting constrained dependencies. ## When to use it in a system design interview - The design exposes public, unauthenticated endpoints whose traffic sources cannot be trusted. - A small request can trigger expensive work, such as password verification, search fan-out, or media processing. - The interviewer asks how the system remains available under hostile traffic rather than ordinary growth. - A flash sale or giveaway needs fair admission while bots compete with legitimate users. - Network bandwidth, open connections, or dependency capacity can be exhausted before application servers reach their CPU limit. ## How to bring it up in the interview - Start with the protected resource and availability goal: ask whether the threat is link saturation, connection exhaustion, or expensive application requests. - Draw the rejection points in order: upstream mitigation, protected edge, gateway admission, and backend concurrency limits; explain which resource each layer protects. - Separate abuse controls from capacity controls: bot detection estimates intent, while bounded admission protects the service even when intent is unknown. - Defend your identity and limit choices; expect probes about shared IP addresses, rotating bot addresses, compromised accounts, regional overshoot, and spoofed forwarding headers. - Explain bypass prevention and degraded operation; expect questions about direct origin access, enforcement outages, false positives, and how you verify that real users still succeed. ## Common mistakes - Calling an application rate limiter complete DDoS protection when traffic can saturate the network before reaching it. - Assuming a CDN automatically protects dynamic APIs or an origin that remains directly reachable. - Using only per-IP limits and ignoring distributed attackers, shared networks, and endpoint-specific resource costs. - Relying on autoscaling or an unbounded queue instead of rejecting work before scarce resources are consumed. - Applying browser challenges to every client or treating every legitimate flash crowd as an attack. ## Interview questions where it comes up - [Design a distributed rate limiter](https://sysround.com/questions/design-rate-limiter): Abuse mitigation makes limiter placement, distributed enforcement, and failure behavior central, while exposing why request quotas cannot stop upstream link saturation. - [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): Password verification under attack requires early filtering and bounded admission so hostile login traffic cannot exhaust authentication capacity. - [Design a flash giveaway: 6 million burgers in an hour](https://sysround.com/questions/design-flash-sale): The claim surge requires bot-aware admission and aggregate resource limits that preserve legitimate access without sending every request to inventory storage. ## FAQ ### What is the difference between DDoS protection and rate limiting? Rate limiting controls how much traffic a client, identity, or endpoint may send and is one part of DDoS protection. DDoS mitigation also covers upstream bandwidth protection, connection handling, traffic filtering, origin isolation, and resource-aware load shedding. ### Does a CDN prevent DDoS attacks? A CDN can absorb cacheable reads and may include network and application-layer mitigation, depending on the service. It does not automatically protect expensive dynamic requests or traffic sent directly to the origin. Verify the protection scope and prevent edge bypass. ### How do you mitigate a distributed application-layer DDoS attack? Combine edge filtering with limits across multiple signals, such as source, account, endpoint, and observed behavior. Bound expensive work with concurrency limits and reject excess requests before backend execution. Because distributed clients can stay below individual quotas, also enforce aggregate capacity budgets and monitor legitimate-user outcomes. ## Related concepts - [Rate limiting algorithms](https://sysround.com/concepts/rate-limiting-algorithms) - [Content delivery networks (CDN)](https://sysround.com/concepts/cdn) - [Load shedding](https://sysround.com/concepts/load-shedding) - [API gateway](https://sysround.com/concepts/api-gateway) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.