# Session Persistence Explained ## 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](https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-persistence/persistence.html) 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. ![](https://cdn.hashnode.com/uploads/covers/69b17cba6c896b05199ab189/5307622f-1d41-4739-a0a4-3c2c6d788b71.png align="center") *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 ```bash # 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) ```bash 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
Click Here to Open Visualizer
**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 ```bash curl http://10.0.0.10 ``` 2. Observe response ```plaintext Server A ``` 3. Repeat multiple times ```bash curl http://10.0.0.10 ``` * * * ### Expected Output You should consistently see: ```plaintext Server A ``` ### Key Observation * Same backend server is hit every time * Confirms persistence is working * * * ## 8.3 Experiment Change persistence type: ```bash 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