Two HAProxy nodes sit behind a round-robin DNS record and each enforces a per-source-IP request limit using its own stick table. What goes wrong, and what does adding an HAProxy `peers` section change?

## Why two nodes are two worlds A stick table lives in one HAProxy process's memory. Nothing about the traffic being load-balanced across nodes makes those tables converge. The consequences show up differently depending on what the table is for: - **Rate limiting.** Each node sees roughly half the client's traffic and counts only that half. Your threshold is effectively multiplied by the node count. Worse, it is multiplied unevenly — a client that happens to pin to one node hits the real limit, while one spread across both never does. - **Stickiness.** An entry created on node A does not exist on node B. When a client's next connection resolves to B, no entry matches, the balance algorithm runs, and the client can land on a different server mid-session. If the application keeps session state locally, that reads to the user as being logged out at random. - **Blocklists.** A client marked abusive on one node is unknown on the other, so half the abusive traffic sails through. ## The peers section ``` peers lb_cluster peer lb1 10.0.0.1:10000 peer lb2 10.0.0.2:10000 frontend fe_public bind :80 stick-table type ip size 100k expire 10m store http_req_rate(10s) peers lb_cluster http-request track-sc0 src http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 } ``` The same block is deployed to both nodes. Each connects to the others and pushes entry updates as they happen; a node that joins pulls the current contents from its peers so it does not start blind. Newer HAProxy versions also let you declare the tables inside the `peers` section itself, which keeps a shared table definition in one place. ## Which peer am I? HAProxy works out which `peer` line refers to itself by matching the node's hostname, which can be overridden on the command line with `-L`. This is the classic operational trap: deploy an identical config to a host whose hostname matches none of the peer names and the node quietly participates in nothing. It starts, it serves traffic, its table simply never syncs. Verifying that each node knows its local peer identity belongs in the deploy check, not in the incident review. The table definitions must also agree across peers — same type, same stored data types — or updates cannot be applied on the receiving side. ## What replication does and does not guarantee The peers protocol is asynchronous replication over a TCP connection between nodes. It is not a quorum, not a lock service, and not a transaction. Practically: - **There is a propagation delay.** A burst arriving simultaneously on both nodes can push both past the threshold before either learns about the other's increments. For rate limiting that is acceptable — you are shaping abuse, not enforcing a billing quota. For anything that must be exact, a proxy-local table is the wrong tool. - **A partition splits the state.** Each side keeps counting on its own and reconverges afterwards; there is no fencing and no elected owner. - **Counters merge by update, not by arithmetic.** Do not reason about the result as though the two nodes' request counts were being summed into an exact global figure. ## The reload benefit The same mechanism carries tables across a configuration reload: the outgoing process transfers its stick tables to the incoming one, so accumulated rates, pins and blocklist entries survive rather than resetting to empty. On a fleet that reloads on every config change, that difference is the gap between a limit that works continuously and one that is reset several times a day. ## The design alternative worth naming Before reaching for replication, ask whether the state needs to be shared at all. Cookie-based persistence carries the routing decision in the client's request, so any node can honour it with no table and no peers — which is why it scales across a proxy fleet more gracefully than `stick on src`. Replication is unavoidable for counters, since a counter is inherently server-side state, but it is often avoidable for persistence. And if the requirement is a genuinely exact, globally consistent quota across nodes, that belongs in a shared store designed for it rather than in the proxy's in-memory table.