Design a web application firewall: system design interview question

How the interviewer opens it

“Design a web application firewall that inspects HTTP traffic and blocks attacks such as SQL injection and cross-site scripting. The service must apply rule changes quickly and add little request latency.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Traffic scale
Read and write mix
HTTP and TLS
Latency
Rule behavior
Update consistency and durability
Availability and stale rules
Inspection limits
Events and privacy
Security scope

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Inspect HTTP requests with shared rules and tenant rules
Block requests that match active attack rules
Apply approved rule changes within a fixed time
Record rule decisions without raw request data

Usually out of scope

Network-layer DDoS protection
Response body inspection
WebSocket messages and gRPC messages
File content inspection
Automatic discovery of new attack classes
Application code fixes and browser security controls

What interviewers ask about

Rule update deadlines: A shared change affects every tenant. Missed updates leave attack paths open, while partial updates can create rules that no operator approved.
What the request means: An attacker can exploit differences between the firewall's interpretation and the origin's interpretation. Partial inspection can hide an attack.
Latency during an attack: Attackers control request content and volume. One expensive rule can consume the CPU that all tenants need.
Effects on customer traffic: An approved rule can still block valid requests. Rapid updates can spread that damage to every tenant.

Common mistakes

The design sends every request to a central rule service.
The design permits requests after partial inspection or a parser failure.
The rule engine permits unbounded work on attacker-controlled input.
The design pins tenant policies to shared versions without a timely path for shared changes.
The update path cannot prove enforcement or bound stale approval confirmations.
The design claims that request filters prevent every SQL injection or cross-site scripting attack.

The bar by level

Senior (L5/E5): Defines shared activation semantics and meets the update deadline for affected tenants. Handles parser ambiguity, regex cost, and false positives. Verifies enforcement without delaying requests.
Staff (L6+/E6+): Proves approval durability and the stale-rule bound across partitions, delayed confirmations, clocks, and recovery. A single quorum-backed authority with fixed-expiry grants suffices. Justifies fleet capacity, shared update cost, and tenant isolation.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a web application firewall
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a web application firewall that inspects HTTP traffic and blocks attacks such as SQL injection and cross-site scripting. The service must apply rule changes quickly and add little request latency.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Inspect HTTP requests with shared rules and tenant rules
Block requests that match active attack rules
Apply approved rule changes within a fixed time
Record rule decisions without raw request data

Usually out of scope

Network-layer DDoS protection
Response body inspection
WebSocket messages and gRPC messages
File content inspection
Automatic discovery of new attack classes
Application code fixes and browser security controls

What interviewers ask about

Rule update deadlines

A shared change affects every tenant. Missed updates leave attack paths open, while partial updates can create rules that no operator approved.

What the request means

An attacker can exploit differences between the firewall's interpretation and the origin's interpretation. Partial inspection can hide an attack.

Latency during an attack

Attackers control request content and volume. One expensive rule can consume the CPU that all tenants need.

Effects on customer traffic

An approved rule can still block valid requests. Rapid updates can spread that damage to every tenant.

Common mistakes

The design sends every request to a central rule service.

The design permits requests after partial inspection or a parser failure.

The rule engine permits unbounded work on attacker-controlled input.

The design pins tenant policies to shared versions without a timely path for shared changes.

The update path cannot prove enforcement or bound stale approval confirmations.

The design claims that request filters prevent every SQL injection or cross-site scripting attack.

The bar by level

Senior (L5/E5)

Defines shared activation semantics and meets the update deadline for affected tenants. Handles parser ambiguity, regex cost, and false positives. Verifies enforcement without delaying requests.

Staff (L6+/E6+)

Proves approval durability and the stale-rule bound across partitions, delayed confirmations, clocks, and recovery. A single quorum-backed authority with fixed-expiry grants suffices. Justifies fleet capacity, shared update cost, and tenant isolation.