Sticky Round Robin

Sticky Round Robin is a hybrid load balancing algorithm that combines the fairness of Round Robin with the session persistence of IP Hash. It aims to evenly distribute client requests across a group of servers while maintaining session affinity, which is crucial for applications that rely on client-specific data stored on the server.

How Sticky Round Robin Works

  1. Initial Request: When a client sends its first request, the load balancer assigns it to a server using the Round Robin algorithm. This ensures initial fairness in load distribution.
  2. Cookie/Session ID: The load balancer sets a cookie in the client’s browser or includes a session ID in the response header. This cookie or session ID identifies the server assigned to the client.
  3. Subsequent Requests: For all subsequent requests from the same client, the load balancer checks the cookie or session ID. It then directs those requests to the same server that handled the initial request.
  4. Session Timeout: If the client remains inactive for a specified period, the session expires, and the cookie or session ID is deleted. The next request from the client will be treated as a new request and assigned to a server using Round Robin.

Benefits of Sticky Round Robin

  • Session Persistence: Ensures that a client’s session data remains on the same server, crucial for applications like online shopping carts, banking, and personalized content delivery.
  • Improved Performance: Reduces the need to transfer session data between servers, leading to faster response times and improved user experience.
  • Initial Fairness: The use of Round Robin for initial request assignment ensures a balanced distribution of load across servers.

Considerations and Limitations

  • Uneven Load Distribution: If session lengths vary significantly among clients, sticky sessions can lead to uneven load distribution. Some servers might become overloaded with long-lived sessions while others remain underutilized.
  • Server Failures: When a server fails, the associated sessions are lost, potentially disrupting the user experience. Load balancers should have mechanisms in place to gracefully handle server failures and reassign sessions to other servers.
  • Scalability: Sticky sessions can hinder horizontal scalability, as adding new servers might not evenly distribute the load if existing sessions are tied to specific servers.

Implementation

Sticky Round Robin is typically implemented within load balancers. Most modern load balancers support sticky sessions through various mechanisms like cookie insertion, URL rewriting, or session ID tracking.

Python
import itertools

class StickyRoundRobin:
    def __init__(self, servers, session_timeout=300):
        self.servers = itertools.cycle(servers)
        self.sessions = {}
        self.session_timeout = session_timeout

    def get_server(self, client_id):
        if client_id in self.sessions and self.sessions[client_id]['expires'] > time.time():
            return self.sessions[client_id]['server']
        else:
            server = next(self.servers)
            self.sessions[client_id] = {'server': server, 'expires': time.time() + self.session_timeout}
            return server

# Example Usage
import time

servers = ['server1', 'server2', 'server3']
srr = StickyRoundRobin(servers)

client_ids = ['client1', 'client2', 'client3']

for _ in range(10):
    for client_id in client_ids:
        server = srr.get_server(client_id)
        print(f"Request from {client_id} sent to {server}")

# Simulate time passing and session expiration
time.sleep(301)  # Sleep for longer than the session timeout

for client_id in client_ids:
    server = srr.get_server(client_id)
    print(f"Request from {client_id} sent to {server} (after session expiration)")
    
# Example Output:

# Request from client1 sent to server1
# Request from client2 sent to server2
# Request from client3 sent to server3
# Request from client1 sent to server1
# ... (more requests, each client sticks to their assigned server)
# Request from client1 sent to server2 (after session expiration) 
# Request from client2 sent to server3 (after session expiration)
# Request from client3 sent to server1 (after session expiration)
# ...

Considerations:

  • Session Storage: In a real-world scenario, session data would likely be stored in a database or cache for persistence across load balancer restarts.
  • Server Failure Handling: Implement mechanisms to handle server failures gracefully, such as reassigning sessions to healthy servers.
  • Scalability: Consider strategies to distribute sessions evenly when adding or removing servers to avoid overloading specific servers with long-lived sessions.

Real-World Examples

  1. E-commerce Websites: In an online store, sticky sessions ensure that a user’s shopping cart items remain associated with the same server throughout their browsing session. This prevents the cart from being emptied or showing incorrect items if the user is redirected to different servers.
  2. Online Banking: Sticky sessions are essential for online banking applications to maintain a secure and consistent user session, preventing unauthorized access and ensuring that transaction data is not lost during server switches.
  3. Personalized Content: Websites that offer personalized recommendations or content based on user behavior benefit from sticky sessions. This ensures that the user’s preferences and history are available on the same server, providing a more relevant and engaging experience.

System Design Interview Examples

Question: How would you implement session persistence in a Sticky Round Robin load balancer?

Answer: Session persistence can be implemented using various mechanisms:

  • Cookies: The load balancer can insert a cookie in the client’s browser, containing the assigned server’s ID. Subsequent requests include the cookie, allowing the load balancer to direct them to the correct server.
  • Session IDs: The load balancer can embed a unique session ID in the response header, which the client includes in subsequent requests for server identification.
  • IP Hash (Partial Stickiness): While not strictly Sticky Round Robin, IP Hash can provide a degree of session persistence by hashing the client’s IP address to a server. This is less reliable than cookies or session IDs but simpler to implement.

—–

    Interviewer: “Design a load balancing solution for an online learning platform where students need to maintain their progress and course materials across multiple sessions.”

    • Candidate: “Sticky Round Robin would be a suitable choice here. It would ensure that each student is assigned to a specific server for their learning session, preserving their progress and access to course materials. We could implement session persistence using cookies or session IDs. To mitigate the risk of server failure, we could also implement session replication to maintain backups.”

    —–

    • Interviewer: “How would you design a load balancing system for a massively multiplayer online game (MMO) where players need to interact with each other in real time?”
      • Candidate: “While Sticky Round Robin could ensure that players in the same game session remain on the same server, it might not be ideal due to the potential for uneven load distribution and scalability challenges. A better approach might be to combine IP Hash for initial server assignment with a dynamic load balancing algorithm like Least Connections to ensure responsiveness and handle fluctuations in player activity. We could also implement session migration or dynamic instance scaling to address server failures and capacity constraints.”