Hook & Stakes
Booking.com's global delivery network handles billions of requests daily. To prevent session data from wandering across Availability Zones, teams embraced locality-aware routing and per-AZ pools, forming the backbone of an LBaaS built on HAProxy 1 . The stakes are simple: keep users seamless and fast, or risk churn when sessions vanish mid-flight. This sets the stage for a deeper dive into session affinity and its price tag.
The Dilemma: Stateless vs Sticky Sessions
Session affinity (sticky sessions) ensures a user keeps hitting the same backend, preserving local session state. But this convenience comes at a cost: it can complicate scaling and lead to hot spots. In modern architectures, many teams weigh strict statelessness against the comfort of a locally stored session. Understanding this balance is the key to choosing the right recipe for a given service. See how patterns map to real systems and what trade-offs show up in practice 3 4 9 .
Implementation Playbook
Two common HAProxy approaches shine here: Source IP Hashing backend web_servers balance source server web1 192.168.1.10:80 check server web2 192.168.1.11:80 check server web3 192.168.1.12:80 check Stick Tables (Cookie-based) backend web_servers balance roundrobin stick-table type string len 32 size 30k expire 30m stick on cookie(JSESSIONID) server web1 192.168.1.10:80 check cookie web1 server web2 192.168.1.11:80 check cookie web2 server web3 192.168.1.12:80 check cookie web3 Both approaches offer HA and performance, but with different implications for scaling and state management 3 7 8 .
Real-World Proof
Booking.com's experience demonstrates a practical, scalable path: locality-aware routing helps keep users within an AZ, while a central control plane coordinates pools and failover. This mirrors lessons from large-scale operators who emphasize topology-aware persistence and careful failover, a pattern echoed by major system-design narratives and supported by industry references 11 9 .
Takeaways
Start with a topology-aware mindset: locality matters for latency and consistency. Choose a HAProxy pattern that aligns with your session needs (source hashing for speed, stick-tables for stateful sessions). Plan for failure: health checks, backups, and session replication where appropriate 4 5 . Real-World Case Study Booking.com Booking.com scaled its global application delivery network using an internal LBaaS built around HAProxy to manage billions of requests per day. To avoid session data issues across multiple availability zones, they implemented smart routing that tends to keep a user within a single AZ, leveraging per-AZ pools and a centralized Balancer API. Key Takeaway: Sticky sessions at scale can be achieved by locality-aware routing and per-AZ state management, but require a control plane (LBaaS) and careful planning to avoid cross-AZ data races and imbalance; true scale often involves shifting from pure stateless designs to topology-aware persistence with robust failover.
System Flow
graph TD; A(Client) --> B[HAProxy] B --> C[AZ-1 Pool] B --> D[AZ-2 Pool] C --> E[web1] C --> F[web2] D --> G[web3] Did you know? Some large-scale CDNs use per-AZ routing as a primary design principle to minimize cross-region latency. Key Takeaways Topology-aware routing matters for latency and consistency Choose between source hashing and stick-tables based on session needs Health checks and backups are essential for high availability References 1 Scaling the Edge: How Booking.com Powers a Global Application Delivery Network with HAProxy article 2 haproxy/haproxy repository 3 AWS Application Load Balancer sticky sessions documentation 4 Kubernetes: Load balancing overview documentation 5 HTTP Cookies - MDN documentation 6 RFC 6265: HTTP State Management Mechanism documentation 7 Load Balancing - Wikipedia documentation 8 ELB: What is Elastic Load Balancing? documentation 9 Netflix architecture and resilience documentation 10 Chaos Monkey (concept) documentation 11 HAProxy Advanced Patterns documentation Share This 🔥 Ever wondered how Booking.com keeps sessions sticky at global scale? Topology-aware routing can reduce cross-AZ data movement by keeping users local. Source IP hashing vs cookie-based sticks: choose based on your session needs. A robust control plane matters for failover and global consistency. Read the full journey to see how to apply these patterns in your own systems. #SoftwareEngineering #SystemDesign #TechCareers #BackendDevelopment #CloudComputing #DevOps #WebPerformance #LoadBalancing undefined function copySnippet(btn) { const snippet = document.getElementById('shareSnippet').innerText; navigator.clipboard.writeText(snippet).then(() => { btn.innerHTML = ' '; setTimeout(() => { btn.innerHTML = ' '; }, 2000); }); }
System Flow
Did you know? Some large-scale CDNs use per-AZ routing as a primary design principle to minimize cross-region latency.
References
- 1Scaling the Edge: How Booking.com Powers a Global Application Delivery Network with HAProxyarticle
- 2haproxy/haproxyrepository
- 3AWS Application Load Balancer sticky sessionsdocumentation
- 4Kubernetes: Load balancing overviewdocumentation
- 5HTTP Cookies - MDNdocumentation
- 6RFC 6265: HTTP State Management Mechanismdocumentation
- 7Load Balancing - Wikipediadocumentation
- 8ELB: What is Elastic Load Balancing?documentation
- 9Netflix architecture and resiliencedocumentation
- 10Chaos Monkey (concept)documentation
- 11HAProxy Advanced Patternsdocumentation
Wrapping Up
Sticky sessions can be powerful at scale when paired with locality-aware routing and a robust control plane. Start by mapping your topology, choose a HAProxy pattern that fits, and build in failover early.