Understanding Server State
SERVER STATE refers to information that an application backend maintains or manages to process requests, identify users, and coordinate application operations.
A server does not always process every request independently. Some operations require information from previous interactions, such as user sessions, shopping carts, or ongoing transactions.
The backend may maintain this information in its LOCAL MEMORY or manage it through external storage systems such as DATABASES and REDIS.
This information helps the application maintain continuity across requests and execute business operations correctly.
In simple terms
Core idea
What Information Does a Server Maintain?
Consider an E-commerce application.
When a user interacts with the application, the backend may need to manage different types of information to support the user's activities.
User ID, email address, profile details and account information.
Identify users and retrieve their account data.
Session ID, authentication status and session expiration.
Maintain authenticated user interactions.
Product IDs, quantities, selected variants and cart ownership.
Preserve the user's shopping selections.
Order ID, order items, order status and delivery details.
Track the order lifecycle.
Transaction ID, payment status and payment references.
Track and coordinate payment operations.
Current task, processing status and workflow progress.
Coordinate multi-step business operations.
Client State vs Server State
The device or application through which the user interacts with the system.
The backend that processes requests and manages application operations.
CLIENT STATE
CLIENT state refers to information maintained on the user's device or application.
Examples include:A user selects the blue color filter on a product page. The selected filter can be maintained in the browser without requiring the backend to remember every UI interaction.
SERVER STATE
SERVER state refers to information maintained or managed by the backend.
Examples include:When a user places an order, the backend stores and manages the order information so that it remains accessible across devices and sessions.
Key Differences
| Client State | Server State |
|---|---|
| Maintained on the user's device | Managed by the backend |
| Primarily supports UI interactions | Supports business logic and operations |
| Can be lost when browser data is cleared | Persistence depends on backend storage policies |
| Generally belongs to a particular client | Can be shared across clients through centralized storage |
| Selected tab, modal, form values | Orders, inventory, user accounts |
How Does a Server Handle Information?
We've understood that a server manages different types of application information, such as user details, sessions, shopping carts, and orders.
But how does a server handle this information when a user sends multiple requests?
Consider an E-commerce application where a user logs in, browses products, adds items to a shopping cart, and proceeds to checkout.
Each interaction generates a separate request to the backend. However, the application still needs access to relevant information from the user's previous interactions.
This introduces an important architectural question:
The ANSWER depends on how the application is designed.
In system design, we commonly discuss two approaches to handling this:
The server does not depend on locally retained client/session state between requests.
The server maintains client/session-related state across requests.
What Is Stateless Architecture?
STATELESS ARCHITECTURE is a server architecture in which an application server does not depend on locally retained client/session state from previous requests to process a new request. Each request carries the required information or allows the server to retrieve it from an external storage system.
In a Traditional Application, a server may maintain user session information in its own memory and use it when the user sends subsequent requests.
➤ However, in a Stateless Architecture, the server does not need to remember the previous interaction with a particular client in its local memory.
Instead, Every request → Contains the necessary context, such as 🔶 Authentication Credentials, 🔶 Request Parameters, or 🔶 Identifiers required to retrieve application data.
This allows different application servers to process requests from the same user without depending on session information stored locally on another server.
In simple terms
Core principle
How Does a Stateless Server Handle Requests?
Consider an E-commerce application where a user wants to view their previous orders.
In a Stateless Architecture, the application server does not need to remember which user sent the previous request. Instead, the incoming request carries the authentication information required to identify the user.
CLIENT Sends :
GET /api/orders
Authorization: Bearer token
SERVER performs :
Validates the token
Identifies the user
Retrieves the user's orders
Returns the response
CLIENT Sends :
GET /api/profile
Authorization: Bearer token
SERVER performs :
Validates the token again
Identifies the user
Retrieves profile information
Returns the response
Notice that the second request does not depend on the first application server remembering the user's session in its local memory.
The required authentication information is supplied again with the request.
How Multiple Servers Handle Requests Independently ?
One of the MAJOR ADVANTAGE of stateless application servers becomes clear when an application needs to handle increasing traffic.
Consider an application running behind a load balancer with multiple application server instances.
Suppose a user sends three different requests:
Each server can process the request because the required authentication information is included in the request, and application data can be retrieved from shared storage.
Key observation
Where Does Application State Live?
A common Misconception is that STATELESS architecture means the application cannot store user or business information.
This is INCORRECT.A stateless application can use external storage systems to maintain information required across requests.
Remember
A STATELESS application server does not depend on locally retained client/session state from previous requests.
Instead, each request carries the necessary context, such as authentication credentials, or allows the server to retrieve the required information from shared storage systems.
This means application data can still be maintained in databases, Redis, and other external storage systems without making individual application servers dependent on their local memory.
What about authentication?
Applications can use signed tokens such as JWTs to carry verified identity and authorization claims.
A server can validate a token without looking up a traditional server-side session on every request.
However, token revocation, permissions, and other requirements may still require shared storage or additional checks.
Characteristics of Stateless Architecture
Independent Requests
Each request carries or retrieves the context required for processing.
No Local Session Dependency
Servers don't rely on locally retained session state between requests.
Horizontal Scalability
New application server instances can be added to handle increasing traffic.
Shared Data Access
Multiple servers can access common databases and distributed storage.
Easier Server Replacement
Servers can restart or be replaced without transferring local session state.
Flexible Request Routing
Requests can reach different available servers without depending on session affinity.
TRADE-OFFS : Advantages and Disadvantages
ADVANTAGES
LIMITATIONS
What Is Stateful Architecture?
STATEFUL ARCHITECTURE is a server architecture in which an application server retains or maintains client/session state between requests and uses that previously stored information when processing subsequent requests.
The SERVER remembers relevant context from earlier interactions instead of requiring every request to independently provide all of it.
Consider a user logging into an e-commerce application.
In a Stateful Architecture, the application server can create a session after Login and Maintain Information Such as the user's identity, authentication status, and shopping cart context.
When the same user sends subsequent requests, the server uses the previously maintained session information to understand the user's context.
Every subsequent request → Can reference the existing session using a session identifier, such as a cookie.
The server uses that identifier to locate the associated session and continue processing the user's interaction.
In simple terms
Core principle
How Does a Stateful Server Handle Requests?
Consider an e-commerce application where a user logs in, views products, adds items to a shopping cart, and proceeds to checkout.
In a Stateful Architecture, the application server can maintain the user's session after login and use it to recognize the user during subsequent requests.
CLIENT Sends :
POST /api/login
Email + Password
SERVER performs :
Validates user credentials
Creates a user session
Stores session information
Returns a session ID to the client
CLIENT Sends :
GET /api/cart
Cookie: SESSION_ID=abc123
SERVER performs :
Reads the session ID
Finds the existing session
Identifies the user and cart context
Returns cart information
Notice that the server uses the session created during the first request to understand the context of the second request.
The client sends the session identifier, and the server uses it to locate the previously maintained session.
Where Does the Server Maintain Session State?
A stateful application server needs a way to maintain session information between requests.
One common implementation is to store session data in the application's own memory.
IN-MEMORY SESSION
EXTERNAL SESSION STORE
Remember
What Happens When Multiple Servers Handle Requests?
A challenge with stateful architecture becomes clear when an application runs across multiple application server instances.Consider an application with a load balancer distributing incoming requests across three servers.
This can cause SESSION LOOKUP FAILURES or make the user appear logged out.
There are two common ways to handle this problem.
1. Sticky Sessions (Session Affinity)
The load balancer routes requests from the same client to the same application server that originally created the session.
For example:
Request routing
This helps the server find its locally stored session without transferring it to another instance.
2. Shared Session Store
Instead of maintaining session data separately in each server's local memory, the application can store sessions in a centralized or distributed session store such as Redis.
Now, any application server can retrieve the user's session using the session ID.
Request routing
All three servers can access the same session information from Redis, so the session is not tied to one particular application server.
Characteristics of Stateful Architecture
Session Retention
The application maintains client/session context between requests.
Session-Based Processing
Subsequent requests can use information established during earlier interactions.
Session Storage
Session information can be maintained in local memory or an external store.
Session Affinity
Local sessions may require requests to reach the same application server.
Context-Aware Requests
The server uses previously established session information to process requests.
Session Lifecycle
Sessions can be created, updated, expired, and invalidated.
TRADE-OFFS : Advantages and Disadvantages
ADVANTAGES
LIMITATIONS
Stateless vs Stateful Architecture
Both Stateless and Stateful Architectures manage application information across user interactions, but they differ in how application servers handle session context between requests.
Let's compare these two approaches across some important architectural characteristics.Stateless
The application server does not depend on locally retained client/session state from previous requests.
Request → Server → Shared Storage
Each request carries or retrieves the required context.
Stateful
The application maintains session context across requests and uses previously established information when processing subsequent interactions.
Request → Session Lookup → Processing
The server uses previously maintained session context.
Key Architectural Differences
| Aspect | Stateless | Stateful |
|---|---|---|
| Request handling | Each request is processed independently. | Requests can use context established by previous interactions. |
| Session dependency | No dependency on locally retained client/session state. | Depends on previously maintained session context. |
| Session storage | Usually avoids local server-side session storage. | Can use local memory or an external session store. |
| Authentication | Often uses tokens such as JWTs. | Often uses server-side sessions identified by session IDs. |
| Request routing | Requests can reach any suitable available server. | Local sessions may require sticky sessions. |
| Horizontal scaling | Generally simpler because requests are not tied to local sessions. | Requires session management across server instances. |
| Server failure | Another server can handle requests if shared dependencies remain available. | Locally stored sessions may be lost if the server fails. |
| Infrastructure | May use shared databases, caches, and token validation. | May require session storage, synchronization, and expiration management. |
| Typical use cases | REST APIs, microservices, and horizontally scaled services. | Session-oriented applications and workflows requiring ongoing context. |
An Important Architectural Distinction
Stateful and stateless architecture are not determined simply by where session data is stored.
For example - An Application can maintain server-side sessions in Redis and allow multiple application servers to access them. The Application uses session-based state, but individual application server instances do not need to retain those sessions in their own memory.
Similarly, a stateless application server can still access databases and Redis to retrieve application data.
The key question:
Does the application server depend on session context retained from previous requests, or can it process the request using the context provided or retrieved independently?
When to Use Which Architecture?
Neither stateless nor stateful architecture is universally better. The right choice depends on how your application handles user context, manages sessions, scales traffic, and processes requests.
Choose Stateless When
Requests should be independently processable, and application servers should not depend on locally retained session context.
❖ High-traffic REST APIs
❖ Microservices
❖ Horizontally scaled web applications
❖ Serverless applications
❖ Public APIs and backend services
Choose Stateful When
❖ Real-time multiplayer games
❖ Persistent WebSocket connections
❖ Collaborative applications
❖ Interactive sessions
❖ Long-running workflows
When Stateless Architecture Is a Good Fit ?
Consider an e-commerce application where users request their order history, profile, and product information.
Each request carries authentication credentials. The server validates the request and retrieves the required information from shared storage. Any available application server can process it.
Why stateless ? Independent request processing and easier horizontal scaling.
In a microservices architecture, services such as User, Order, and Payment should ideally process requests without depending on session data stored inside a particular service instance.
Each service can scale independently, while shared databases, caches, or other infrastructure maintain the required application data.
Why stateless? Independent deployment, scaling, and request handling.
Serverless functions may execute on different instances for different requests. Keeping session state inside an individual function instance is unreliable because the instance may be reused, replaced, or unavailable for the next invocation.
Why stateless ? Each invocation can operate independently using request context and external storage.
When Stateful Architecture Is a Good Fit ?
In a multiplayer game, the server continuously maintains the current game state, including player positions, scores, health, and active game events.
Position
Score
Status
The server needs to maintain and update a shared game state as players interact in real time.
Why stateful ? Continuous interactions depend on the current session or game state.
Consider a live chat application. A WebSocket connection remains open between the client and server, allowing both sides to exchange messages without establishing a new HTTP request for every message.
The server tracks active connections and may maintain connection-specific context. If connections are distributed across multiple servers, connection routing and shared coordination need to be designed carefully.
Why stateful ? The application maintains ongoing connection context.
In collaborative tools such as shared document editors, multiple users may edit the same document simultaneously. The application coordinates active users, document changes, and synchronization of ongoing updates.
Why stateful ? Maintaining ongoing collaboration context is important.
Decision Guide
Can Both Architectures Be Used Together?
Yes. In fact, many real-world applications combine stateless request processing with stateful components.
In this design, ordinary API servers can process requests independently, while Redis provides shared state and a real-time service manages persistent connections. The overall application uses both stateless and stateful behavior.