Tuesday 7 May 2024

How to maintain user state in a stateless Architecture?

Stateful System

Within a stateful system, user session information remains stored on the server.

 

Let me to explain with an example. Consider an e-commerce website hosted across three application servers.

 

In this scenario, each of the three application servers maintains its own user state. When a user logs in, his/her request is directed to one of the servers. For instance, UserA's login request is routed to server1, UserB's to server2, and UserC's to server3.

 

Since the system is stateful, each server retains information about the users it has interacted with. So, after UserA logs in and their session is established on server1, subsequent requests from UserA are handled by server1.

 

Similarly, UserB's session data is stored on server2, and UserC's on server3. This means that each user's session state is tied to the specific server they initially interacted with.

 

How are User A's requests consistently directed to Server 1?

This is accomplished through a technique known as Sticky Session. Sticky Session is a method employed in load balancing to ensure that requests from the same client are routed to the same server.

When a client establishes an initial connection with the server, the load balancer intercepts the request. It then checks whether the client already has a session or not. If it's a new client request, then the load balancer applies its load balancing algorithm to determine which server to route the request to. Once a server is chosen, the load balancer assigns a sticky session identifier to the client's session. This identifier could be a cookie or another mechanism enabling the load balancer to identify the client in subsequent requests. For subsequent requests from the same client, the load balancer utilizes the sticky session identifier to direct the request to the same server where the client's session is being maintained. This ensures that all requests from that client throughout its session are handled by the same server, maintaining session state. This process is illustrated in the diagram below.


Find the pseudo code for the same.

# Define a dictionary to store session information
session_dict = {}

# Function to handle incoming HTTP requests
def handle_request(request):
    # Extract client's session ID from the request
    session_id = extract_session_id(request)
    
    # Check if the session ID exists in the session dictionary
    if session_id in session_dict:
        # If session ID exists, retrieve the associated server
        server = session_dict[session_id]
    else:
        # If session ID doesn't exist or expired, assign a server based on load balancing algorithm
        server = select_server_based_on_algorithm()
        # Store the session ID and assigned server in the session dictionary
        session_dict[session_id] = server
    
    # Route the request to the selected server
    route_to_server(request, server)

# Function to extract session ID from HTTP request (assuming session ID is stored in a cookie)
def extract_session_id(request):
    # Extract session ID from the request's cookies
    session_id = request.cookies.get('session_id')
    return session_id

# Function to select a server based on load balancing algorithm (e.g., round-robin)
def select_server_based_on_algorithm():
    # Implement your load balancing algorithm here (e.g., round-robin, least connections)
    # Return the selected server
    pass

# Function to route the HTTP request to the selected server
def route_to_server(request, server):
    # Forward the HTTP request to the selected server
    # Implement your logic to route the request to the server (e.g., using HTTP proxy)
    Pass

Stateless System

In a stateless system, each HTTP request is processed independently, and there's no need to  maintain session state on the server.


 


How to maintain the state in stateless Architecture?

Although stateless architectures do not retain state on individual servers, applications can still maintain state using various techniques. Here are some common techniques.

 

Client-Side Storage

Browser Storage: Use browser Local Storage to store information directly on the user's device. This is suitable for storing user preferences, shopping cart contents, or temporary data.

 

External Storage

Databases: Use relational databases like MySQL or NoSQL databases such as MongoDB to store session data or application state persistently. This enables access from any server and facilitates data sharing across the system.

 

Caching: Use in-memory data stores like Redis or Memcached for faster retrieval of frequently accessed data. Although not persistent, caching can enhance performance for frequently used state information.

 

Pseudocode to maintain state at external storage

Function handleRequest(request):
    // Extract necessary information from the request
    userId = request.userId
    action = request.action
    
    // Retrieve user state from external storage
    userState = fetchUserState(userId)
    
    // Process the action and update user state
    updatedState = processAction(userState, action)
    
    // Store the updated state back to external storage
    storeUserState(userId, updatedState)
    
    // Return response based on updated state
    return generateResponse(updatedState)

Advantages of Stateless Systems Compared to Stateful Systems with Sticky Sessions

1.   Scalability: Since, each request is processed independently, Stateless applications offer horizontal scalability. This enables seamless management of increased user traffic.

2.   Simplified Load Balancing: Load balancers can evenly distribute incoming requests across any available server without the need for sticky sessions. This flexibility optimizes resource utilization and enhances overall system performance.

3.   Reduced Memory Footprint: Stateless servers do not need memory allocation for session data storage, leading to more efficient resource utilization and lower memory footprint.

  

                                                  System Design Questions

No comments:

Post a Comment