Edge Rate Limiting for Storefront APIs Without Blocking Real Shoppers
Put rate limits at the edge, per route and per identity signal, not as one global cap. Checkout and account endpoints get tight limits tied to sessions, while catalog reads get generous ones. The edge can shed abusive traffic in milliseconds, so the origin only ever sees a load it can actually serve.
Every storefront API call that reaches your origin costs the same whether it comes from a shopper or a script. During a credential stuffing run or a price scraping flood, that means your servers spend the morning serving machines while real customers wait in line behind them.
Rate limiting is the standard answer, and the standard failure is a blunt one: one threshold for everything, applied at the origin, discovered by real shoppers during your biggest sale. Done at the edge with per route limits, it becomes invisible to buyers and very visible to abuse.
Limit by route, not by store
A product page read and a login attempt are not the same risk. Catalog and search endpoints tolerate high request rates from one address because shared networks and price comparison tools look exactly like that. Login, password reset, gift card balance, and checkout endpoints are where abuse concentrates, and they should carry limits an order of magnitude tighter.
Write the limits from your own traffic data. Take the 99th percentile of legitimate requests per minute for each route, then set the ceiling modestly above it. Limits guessed from a template either leak abuse or clip real demand, and both errors show up as lost revenue.
Identity beats IP address
Raw IP limits punish offices, campuses, and mobile carriers that put thousands of people behind one address. Layer signals instead: session cookies, device fingerprints the edge already computes, and account identity for logged in routes. A single IP making requests across fifty fresh sessions reads very differently from fifty shoppers sharing one NAT address.
Challenge before you block. When a source crosses a soft threshold, serve a proof of work or a managed challenge rather than an error page. Bots burn budget solving challenges at scale; a human solves one in a second and never thinks about it again. Reserve hard blocks for repeat offenders and known bad networks.
Tune it like a product, not a firewall
Log every limit hit with the route and the signals that triggered it, and review the false positive rate weekly. A limit that fires during a marketing email send is not protecting the store, it is taxing it. Treat each false positive as a bug with a revenue cost attached.
Rehearse the big days. Before a planned sale, replay last year peak traffic against the current limits in a staging pass, and raise sale day ceilings deliberately rather than discovering them in production. Rate limiting should be at its most permissive exactly when the store is at its most valuable, with the challenge layer carrying the extra load.
Related reading
Readers working through this topic often find these earlier guides useful as well: How Edge Personalization Works Without Slowing the Storefront Down, Edge Observability: Seeing Storefront Errors Where They Actually Happen, and Cutting Checkout API Latency With Edge Proxies and Connection Reuse.
Frequently asked questions
Will rate limiting slow down my real customers?
Properly set limits never touch normal shopping behavior, because legitimate use sits far below the ceilings. Customers only encounter anything when traffic patterns look automated, and a quick challenge resolves it. The slowdowns shoppers actually feel usually come from unfiltered bot load, which limiting removes.
Should rate limits live at the edge or the origin?
At the edge, where abusive traffic can be dropped before it consumes origin capacity. Origin limits still matter as a backstop, but by the time traffic reaches the origin the expensive part, connection handling and compute, is already being spent.
How do I know if my limits are too strict?
Watch the challenge and block logs against conversion on the same routes. If blocked sessions include completed orders or long browsing histories, the limit is catching humans. Weekly review of a sample of blocked sessions is the fastest way to calibrate.
Do rate limits help with checkout bots specifically?
Yes, checkout and inventory endpoints are prime bot targets during limited releases. Tight per session limits plus challenge escalation on those routes keep automated buyers from sweeping stock while leaving normal checkout untouched.