Production Implementation Patterns: Cookie Based vs IP Based Affinity

Cookie-Based Affinity
Cookie-based affinity is the standard for Layer 7 (L7) HTTP/HTTPS load balancers. The load balancer injects a cookie on the first response that encodes: the selected backend identifier, an issued timestamp, expiry time, and a cryptographic signature to prevent tampering. The cookie travels with every subsequent request, allowing the load balancer to route deterministically without maintaining state in memory. This makes the load balancer itself stateless while providing per-request affinity decisions.
IP-Based Affinity
IP-based affinity is typical for Layer 4 (L4) network load balancers that operate below the HTTP layer. The load balancer hashes the client source IP address (and optionally port) to select a backend, then remembers this mapping for a configured duration. The advantage is protocol independence: it works for TCP, UDP, and any IP traffic without inspecting application-layer data. The severe limitation is that many clients share the same IP address behind carrier-grade NAT (CGNAT) or corporate proxies.
Why Cookies Are Generally Superior
Cookie-based affinity is generally superior for web applications because it: survives IP address changes (mobile devices switching between WiFi and cellular), provides per-user granularity instead of per-IP (critical when thousands share one IP), and allows the load balancer to remain stateless by encoding routing information in the cookie itself. The load balancer needs no memory of previous decisions; it reads the cookie and routes accordingly.
The CGNAT Problem
Carrier-grade NAT creates extreme hotspots with IP-based affinity. A mobile carrier with 100,000 subscribers might present only 2-5 public IP addresses. All traffic from those subscribers hashes to the same 2-5 backends, creating 20,000-50,000 RPS hotspots while other backends sit idle. Imbalance ratios of 3-5x are common in IP-based deployments serving mobile traffic.
Security Requirements for Cookies
Affinity cookies require strict security configuration: cryptographically signed with a rotated secret key (rotate every 24-48 hours), marked HttpOnly (no JavaScript access), marked Secure (HTTPS only), and SameSite=Lax or Strict to prevent cross-site request attacks. Cookies must be regenerated on authentication events to prevent session fixation attacks where an attacker sets the affinity marker before the victim logs in.
Key Insight: Both cookie and IP-based affinity break immediately on backend health check failures. When a server becomes unhealthy, clients are reassigned, losing session state unless checkpointed. Plan for this by writing critical state to shared storage within 2ms of state changes.

💡 Key Takeaways

✓Cookie affinity provides per-user granularity, survives IP changes, keeps load balancer stateless; standard for L7 HTTP

✓IP affinity works at L4 for any protocol but suffers CGNAT where 100K users share 2-5 IPs, creating 3-5x imbalance

✓Cookie security: cryptographic signature rotated 24-48h, HttpOnly, Secure, SameSite; regenerate on authentication

✓Both mechanisms break on backend failure; checkpoint critical state to shared store within 2ms to prevent loss

📌 Interview Tips

1Explain CGNAT hotspot: mobile carrier with 100K subscribers behind 2-5 public IPs, all hash to same backends

2Describe why cookies survive IP changes: mobile user switches WiFi to cellular, cookie maintains affinity to same backend

3List cookie security requirements: signed, HttpOnly, Secure, SameSite, regenerate on login/privilege escalation

← Back to Sticky Sessions Overview