1. Problem Statement

Imagine this:

A user logs into your application, adds items to their cart...
Everything works fine.

Then suddenly — they get logged out or their cart is empty.

Why?

Because their next request went to a different backend server.

This is one of the most common real-world issues in load-balanced environments.

Without session persistence:

• Login sessions break

• Shopping carts reset

• User experience becomes frustrating

---

2. Concept Explanation

Session Persistence (Sticky Sessions) ensures that:

A user is always sent to the same backend server for the duration of their session.

Simple Analogy

Think of going to a barber shop.

• First time → any barber (load balancing)

• Next visits → you go to the same barber (persistence)

Because:

• They remember your style

• They already know your preferences

---

3. Types

1. Source IP Persistence

• Uses client IP to stick to a server

• Simple but unreliable because NAT users share the same IP

• Load balancer maintains persistence table

---

2. Cookie-Based Persistence

• Load balancer inserts or uses cookies

• Most reliable for web applications

• The cookie contains hashed persistence information

---

3. SSL Session ID

• Uses SSL session information

• Useful for HTTPS traffic without cookies

• This type of persistence is used in SSL-BRIDGE service (NetScaler)

You can refer to NetScaler Docs for more details on different types of persistences supported by NetScaler.

---

4. How It Works Internally

Step-by-step flow:

1. Client sends first request to Load Balancer

2. Load Balancer selects a backend server

3. Load Balancer creates a persistence record

4. Response sent back to client

5. Client sends next request

6. Load Balancer checks persistence table

7. Request is sent to the same server

Key idea:
Load balancer maintains a mapping table between client and server. In cookie-based persistence, the load balancer may rely on information stored in the cookie instead of a traditional persistence table, but it still maintains mapping logic to route traffic correctly.

---

5. Diagram

Session Persistence Diagram

This diagram shows how the load balancer remembers a client and routes all future requests to the same backend server.

Figure: session-persistence-diagram.png

What to Observe

• First request → load balancer selects server

• Persistence record / cookie is created

• Subsequent requests → same server

• If server down, Load balancer assigns → New server

---

6. Real-World Example

E-commerce Scenario

Without Persistence

• Login → Server A

• Add to cart → Server B

• Cart is empty

---

With Persistence

• Login → Server A

• Add to cart → Server A

• Checkout works

---

7. Common Issues / Pitfalls

Session loss after failover

• Server crashes and session is lost

Persistence timeout too low

• If the user stays idle, the mapping expires

• Next request goes to a different server and session loss

Uneven load distribution

• One server gets too many sticky users

Cookie mismatch

• Application and load balancer cookie conflict

---

NetScaler Hands-on

---

8.1 Commands

# Create LB vServer
add lb vserver lb_vsrv_http HTTP 10.0.0.10 80

# Bind backend services
bind lb vserver lb_vsrv_http svc_server1
bind lb vserver lb_vsrv_http svc_server2

# Enable persistence
set lb vserver lb_vsrv_http -persistenceType COOKIEINSERT

# Verify configuration
show lb vserver lb_vsrv_http

Sample Output (Truncated)

lb_vsrv_http (10.0.0.10:80) - SSL Type: ADDRESS
State: UP
..
Persistence: COOKIEINSERT (version 0) Persistence Timeout: 2 min
..
1) svc_server1 - HTTP State: UP
       Persistence Cookie Value : NSC...

2) svc_server2 - HTTP State: UP
       Persistence Cookie Value : NSC...

Try it Yourself

Interactive Demo

**Best viewed on Laptop and bigger screens

Mini Lab

Objective

Validate session persistence behavior

---

Setup

• 2 backend servers:

  • Server1 returns "Server A"

  • Server2 returns "Server B"

• NetScaler load balancer in front

---

Steps

1. Send request

curl http://10.0.0.10

1. Observe response

Server A

1. Repeat multiple times

curl http://10.0.0.10

---

Expected Output

You should consistently see:

Server A

Key Observation

• Same backend server is hit every time

• Confirms persistence is working

---

8.3 Experiment

Change persistence type:

set lb vserver lb_vsrv_http -persistenceType SOURCEIP

Observe

• Behavior changes across clients

• Less reliable in NAT environments

---

9. Key Takeaways

• Session persistence keeps user experience consistent

• Cookie-based persistence is most reliable

• Persistence affects load distribution

• Always validate with real traffic

---

10. Conclusion

Session persistence is not optional — it is essential for user experience.

Without it:

• Users lose sessions

• Applications behave unpredictably

With it:

• Systems feel consistent

• Users trust your application

---

11. Series Continuity

Before this, we explored how requests are processed inside NetScaler.

Read here: https://blog.bgyani.co.in/inside-netscaler-understanding-client-request-flow