Design Web Application Firewall

Problem Statement and WAF Placement

Define a multi-tenant L7 Web Application Firewall that inspects HTTP/HTTPS before origin, blocks OWASP-class attacks, and emits auditable security telemetry without breaking legitimate API traffic.

Where the WAF sits and what it must not break

A WAF is an inline L7 reverse proxy on the request path: it terminates (or inspects) HTTP/HTTPS before the request reaches the origin, applies a rule set, and decides allow / block / challenge / log. Placement is the first decision — inline blocking (can stop attacks, but adds latency and can take the site down if it misfires) versus out-of-band mirror (zero risk to traffic, but can only alert, not block). Production WAFs (Cloudflare, AWS WAF, Akamai, F5, ModSecurity) run inline and live or die on one number: the false-positive rate, because a WAF that blocks legitimate checkout traffic is a worse outage than the attack it prevents.

That tension — catch attacks vs never block real users — is the spine of the design, and it drives everything: a shadow/count-only mode to test rules before enforcing, per-endpoint allowlists for high-value flows, and a control-plane/data-plane split so a rule edit cannot stall the hot path. Anchor on real scale: ~2.5M requests/sec inspected, p99 inspection under ~8ms (you are in everyone's latency budget), block rate ~0.4%, and a false-positive budget under 0.01%.

Interview checkpoint

Open by placing the WAF (inline L7 reverse proxy, before origin) and naming the defining tension: catch OWASP attacks without blocking real users, measured as a sub-0.01% false-positive SLO. Then the levers that resolve it — shadow mode, per-endpoint allowlists, control/data-plane split — and the latency budget (p99 < 8ms) that forbids heavy per-request work.