System Design (HLD)Session Persistence (Sticky Sessions)

Session Persistence (Sticky Sessions)

LevelIntermediate

Duration55 mins

TopicSession Persistence (Sticky Sessions)

2 / 5

Cookie-Based Session Persistence

The Cookie as Traffic Director

When a user visits your application for the first time, they're just an anonymous HTTP request arriving at your load balancer. But once they've been routed to a specific backend server, how do you ensure all their subsequent requests return to that same server?

The answer, in most production systems, is a small piece of data traveling with every request: the persistence cookie.

Cookies—originally designed by Netscape in 1994 for shopping cart persistence (ironically enough)—have become the most reliable and widely-used mechanism for session affinity in load-balanced environments. A persistence cookie carries just enough information for the load balancer to route requests consistently, without requiring any client-side cooperation beyond the browser's built-in cookie handling.

This page explores cookie-based persistence in exhaustive depth: how load balancers inject and read these cookies, the security implications you must address, configuration options across major platforms, and the subtle edge cases that can break your implementation in production.

What You Will Learn

By the end of this page, you will understand the mechanics of cookie-based persistence at both the protocol and implementation level. You'll know how to configure it on major load balancers, secure it against common attacks, and troubleshoot issues when cookies aren't behaving as expected.

How Cookie-Based Persistence Works

Cookie-based persistence operates through a simple but elegant mechanism. The load balancer acts as an intermediary, injecting tracking information into the HTTP response and reading it from subsequent requests.

The Complete Flow:

Converting Mermaid diagram...

Step-by-Step Breakdown:

1. Initial Request Arrives:

Client sends HTTP request without persistence cookie
Load balancer applies normal selection algorithm (round-robin, least-connections, etc.)
Selected server processes request and generates response

2. Cookie Injection (Response Path):

Load balancer intercepts the response before sending to client
Injects Set-Cookie header with persistence information
Cookie value encodes enough information to identify the server

3. Subsequent Requests:

Browser automatically includes cookie in requests to same domain
Load balancer reads cookie, extracts server identifier
Routes directly to identified server (bypassing selection algorithm)

4. Cookie Lifecycle:

Cookie persists according to its attributes (session vs. persistent)
Expired or missing cookies fall back to normal selection
Server pool changes may invalidate stale cookies

Load Balancer-Managed vs. Application-Managed

This page focuses on load balancer-managed cookies where the LB injects and reads cookies without application involvement. An alternative is application-managed persistence where the application sets a session cookie (like JSESSIONID) that the LB reads. Both approaches work; LB-managed is simpler but less flexible.

Cookie Content and Encoding Strategies

What exactly goes inside the persistence cookie? Different load balancers take different approaches, each with tradeoffs:

Strategy 1: Server Identifier (Direct Reference)

The cookie contains a direct identifier for the backend server:

Set-Cookie: SERVERID=backend_server_1_192.168.1.10; Path=/

Pros: Simple, easy to debug, human-readable Cons: Exposes internal infrastructure, less secure, breaks if server names change

Strategy 2: Hashed/Encrypted Identifier

Server identity is encrypted or hashed:

Set-Cookie: SERVERID=a8f9d2e1c3b4; Path=/

Pros: Hides internal details, can include expiry/signature Cons: More complex, requires shared secret, harder to debug

Strategy 3: Pool Index

Cookie contains server's position in the pool:

Set-Cookie: SERVERID=3; Path=/

Pros: Minimal data, easy rotation Cons: Breaks if pool order changes, limited metadata

Strategy 4: Session + Server Binding

Associates a random session ID with a server in the LB's memory:

Set-Cookie: AWSALB=abc123def456; Path=/

The LB maintains internal mapping: abc123def456 → backend_server_3

Pros: No internal exposure, can persist mapping across server changes Cons: Requires LB state, memory overhead, scaling considerations

Cookie Encoding Comparison
Strategy	Cookie Size	Security	Debugging	Resilience to Changes
Direct Reference	Large (server names)	Low (exposes internals)	Easy	Low
Hashed/Encrypted	Medium (hash length)	High	Moderate	Moderate
Pool Index	Tiny (just a number)	Medium	Easy	Low
Session Binding	Medium (random ID)	High	Requires LB access	High

Production Recommendation:

Modern load balancers typically use session binding (like AWS ALB's AWSALB cookie) or encrypted identifiers. Direct server references should be avoided in production due to security exposure.

Example Cookie Values from Real Load Balancers:

Load Balancer	Cookie Name	Example Value
AWS ALB	AWSALB / AWSALBCORS	`Tn2YbGg0z1bE1+xA9K3...` (base64-encoded)
HAProxy	SERVERID	`s1` or `srv1~12345`
NGINX Plus	srv_id	`a1b2c3d4e5f6`
F5 BIG-IP	BIGipServer~pool	`rd3o00000000000000...` (encrypted)
Cloudflare LB	`__cflb`	Complex encoded value

Cookie Tampering Risks

If cookies contain unencrypted server identifiers, malicious users could tamper with them to target specific servers—potentially for attack reconnaissance or to bypass security controls. Always use signed or encrypted cookie values in production.

Cookie Attributes and Their Implications

HTTP cookies support multiple attributes that control their behavior. Each attribute has implications for session persistence:

1. Domain Attribute:

Set-Cookie: SERVERID=abc; Domain=.example.com

Controls which domains receive the cookie:

Omitting Domain: Cookie sent only to exact host that set it
Domain=.example.com: Cookie sent to example.com and all subdomains

Persistence Implication: If your load balancer serves multiple subdomains (api.example.com, www.example.com) from the same pool, set Domain appropriately so persistence works across subdomains.

2. Path Attribute:

Set-Cookie: SERVERID=abc; Path=/app

Restricts cookie to specific URL paths:

Path=/: Cookie sent for all paths (most common)
Path=/app: Cookie sent only for /app/* routes

Persistence Implication: Almost always use Path=/ for persistence cookies. Path-restricted cookies can break persistence when users navigate between app sections.

3. Expires / Max-Age:

Set-Cookie: SERVERID=abc; Max-Age=3600
Set-Cookie: SERVERID=abc; Expires=Wed, 09 Jun 2025 10:18:14 GMT

Omitting both: Session cookie (deleted when browser closes)
Max-Age=3600: Expires in 3600 seconds
Expires=<date>: Expires at specific date/time

Persistence Implication: Session cookies are appropriate when persistence should match browser sessions. Persistent cookies with Max-Age survive browser restarts—useful for keeping cart contents but potentially surprising for security-sensitive sessions.

4. Secure Attribute:

Set-Cookie: SERVERID=abc; Secure

Cookie only sent over HTTPS connections.

Persistence Implication: Always use Secure for production. Without it, persistence cookies leak to unencrypted connections, exposing server identities and enabling session hijacking.

5. HttpOnly Attribute:

Set-Cookie: SERVERID=abc; HttpOnly

Cookie inaccessible to JavaScript (document.cookie).

Persistence Implication: Always use HttpOnly for persistence cookies. There's no legitimate reason for client JavaScript to access server routing cookies, and HttpOnly prevents XSS from exfiltrating them.

6. SameSite Attribute:

Set-Cookie: SERVERID=abc; SameSite=Lax
Set-Cookie: SERVERID=abc; SameSite=Strict
Set-Cookie: SERVERID=abc; SameSite=None; Secure

Controls cross-site cookie behavior:

Strict: Cookie only sent for same-site requests
Lax: Sent for same-site + top-level GET navigations (default in modern browsers)
None + Secure: Sent for cross-site requests (requires Secure)

Persistence Implication: Lax is usually appropriate. Strict can break persistence when users arrive via external links. None is needed for cross-origin API scenarios but increases security exposure.

Complete Cookie Example

HTTP Header

# Production-grade persistence cookie
Set-Cookie: SERVERID=encrypted_value_here; Path=/; Domain=.example.com; Max-Age=3600; Secure; HttpOnly; SameSite=Lax
 
# Breakdown:
# SERVERID=encrypted_value_here  - Server identifier (encrypted)
# Path=/                          - Valid for all paths
# Domain=.example.com             - Works across subdomains
# Max-Age=3600                    - Expires in 1 hour
# Secure                          - HTTPS only
# HttpOnly                        - No JavaScript access
# SameSite=Lax                    - Reasonable cross-site protection

Modern Browser Defaults

As of 2024, Chrome and other browsers default SameSite to 'Lax' if not specified, and require 'Secure' for 'SameSite=None'. This helps security but can break legacy configurations. Always explicitly set SameSite to avoid browser-dependent behavior.

Load Balancer Configuration Deep Dive

Let's examine cookie-based persistence configuration across major load balancing platforms. Understanding these implementations helps you make informed choices and troubleshoot issues.

NGINX Open Source doesn't include built-in cookie persistence—this is an NGINX Plus feature. Open source alternatives include using ip_hash or third-party modules.

NGINX Plus offers the sticky directive with cookie persistence:

nginx.conf
NGINX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
upstream backend {
    # Enable sticky cookie persistence
    sticky cookie srv_id expires=1h domain=.example.com httponly secure path=/;
    
    # Backend servers
    server 10.0.0.1:8080 weight=1;
    server 10.0.0.2:8080 weight=1;
    server 10.0.0.3:8080 weight=1;
}
 
server {
    listen 443 ssl;
    server_name example.com;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
 
# Alternative: sticky route (using existing cookies)
upstream backend_route {
    sticky route $cookie_jsessionid;
    
    server 10.0.0.1:8080 route=a;
    server 10.0.0.2:8080 route=b;
}

Key Options:

expires: Cookie lifetime (e.g., 1h, 24h)
domain: Cookie domain attribute
httponly: Add HttpOnly flag
secure: Add Secure flag
path: Cookie path (default: /)

Security Considerations

Cookie-based persistence introduces security surface area that must be carefully managed. Let's examine the threat model and mitigations:

Security Threats

•Infrastructure Reconnaissance: Predictable or unencrypted cookie values reveal backend server names, IPs, or pool structures. Attackers use this information to map your infrastructure before targeted attacks.
•Session Fixation: If attackers can set or predict persistence cookies before user authentication, they might force users onto specific servers they've compromised or are monitoring.
•Cookie Theft via XSS: Without HttpOnly, JavaScript-based attacks (XSS) can steal persistence cookies, learning which servers users are routed to.
•Cookie Interception (MITM): Without Secure flag, cookies transmit over unencrypted connections, exposing routing information to network attackers.
•Cookie Tampering: If cookies aren't signed/encrypted, attackers can modify them to target specific servers—useful for concentrating attacks or avoiding detection.
•Denial of Service via Cookie Manipulation: Attackers might flood a specific backend by manipulating cookies to consistently target that server, bypassing load balancing protections.

Security Best Practices

•Always Encrypt Cookie Values: Use encrypted or cryptographically-signed cookie values. Never expose raw server identifiers, IPs, or internal names.
•Set Secure Flag: Persistence cookies must only transmit over HTTPS. Period. This isn't optional in production.
•Set HttpOnly Flag: There's no legitimate reason for client JavaScript to read persistence cookies. Block access unconditionally.
•Use SameSite Appropriately: Start with SameSite=Lax. Only use None if cross-origin requests truly require persistence, and understand the CSRF implications.
•Implement Cookie Rotation: Don't let persistence cookies live forever. Rotate them periodically (e.g., every few hours) to limit the window for stolen cookies.
•Validate Cookie Integrity: Load balancers should validate that cookies haven't been tampered with. Signed cookies prevent modification.
•Rate Limit by Cookie: If you detect unusual patterns (many requests with same cookie from different IPs), investigate potential cookie theft.
•Log Cookie Changes: When users establish new sessions or get re-routed, log these events for forensic analysis.

The Privacy-Security Balance

GDPR and similar regulations classify some tracking cookies as requiring consent. While persistence cookies are generally considered 'essential' (not requiring consent), their exact classification depends on implementation. Consult privacy counsel if you're unsure about compliance in your jurisdiction.

Edge Cases and Troubleshooting

Cookie-based persistence can fail in subtle ways. Here are common issues and their resolutions:

Problem 1: Persistence Not Working at All

Symptoms: Users bounce between servers despite cookie configuration.

Potential Causes:

Cookie domain mismatch (cookie set for api.example.com, user on www.example.com)
Browser rejecting third-party cookies (if using iframe embed)
Missing SameSite/Secure for modern browsers
Load balancer not configured correctly for all routes
Health check failures causing server rotation

Debugging Steps:

Check browser DevTools → Application → Cookies
Verify Set-Cookie header in network response
Confirm cookie sent with subsequent requests
Check load balancer logs for routing decisions

Problem 2: Cookie Works But Persistence Is Intermittent

Symptoms: Sometimes requests hit the right server, sometimes not.

Potential Causes:

Multiple load balancers without shared state
CDN stripping cookies on certain paths
Some requests (static assets) bypass persistence
Cookie expiring too quickly
Browser incognito mode not persisting cookies

Debugging Steps:

Trace full request path (CDN → LB → origin)
Check if all request types include cookies
Verify cookie TTL matches expected session length

Problem 3: Cookie Conflicts

Symptoms: Application behaves erratically, multiple cookies present.

Potential Causes:

Multiple load balancers setting same-named cookie
Application and LB both setting persistence cookies
Cookie scope (domain/path) overlaps incorrectly
Migration leaving old cookies in place

Debugging Steps:

List all cookies for domain (DevTools)
Identify duplicate/conflicting names
Trace which component sets each cookie
Clear cookies and test clean session

Problem 4: Server Pool Changes Break Sessions

Symptoms: After deployments or scaling, users lose their sessions.

Potential Causes:

Cookie references server no longer in pool
Server index changed when pool resized
Encrypted cookie uses key that rotated
New servers have different identifiers

Mitigation Strategies:

Use session-binding (LB maintains mapping table)
Graceful draining before removing servers
Consistent server identifiers across deployments
Cookie fallback to normal load balancing on invalid value

Debug Header Injection

Many load balancers can inject debug headers showing routing decisions. For example, HAProxy can add X-Backend: server1 to responses, Traefik can inject X-Traefik-Route. Enable these in staging to understand routing behavior without checking LB logs.

Advanced Cookie Persistence Patterns

Beyond basic cookie persistence, advanced patterns address specific architectural needs:

Pattern 1: Cookie Chaining (Multi-Tier Persistence)

In multi-tier architectures, you might need persistence at multiple levels:

Client → CDN → Global LB → Regional LB → Application Server

Each tier can set its own persistence cookie:

CDN: Route to consistent edge location
Global LB: Route to consistent region
Regional LB: Route to consistent server

Implementation: Use distinct cookie names at each tier (X-Edge, X-Region, X-Server).

Pattern 2: Weighted Persistence (A/B Testing)

During gradual rollouts, you want users to stick to their assigned variant:

First request: LB assigns to variant (90% old, 10% new)
Cookie encodes variant assignment
Subsequent requests route to same variant

Implementation: Cookie contains both variant and server within variant.

Pattern 3: Persistence with Fallback Pools

When primary servers are unavailable, route to backup pool while maintaining eventual consistency:

Normal: Route to primary (Cookie: primary_server1)
Primary fails: Route to backup (Cookie updated: backup_server5)
Primary recovers: Optionally migrate back

Implementation: Time-bounded cookies allow natural migration back.

Pattern 4: Shard-Aware Persistence

When data is sharded across servers, route users to the shard holding their data:

First request: LB examines user ID header
Hash user ID to determine shard
Set cookie encoding shard assignment
Subsequent requests route via cookie

Implementation: Cookie contains shard identifier, not server. LB maps shard to current server.

Pattern 5: Canary Cookie Persistence

For canary deployments, selected users get routed to canary servers:

First request: LB selects small percentage for canary
Canary users get special cookie (CANARY=true)
All subsequent requests route to canary pool
Non-canary users never see canary

Implementation: Two-stage routing—first check canary cookie, then normal persistence.

Pattern 6: Signed Cookie with Metadata

Embed metadata in cookies for advanced routing decisions:

Cookie: STICKY=<base64(server|timestamp|signature)>

The timestamp enables:

Automatic cookie expiry
Forced refresh after configurable period
Migration windows during deployments

Complexity Warning

Advanced patterns increase operational complexity significantly. Each layer of persistence is another potential failure point, another thing to debug, another configuration to maintain. Adopt advanced patterns only when clearly needed, and document them extensively.

Summary: Cookie-Based Persistence Mastered

We've thoroughly explored cookie-based session persistence, from fundamental mechanics to advanced patterns. Let's consolidate:

Key Takeaways

•Cookie persistence is the most reliable method — It works across network changes, survives IP variation, and requires only standard browser cookie support.
•Cookie content should be encrypted or signed — Never expose internal server identifiers. Use session binding or encrypted tokens.
•Cookie attributes matter for security — Always set Secure, HttpOnly, and appropriate SameSite. Omitting these creates exploitable vulnerabilities.
•Load balancer configuration varies significantly — Each platform (NGINX, HAProxy, AWS, Envoy) has different approaches. Understand your specific platform.
•Edge cases are subtle but critical — Domain mismatches, cookie conflicts, and pool changes can silently break persistence. Monitor and test thoroughly.
•Advanced patterns enable sophisticated routing — Multi-tier persistence, A/B testing, and shard-aware routing are possible but increase complexity.

What's Next:

Cookies are the most common persistence mechanism, but not the only one. Next, we'll explore IP-based persistence—an approach that works without cookies but comes with significant limitations. Understanding both methods helps you choose the right approach for your specific requirements.

Cookie Persistence Complete

You now have comprehensive knowledge of cookie-based session persistence: how it works, how to configure it, how to secure it, and how to troubleshoot it. This is the foundation for effective session management in production load-balanced environments.

2 / 5

Loading learning content...

System Design (HLD)Session Persistence (Sticky Sessions)

Session Persistence (Sticky Sessions)

LevelIntermediate

Duration55 mins

TopicSession Persistence (Sticky Sessions)

2 / 5

Cookie-Based Session Persistence

The Cookie as Traffic Director

The answer, in most production systems, is a small piece of data traveling with every request: the persistence cookie.

What You Will Learn

How Cookie-Based Persistence Works

The Complete Flow:

Converting Mermaid diagram...

Step-by-Step Breakdown:

1. Initial Request Arrives:

Client sends HTTP request without persistence cookie
Load balancer applies normal selection algorithm (round-robin, least-connections, etc.)
Selected server processes request and generates response

2. Cookie Injection (Response Path):

Load balancer intercepts the response before sending to client
Injects Set-Cookie header with persistence information
Cookie value encodes enough information to identify the server

3. Subsequent Requests:

Browser automatically includes cookie in requests to same domain
Load balancer reads cookie, extracts server identifier
Routes directly to identified server (bypassing selection algorithm)

4. Cookie Lifecycle:

Cookie persists according to its attributes (session vs. persistent)
Expired or missing cookies fall back to normal selection
Server pool changes may invalidate stale cookies

Load Balancer-Managed vs. Application-Managed

Cookie Content and Encoding Strategies

What exactly goes inside the persistence cookie? Different load balancers take different approaches, each with tradeoffs:

Strategy 1: Server Identifier (Direct Reference)

The cookie contains a direct identifier for the backend server:

Set-Cookie: SERVERID=backend_server_1_192.168.1.10; Path=/

Pros: Simple, easy to debug, human-readable Cons: Exposes internal infrastructure, less secure, breaks if server names change

Strategy 2: Hashed/Encrypted Identifier

Server identity is encrypted or hashed:

Set-Cookie: SERVERID=a8f9d2e1c3b4; Path=/

Pros: Hides internal details, can include expiry/signature Cons: More complex, requires shared secret, harder to debug

Strategy 3: Pool Index

Cookie contains server's position in the pool:

Set-Cookie: SERVERID=3; Path=/

Pros: Minimal data, easy rotation Cons: Breaks if pool order changes, limited metadata

Strategy 4: Session + Server Binding

Associates a random session ID with a server in the LB's memory:

Set-Cookie: AWSALB=abc123def456; Path=/

The LB maintains internal mapping: abc123def456 → backend_server_3

Pros: No internal exposure, can persist mapping across server changes Cons: Requires LB state, memory overhead, scaling considerations

Cookie Encoding Comparison
Strategy	Cookie Size	Security	Debugging	Resilience to Changes
Direct Reference	Large (server names)	Low (exposes internals)	Easy	Low
Hashed/Encrypted	Medium (hash length)	High	Moderate	Moderate
Pool Index	Tiny (just a number)	Medium	Easy	Low
Session Binding	Medium (random ID)	High	Requires LB access	High

Production Recommendation:

Modern load balancers typically use session binding (like AWS ALB's AWSALB cookie) or encrypted identifiers. Direct server references should be avoided in production due to security exposure.

Example Cookie Values from Real Load Balancers:

Load Balancer	Cookie Name	Example Value
AWS ALB	AWSALB / AWSALBCORS	`Tn2YbGg0z1bE1+xA9K3...` (base64-encoded)
HAProxy	SERVERID	`s1` or `srv1~12345`
NGINX Plus	srv_id	`a1b2c3d4e5f6`
F5 BIG-IP	BIGipServer~pool	`rd3o00000000000000...` (encrypted)
Cloudflare LB	`__cflb`	Complex encoded value

Cookie Tampering Risks

Cookie Attributes and Their Implications

HTTP cookies support multiple attributes that control their behavior. Each attribute has implications for session persistence:

1. Domain Attribute:

Set-Cookie: SERVERID=abc; Domain=.example.com

Controls which domains receive the cookie:

Omitting Domain: Cookie sent only to exact host that set it
Domain=.example.com: Cookie sent to example.com and all subdomains

Persistence Implication: If your load balancer serves multiple subdomains (api.example.com, www.example.com) from the same pool, set Domain appropriately so persistence works across subdomains.

2. Path Attribute:

Set-Cookie: SERVERID=abc; Path=/app

Restricts cookie to specific URL paths:

Path=/: Cookie sent for all paths (most common)
Path=/app: Cookie sent only for /app/* routes

Persistence Implication: Almost always use Path=/ for persistence cookies. Path-restricted cookies can break persistence when users navigate between app sections.

3. Expires / Max-Age:

Set-Cookie: SERVERID=abc; Max-Age=3600
Set-Cookie: SERVERID=abc; Expires=Wed, 09 Jun 2025 10:18:14 GMT

Omitting both: Session cookie (deleted when browser closes)
Max-Age=3600: Expires in 3600 seconds
Expires=<date>: Expires at specific date/time

4. Secure Attribute:

Set-Cookie: SERVERID=abc; Secure

Cookie only sent over HTTPS connections.

Persistence Implication: Always use Secure for production. Without it, persistence cookies leak to unencrypted connections, exposing server identities and enabling session hijacking.

5. HttpOnly Attribute:

Set-Cookie: SERVERID=abc; HttpOnly

Cookie inaccessible to JavaScript (document.cookie).

6. SameSite Attribute:

Set-Cookie: SERVERID=abc; SameSite=Lax
Set-Cookie: SERVERID=abc; SameSite=Strict
Set-Cookie: SERVERID=abc; SameSite=None; Secure

Controls cross-site cookie behavior:

Strict: Cookie only sent for same-site requests
Lax: Sent for same-site + top-level GET navigations (default in modern browsers)
None + Secure: Sent for cross-site requests (requires Secure)

Complete Cookie Example

HTTP Header

# Production-grade persistence cookie
Set-Cookie: SERVERID=encrypted_value_here; Path=/; Domain=.example.com; Max-Age=3600; Secure; HttpOnly; SameSite=Lax
 
# Breakdown:
# SERVERID=encrypted_value_here  - Server identifier (encrypted)
# Path=/                          - Valid for all paths
# Domain=.example.com             - Works across subdomains
# Max-Age=3600                    - Expires in 1 hour
# Secure                          - HTTPS only
# HttpOnly                        - No JavaScript access
# SameSite=Lax                    - Reasonable cross-site protection

Modern Browser Defaults

Load Balancer Configuration Deep Dive

Let's examine cookie-based persistence configuration across major load balancing platforms. Understanding these implementations helps you make informed choices and troubleshoot issues.

NGINX Open Source doesn't include built-in cookie persistence—this is an NGINX Plus feature. Open source alternatives include using ip_hash or third-party modules.

NGINX Plus offers the sticky directive with cookie persistence:

nginx.conf
NGINX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
upstream backend {
    # Enable sticky cookie persistence
    sticky cookie srv_id expires=1h domain=.example.com httponly secure path=/;
    
    # Backend servers
    server 10.0.0.1:8080 weight=1;
    server 10.0.0.2:8080 weight=1;
    server 10.0.0.3:8080 weight=1;
}
 
server {
    listen 443 ssl;
    server_name example.com;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
 
# Alternative: sticky route (using existing cookies)
upstream backend_route {
    sticky route $cookie_jsessionid;
    
    server 10.0.0.1:8080 route=a;
    server 10.0.0.2:8080 route=b;
}

Key Options:

expires: Cookie lifetime (e.g., 1h, 24h)
domain: Cookie domain attribute
httponly: Add HttpOnly flag
secure: Add Secure flag
path: Cookie path (default: /)

Security Considerations

Cookie-based persistence introduces security surface area that must be carefully managed. Let's examine the threat model and mitigations:

Security Threats

•Infrastructure Reconnaissance: Predictable or unencrypted cookie values reveal backend server names, IPs, or pool structures. Attackers use this information to map your infrastructure before targeted attacks.
•Session Fixation: If attackers can set or predict persistence cookies before user authentication, they might force users onto specific servers they've compromised or are monitoring.
•Cookie Theft via XSS: Without HttpOnly, JavaScript-based attacks (XSS) can steal persistence cookies, learning which servers users are routed to.
•Cookie Interception (MITM): Without Secure flag, cookies transmit over unencrypted connections, exposing routing information to network attackers.
•Cookie Tampering: If cookies aren't signed/encrypted, attackers can modify them to target specific servers—useful for concentrating attacks or avoiding detection.
•Denial of Service via Cookie Manipulation: Attackers might flood a specific backend by manipulating cookies to consistently target that server, bypassing load balancing protections.

Security Best Practices

•Always Encrypt Cookie Values: Use encrypted or cryptographically-signed cookie values. Never expose raw server identifiers, IPs, or internal names.
•Set Secure Flag: Persistence cookies must only transmit over HTTPS. Period. This isn't optional in production.
•Set HttpOnly Flag: There's no legitimate reason for client JavaScript to read persistence cookies. Block access unconditionally.
•Use SameSite Appropriately: Start with SameSite=Lax. Only use None if cross-origin requests truly require persistence, and understand the CSRF implications.
•Implement Cookie Rotation: Don't let persistence cookies live forever. Rotate them periodically (e.g., every few hours) to limit the window for stolen cookies.
•Validate Cookie Integrity: Load balancers should validate that cookies haven't been tampered with. Signed cookies prevent modification.
•Rate Limit by Cookie: If you detect unusual patterns (many requests with same cookie from different IPs), investigate potential cookie theft.
•Log Cookie Changes: When users establish new sessions or get re-routed, log these events for forensic analysis.

The Privacy-Security Balance

Edge Cases and Troubleshooting

Cookie-based persistence can fail in subtle ways. Here are common issues and their resolutions:

Problem 1: Persistence Not Working at All

Symptoms: Users bounce between servers despite cookie configuration.

Potential Causes:

Cookie domain mismatch (cookie set for api.example.com, user on www.example.com)
Browser rejecting third-party cookies (if using iframe embed)
Missing SameSite/Secure for modern browsers
Load balancer not configured correctly for all routes
Health check failures causing server rotation

Debugging Steps:

Check browser DevTools → Application → Cookies
Verify Set-Cookie header in network response
Confirm cookie sent with subsequent requests
Check load balancer logs for routing decisions

Problem 2: Cookie Works But Persistence Is Intermittent

Symptoms: Sometimes requests hit the right server, sometimes not.

Potential Causes:

Multiple load balancers without shared state
CDN stripping cookies on certain paths
Some requests (static assets) bypass persistence
Cookie expiring too quickly
Browser incognito mode not persisting cookies

Debugging Steps:

Trace full request path (CDN → LB → origin)
Check if all request types include cookies
Verify cookie TTL matches expected session length

Problem 3: Cookie Conflicts

Symptoms: Application behaves erratically, multiple cookies present.

Potential Causes:

Multiple load balancers setting same-named cookie
Application and LB both setting persistence cookies
Cookie scope (domain/path) overlaps incorrectly
Migration leaving old cookies in place

Debugging Steps:

List all cookies for domain (DevTools)
Identify duplicate/conflicting names
Trace which component sets each cookie
Clear cookies and test clean session

Problem 4: Server Pool Changes Break Sessions

Symptoms: After deployments or scaling, users lose their sessions.

Potential Causes:

Cookie references server no longer in pool
Server index changed when pool resized
Encrypted cookie uses key that rotated
New servers have different identifiers

Mitigation Strategies:

Use session-binding (LB maintains mapping table)
Graceful draining before removing servers
Consistent server identifiers across deployments
Cookie fallback to normal load balancing on invalid value

Debug Header Injection

Advanced Cookie Persistence Patterns

Beyond basic cookie persistence, advanced patterns address specific architectural needs:

Pattern 1: Cookie Chaining (Multi-Tier Persistence)

In multi-tier architectures, you might need persistence at multiple levels:

Client → CDN → Global LB → Regional LB → Application Server

Each tier can set its own persistence cookie:

CDN: Route to consistent edge location
Global LB: Route to consistent region
Regional LB: Route to consistent server

Implementation: Use distinct cookie names at each tier (X-Edge, X-Region, X-Server).

Pattern 2: Weighted Persistence (A/B Testing)

During gradual rollouts, you want users to stick to their assigned variant:

First request: LB assigns to variant (90% old, 10% new)
Cookie encodes variant assignment
Subsequent requests route to same variant

Implementation: Cookie contains both variant and server within variant.

Pattern 3: Persistence with Fallback Pools

When primary servers are unavailable, route to backup pool while maintaining eventual consistency:

Normal: Route to primary (Cookie: primary_server1)
Primary fails: Route to backup (Cookie updated: backup_server5)
Primary recovers: Optionally migrate back

Implementation: Time-bounded cookies allow natural migration back.

Pattern 4: Shard-Aware Persistence

When data is sharded across servers, route users to the shard holding their data:

First request: LB examines user ID header
Hash user ID to determine shard
Set cookie encoding shard assignment
Subsequent requests route via cookie

Implementation: Cookie contains shard identifier, not server. LB maps shard to current server.

Pattern 5: Canary Cookie Persistence

For canary deployments, selected users get routed to canary servers:

First request: LB selects small percentage for canary
Canary users get special cookie (CANARY=true)
All subsequent requests route to canary pool
Non-canary users never see canary

Implementation: Two-stage routing—first check canary cookie, then normal persistence.

Pattern 6: Signed Cookie with Metadata

Embed metadata in cookies for advanced routing decisions:

Cookie: STICKY=<base64(server|timestamp|signature)>

The timestamp enables:

Automatic cookie expiry
Forced refresh after configurable period
Migration windows during deployments

Complexity Warning

Summary: Cookie-Based Persistence Mastered

We've thoroughly explored cookie-based session persistence, from fundamental mechanics to advanced patterns. Let's consolidate:

Key Takeaways

•Cookie persistence is the most reliable method — It works across network changes, survives IP variation, and requires only standard browser cookie support.
•Cookie content should be encrypted or signed — Never expose internal server identifiers. Use session binding or encrypted tokens.
•Cookie attributes matter for security — Always set Secure, HttpOnly, and appropriate SameSite. Omitting these creates exploitable vulnerabilities.
•Load balancer configuration varies significantly — Each platform (NGINX, HAProxy, AWS, Envoy) has different approaches. Understand your specific platform.
•Edge cases are subtle but critical — Domain mismatches, cookie conflicts, and pool changes can silently break persistence. Monitor and test thoroughly.
•Advanced patterns enable sophisticated routing — Multi-tier persistence, A/B testing, and shard-aware routing are possible but increase complexity.

What's Next:

Cookie Persistence Complete

2 / 5