DDoS Protection Basics: How Caching and Rate Limiting Absorb Attacks

Introduction

A distributed denial-of-service (DDoS) attack tries to knock your site offline by burying it in more traffic or work than it can handle. You don't need an exotic, expensive appliance to defend against the majority of them — two of the most effective tools are ones you probably already have reasons to want: caching and rate limiting. This guide explains what DDoS attacks actually are, and how caching, rate limiting, and a few related techniques absorb them.

What a DDoS attack is

"Denial of service" simply means making a service unavailable to its legitimate users. The "distributed" part means the attack comes from many sources at once — often a botnet of thousands of compromised devices — which makes it hard to just block one address. Attacks fall into a few broad layers:

Type	What it targets	Example
Volumetric	Your bandwidth — flood the pipe so real traffic can't get through.	UDP floods, DNS/NTP amplification.
Protocol	Server and network resources like connection tables.	SYN floods, Ping of Death.
Application (Layer 7)	Your application — expensive requests that look almost legitimate.	HTTP floods hammering a search or login endpoint.

Layer 7 attacks are the trickiest because each request can look like a real one; the harm is in the volume and in targeting your most expensive operations. This is exactly where caching and rate limiting earn their keep.

How caching absorbs an attack

The core insight: a request answered from cache never reaches your origin. If an attacker floods you with requests for your homepage and that page is cached at the edge, the edge answers all of them from memory. Your application servers, your database, and your origin bandwidth see almost none of it. A cached response costs a memory lookup and a write to a socket — orders of magnitude cheaper than generating the page — so the edge can serve a flood of identical requests without breaking a sweat.

Caching is most effective against attacks when:

• Your cache-hit ratio is high. The more traffic you serve from cache in normal times, the more of an attack it deflects. A site that caches aggressively has a huge head start.
• The attack targets cacheable content. Floods of your public pages, images, and assets are absorbed almost entirely at the edge.
• The edge is distributed. Spreading cache nodes across many locations both raises capacity and dilutes a volumetric attack across many points of presence instead of one origin.

Caching's limit is dynamic, uncacheable requests — a login POST, a personalised dashboard, a search with a unique query. Those still reach the origin, which is where the second tool comes in.

How rate limiting caps the damage

Rate limiting restricts how many requests a single client can make in a window of time. Against the uncacheable requests that caching can't help with, it puts a ceiling on how much load any one source can generate. An attacker's individual bots get throttled to a trickle, and the expensive endpoints they're trying to overwhelm stay responsive for everyone else.

Rate limiting is most useful when you:

• Protect expensive endpoints specifically. Login, search, and anything hitting the database benefit most from tight limits.
• Key on something meaningful. Per-IP is the common default; behind another proxy you key on the real client from a trusted forwarded header, or an attacker just rotates the header to escape.
• Return a proper 429 with Retry-After. Legitimate clients back off; abusive ones are simply denied.

Its limit is the flip side of caching's: a truly distributed attack spreads across so many source IPs that each stays under a per-IP cap. That's why layering matters — no single technique is complete.

Defence in depth

Real protection stacks several layers so that whatever one technique misses, the next one catches:

• Edge caching deflects the large share of traffic aimed at cacheable content.
• Rate limiting caps what any single source can do to the uncacheable remainder.
• A Web Application Firewall (WAF) filters out obviously malicious requests — known-bad patterns, injection attempts, abusive user agents and bots — before they cost you anything.
• Waiting rooms handle the opposite problem: a genuine flash crowd. Instead of collapsing under a legitimate surge, you queue visitors and admit them at a rate your origin can sustain, keeping the site up for everyone.
• A distributed edge spreads both capacity and attack traffic across many locations, so no single origin is the chokepoint.
• Network-layer scrubbing upstream handles the raw volumetric and protocol floods that never should reach your application at all.

The pattern is the same one that runs through good security generally: no single wall, but several, each covering the gaps in the others.

Practical steps for most sites

• Put a caching reverse proxy or CDN in front of your origin and cache as much as you safely can.
• Set sensible per-client rate limits, tightest on your most expensive endpoints.
• Never expose your origin's real IP directly — route everything through the edge so attackers can't bypass it.
• Enable a WAF to filter known-bad traffic and abusive bots.
• Have a plan for legitimate surges (a waiting room) so success doesn't look like an attack and take you down.
• Monitor traffic so you can see an attack starting and respond deliberately.

Conclusion

You don't defend against DDoS attacks with one magic switch — you defend with layers, and the two most accessible layers are caching and rate limiting. Caching absorbs the flood of cacheable requests before they ever reach your origin; rate limiting caps what any single source can do to what's left. Add a WAF, waiting rooms for genuine surges, and a distributed edge, and most application-layer attacks become a non-event. ARC2 Proxy brings these together — per-domain caching, rate limiting, a WAF, and Cloudflare-style waiting rooms — so the same infrastructure that makes your site fast also keeps it standing when someone tries to take it down.