1Context and scope
A service with a load balancer, an API and a database. Halfway through, a flood of 20,000 requests a second arrives for 15 seconds. Nothing in the design can tell attackers from users, so the flood takes the capacity real users need.
2Goals and non-goals
Goals
- 1,500 real users a second.
- Keep success at least 98%, block at least 95% of the attack, and keep attack traffic out of the database.
Non-goals
- Attacks that use valid accounts (credential stuffing, fraud): authentication and fraud checks handle those.
- Floods that bypass the edge: lock the origin so it only accepts traffic from the edge.
- Fixing bugs in the application itself (the WAF only filters known attack patterns).
3Capacity estimate
Back-of-the-envelope numbers from the template. The simulation uses the same ones, so you can check them against a run.
| Quantity | Value | How |
|---|---|---|
| Real users | 1,500/s | |
| Attack | 20,000/s for 15 s | 13× the real traffic |
| Attack that gets through at 98% blocking | 400/s | still a quarter of real traffic |
4The design
Each component in the template, in the order a request meets it, and why it is there.
- DDoS protection
Absorbs volumetric floods at the network edge, before they reach you.
- WAF
Inspects HTTP requests and blocks known-bad patterns, scraping and credential stuffing.
- Bot management
Scores clients by behaviour and fingerprint to stop automated traffic that looks almost human.
- Load balancer, API, Postgres
The system being protected. It was sized for users, not for attackers.
5Key concepts
Defence in depth
Each layer stops a different kind of attack: floods at the edge, malicious requests at the WAF, automation at the bot manager. No single filter covers all of them.
Block rates are never 100%
At 98% blocking, 2% of a 20,000 req/s flood still arrives: 400 req/s. Design so what leaks through cannot hurt the data layer (rate limits, capacity headroom).
False positives
Every filter blocks some real users. Tight rules stop more attacks and more customers; tune them in log-only mode first and challenge instead of blocking where possible.
Graceful degradation
Keep the service usable even when some attack gets through: shed low-priority work, protect the database, keep core paths fast.
6Alternatives considered
- Stricter filters block more attack and more real users.
- Full bot management can cost as much as the rest of the edge.
7Failure modes and fixes
What goes wrong in the simulation, why, and the change that fixes it. Each one shows up as a finding in the lab; ask “what broke?” to see it, and for the fix when you want it.
Real users fail and attack traffic reaches Postgres.
WhyWith no filter in front, the flood competes with users for API slots and database connections.
FixPut DDoS protection, a WAF and bot management in front of the load balancer.
8Try it in the lab
Open the template, then type these into the copilot one at a time. The first few are also offered as buttons when the template opens.
add ddos protectionThe flood is stopped at the edge; compare success before and after.
add a wafCovers credential stuffing and scraping.
add bot managementCovers automated bots.
stress testRuns a DDoS, bot and credential-stuffing drill against your defences.
9Check yourself
- Why is a single WAF not enough against a volumetric DDoS?
- If 1% of a 50,000 req/s attack gets through, how does that compare with 1,500 real users?
- How would you tune a filter to keep false positives low?