Automated traffic is 60% of your requests, distorting analytics and consuming capacity. Where do you handle it and how?

What the interviewer is testing

Whether you place the control at the right layer and recognise that not all automated traffic is unwanted.

Classify before blocking

Wanted: search engine crawlers, partner integrations, monitoring, your own synthetic checks, price comparison services you have agreements with.

Tolerable: aggressive scrapers, competitive price monitoring. Unwanted and not malicious.

Harmful: credential stuffing, scalping and inventory hoarding, card testing, scraping that saturates capacity.

Blocking indiscriminately removes search indexing and breaks partner integrations, which is a commercial incident.

Where to handle it

At the edge, before origin. The entire point is that the request never consumes origin capacity, so handling it in the application has already paid most of the cost. This is the strongest argument for an edge security layer.

The techniques, in order of cost to the user

Reputation and known-bot identification, which requires no user interaction.

Behavioural signals — request patterns, timing, navigation shape, header consistency. Effective and requires no friction.

Rate limiting by identity where available, falling back to IP with the knowledge that shared addresses penalise legitimate users.

Progressive challenges, escalating from invisible checks to interactive ones only for suspicious traffic. Every challenge shown to a legitimate user is friction, so the goal is to show as few as possible.

Blocking, reserved for high-confidence malicious traffic.

The analytics half

Classify and label rather than only blocking, so tolerated automated traffic is excluded from business metrics without being denied. Analytics distortion is often the more expensive problem, and it is solved by labelling rather than by blocking.

What a strong answer adds

Rate limits enforced independently at many edge locations are not the limit you specified — a limit of 100 enforced at fifty locations is 5,000. Anything with a hard cap needs either a much lower local limit or approximate global counting, and the design should state which limits are exact and which are approximate.

And measuring the intended effect: origin load, capacity cost and metric accuracy — not "bots blocked", which rewards over-blocking.

Common weak answers

Blocking by user agent, trivially spoofed. Handling it in the application, which pays the capacity cost you were trying to avoid.