You need an HAProxy frontend to answer 429 to any client IP that exceeds 100 requests in 10 seconds. Walk through the `stick-table`, `http-request track-sc0` and `http-request deny` lines required, and explain what order they must appear in and why.

## The configuration ``` frontend fe_public bind :80 stick-table type ip size 100k expire 10m store http_req_rate(10s) http-request track-sc0 src http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 } default_backend app ``` The pieces: - **The table** holds one entry per source address with a request rate averaged over ten seconds. Because it is declared in this frontend, rules here use it implicitly; a rule in another section would need `table fe_public`. - **`track-sc0 src`** binds *sticky counter zero* for this connection to the entry keyed by the source address. Tracking is what creates the entry and what makes each request increment `http_req_cnt` and feed `http_req_rate`. HAProxy provides several sticky counter slots, `sc0`, `sc1`, `sc2` and beyond, so you can track more than one key at once — for example the address in `sc0` and an API key header in `sc1`. - **`sc_http_req_rate(0)`** reads the request rate from whatever counter zero is tracking. The `(0)` is the counter slot, not a period. ## Why the order is not negotiable `http-request` rules run in file order for each request. If the deny sits above the track, the fetch resolves against a counter that is not bound to anything and returns zero, so the condition is never true and the rule silently does nothing. This is the single most common way a rate limit is written and never fires. The symptom is indistinguishable from a threshold that is too high, which is why reading rule order is the first diagnostic step. A related subtlety: `track-sc0` is ignored if counter zero is already tracking something on that connection. A second `track-sc0` further down — perhaps one keying on a header — does not replace the first. Use a different slot instead. ## What the counter actually measures `http_req_rate` is a moving average over the declared period, computed from the current and previous interval rather than a precise count in a fixed bucket. That means a threshold behaves approximately: a very short burst can pass under a limit that a sustained equivalent load would trip. If you need a ceiling on concurrency rather than rate, `conn_cur` is the data type to store, and if you want to count something the built-ins do not cover, increment a general-purpose counter with `http-request sc-inc-gpc0(0)` and test `sc_gpc0(0)`. In HTTP mode every request is counted, including successive requests on one keep-alive connection — which is correct for a request-rate limit, and worth stating explicitly because candidates often assume the counter is per connection. ## Choosing the key `src` is the source address of the TCP connection as HAProxy sees it. That is right when HAProxy is the edge. It is wrong the moment something sits in front: - **Behind a CDN or another proxy** every request appears to come from a handful of addresses. One entry accumulates the whole site's traffic, crosses the threshold in seconds, and the deny rule takes the site down for everyone. The fix is to key on the forwarded client address — for example `http-request track-sc0 req.hdr_ip(X-Forwarded-For)` — but only where that header is set by infrastructure you control and cannot be supplied by the client, otherwise anyone can rotate the header and escape the limit entirely. If HAProxy receives the PROXY protocol from the upstream, `src` is already the real client and no header is involved. - **Behind NAT or CGNAT** many genuine users share one address, so a per-IP limit throttles a whole office. Per-account keys — an API key or authenticated user id from a header — are fairer where they exist. ## The response `http-request deny` returns 403 by default; `deny_status 429` is what a throttled client should receive so its own retry logic can react. Denying at the frontend means the request never reaches a backend, which is the point: the work is refused before it costs a connection to an application server. There are gentler alternatives once you have the counter. A `use_backend` on a slow or reduced backend degrades rather than blocks, and setting a header instead of denying lets you run the rule in observation mode first, watching what would have been rejected before you turn it on. Rolling out a new limit that way is what separates a limit that protects the service from one that pages you at 3am about your own biggest customer.