Become a layoff-proof software engineer

Get lifetime access to 500+ system design questions

Back

A Quick Crash Course on Stateful vs Stateless Architecture

Stay updated with SWE Quiz

Get one free software engineering question every Saturday, with resources to learn more.

Stateful vs. stateless architecture is one of those architectural choices that seems simple on the surface but has important implications for whatever software you’re building.

Stateful architecture remembers. It maintains information about client sessions and uses that history to inform responses and operations. Think of it like a barista who remembers your usual order: “The usual today, Alex?”

Stateless architecture has amnesia. Each request is processed without any knowledge of previous requests. It’s like a vending machine—it doesn’t care who you are or what you bought last time; it just responds to your current input.

Stateful vs Stateless Architecture Stateful Architecture (With Memory) Stateless Architecture (Without Memory) Client Server Memory/State Database Client Load Balancer Server 1 Server 2 Database Request Response + Session ID Persist Retrieve Request + Context Query/Update Response Session state stored in memory No internal state storage

Stateful Architecture: The Pros and Cons

Pros:

  • Rich User Experience: The system remembers user preferences and history
  • Simpler Client Logic: The server handles most of the state management
  • Potentially Faster for Complex State: No need to transmit state with every request

Cons:

  • Scaling Headaches: Server instances need to share state somehow
  • Session Affinity Required: Users must be routed back to the same server, or state must be synchronized
  • Failure Recovery: If a server crashes, user state may be lost

Stateless Architecture: The Pros and Cons

Pros:

  • Horizontal Scaling: Add servers effortlessly without worrying about state
  • Resilience: Any server can handle any request
  • Simplicity: Fewer moving parts and failure modes

Cons:

  • Heavier Requests: Each request needs to contain all necessary context
  • Client Complexity: More state management happens on the client
  • Performance: May require multiple requests for complex operations

Real-World Examples

Stateful Examples

1. E-commerce Shopping Carts

When you’re shopping online at Amazon or any major retailer, your shopping cart persists as you browse different product categories. This is a perfect example of stateful architecture in action:

  • The server remembers the items you’ve added to your cart
  • If you navigate away to browse more products, the cart retains your selections
  • Even if you close the browser and come back later (via cookies or account login), your cart items are still there
  • This persistent state creates a seamless shopping experience that would be cumbersome in a completely stateless design

2. Video Streaming Services

Netflix and YouTube are excellent examples of stateful applications:

  • They track where you left off in a video
  • When you return, even on a different device, you can resume exactly where you stopped
  • Your watch history influences recommendations
  • Preferences like volume levels, subtitle settings, and playback speed are remembered

Netflix maintains complex user state including not just basic watch history, but also detailed metrics about viewing habits to create a highly personalized experience.

3. Messaging Applications

WhatsApp, Slack, and other messaging platforms rely heavily on stateful architecture:

  • Message history is maintained across sessions
  • Read/unread status of messages is tracked
  • User presence (online/offline status) is monitored and shared
  • Active conversations remain in context when switching between chats

When you open Slack after being away, it knows exactly which messages you’ve seen and which are new, which channels had activity, and which @mentions you need to address—all stateful information.

Stateless Examples

1. RESTful APIs

Public weather APIs are a quintessential example of stateless design:

  • Each time you request weather data, you must provide your location
  • The API doesn’t “remember” your previous requests
  • Every request contains all the information needed to fulfill it
  • This makes the API highly scalable—millions of requests can be distributed across server farms with no session tracking

2. Content Delivery Networks (CDNs)

CDNs like Cloudflare and Akamai operate in a stateless manner:

  • When you request an image, JavaScript file, or video from a CDN, each request is handled independently
  • The CDN doesn’t need to know about your previous requests
  • This allows CDNs to route requests to the nearest edge server without maintaining user sessions
  • The result is extremely high scalability and performance

3. Serverless Functions

AWS Lambda, Azure Functions, and Google Cloud Functions are designed to be stateless:

  • Each function invocation starts with a clean slate
  • No persistence between executions unless explicitly stored externally
  • This enables massive parallelization and automatic scaling
  • You pay only for the compute time you use, with no idle resources

For example, an image processing Lambda function might receive an image, resize it, and store the result in S3, but it maintains no knowledge of previous images it processed.

Common Patterns in Stateful Architecture

1. Sticky Sessions

Many e-commerce platforms and online banking systems use sticky sessions:

  • Once a user connects to Server A, the load balancer ensures all their subsequent requests go to Server A
  • This keeps the user’s session data accessible without complex synchronization
  • However, if Server A fails, the user’s session is lost and they might need to log in again
Sticky Sessions in Stateful Architecture Load balancer directs all requests from a specific user to the same server User A User B User C Load Balancer Server A User A Session Server B User B Session Server C User C Session Server D FAILED Database User A requests User B requests User C requests Server Failure Impact: If a server fails, all user sessions on that server are lost Key Characteristics: • User sessions are maintained on specific servers • Load balancer tracks which server handles which user

2. Centralized Session Stores

Many scaled web applications use Redis or Memcached for session management:

  • User session data is stored in a central, high-speed in-memory datastore
  • Application servers treat sessions as external resources rather than local state
  • If a server fails, users can be routed to another server with minimal disruption
  • Sessions continue because the new server can access the same session store

This creates a hybrid approach – the application servers remain stateless, while the session state is externalized. Companies like Twitter, LinkedIn, and large e-commerce platforms often implement this pattern with added complexity:

  • Session data is often partitioned or sharded across multiple cache instances for scalability
  • Short-lived authentication tokens may be used alongside longer session data
  • Critical session data might be periodically persisted to databases for durability
  • Not all user state is kept in the session – some may be fetched on-demand
Centralized Session Stores Session data stored in high-speed central database (Redis/Memcached) User A User B User C Load Balancer Server 1 Active Server 2 Active Server 3 Active Server 4 FAILED Centralized Session Store (Redis/Memcached) User A: Session1 User B: Session2 User C: Session3 Database Requests Dynamic routing to any server Read/Write Session Data Reroute traffic when server fails Persist Key Benefits: • High availability – server failures don’t impact users • Scalability – servers can be added/removed easily • Session continuity – seamless user experience

Common Patterns in Stateless Architecture

1. Token-Based Authentication

Many modern APIs and single-page applications use JSON Web Tokens (JWT):

  • After initial authentication, the server issues a signed JWT
  • The client includes this token with every subsequent request
  • The server validates the token but stores no session information
  • This allows authentication without server-side state

For example, when you log into a modern web application like Trello or Notion, your browser stores a JWT and includes it with every API request, allowing you to stay authenticated without the server maintaining a session.

Token-Based Authentication (JWT) Stateless architecture using JSON Web Tokens Client Browser JWT Storage (localStorage/Cookie) Load Balancer Stateless Server Pool Server 1 Server 2 Database JWT Structure Header Payload (Claims) Signature 1. Initial Authentication • Client sends credentials • Server validates credentials • Server generates signed JWT • Client stores JWT 2. Subsequent Requests • Client sends request with JWT • Server validates token signature • Server checks token expiration • Server extracts user info • No session lookup needed ✓ Completely Stateless! • Any server can process the request independently 1. Login Request JWT Response JWT 2. API Request + JWT in Header 3. Response Data access only (No session state)

2. Idempotent Operations

Payment processors like Stripe use idempotent operations to ensure reliability:

  • Each payment request includes a unique idempotency key
  • If the same request is sent multiple times (due to network issues), the payment is processed only once
  • The server can verify if a request has already been processed without maintaining session state
  • This prevents duplicate charges while maintaining a stateless architecture
Idempotent Operations in Stateless Architecture Example: Payment processing with idempotency keys E-commerce Application Client Payment API (Stripe) Stateless Servers Database Idempotency Records Idempotency Key Request Status pay_a1b2c3d4 COMPLETED pay_e5f6g7h8 FAILED pay_i9j0k1l2 PROCESSING pay_dup123 COMPLETED (DUPLICATE) pay_m3n4o5p6 PENDING 1. Generate Request Client generates a unique idempotency key 2. Check Key Server checks if the key exists in the database 3A. New Request Process payment and store result with key 3B. Duplicate Request Return cached result without processing again 4. Response Return consistent response to client Multiple identical requests due to network issues (same key) Single response Check & Record Payment Request Example POST /v1/charges Idempotency-Key: pay_a1b2c3d4 amount: 2500, currency: “usd”

When to Use Each Approach

Choose Stateful When:

  • User experience depends heavily on personalization and context
  • Real-time applications require persistent connections (gaming, collaborative editing)
  • Complex workflows span multiple interactions (multi-step forms, checkout processes)
  • Session security is paramount (banking applications, admin dashboards)

Choose Stateless When:

  • Global scale and high availability are primary concerns
  • Your application needs to handle unpredictable traffic spikes
  • Deployment simplicity and infrastructure costs are priorities
  • You’re building public APIs consumed by many different clients

It’s Not “Either/Or” – It’s “What Goes Where”

Here’s the truth that often gets missed in architecture discussions: virtually EVERY successful modern application uses a hybrid approach. The real architectural decision isn’t choosing between stateful OR stateless – it’s determining WHICH components should be stateful and which should be stateless.

Smart architects think in terms of state boundaries and state ownership:

Spotify’s State Architecture:

  • Stateless: Search API, catalog browsing, authentication
  • Stateful: Real-time streaming sessions, playback position, playlist management
  • Why this works: High-volume discovery features scale horizontally while personalized features maintain context

Gmail’s State Distribution:

  • Stateless: Email delivery pipeline, authentication, contact management
  • Stateful: Read/unread tracking, draft composition, user interface preferences
  • Why this works: Core email infrastructure handles massive scale while user-specific features preserve context

Modern Banking Apps’ State Partitioning:

  • Stateless: Public information APIs, initial authentication, transaction processing
  • Stateful: Fraud detection patterns, session context, compliance monitoring
  • Why this works: Critical security features maintain necessary context while enabling scale for standard operations

The Strategic Questions:

  1. Which data needs to persist across requests?
  2. Where should that state live? (Client, CDN edge, application server, database, etc.)
  3. What’s the performance impact of state location choices?
  4. How does state location affect security posture?
  5. What happens when state storage components fail?

These are the kinds of questions that you should expect to come up in design review at work, or from your interviewer during a system design interview.

As we’ve seen, framing the architectural decision as “stateful versus stateless” misses the mark. The real art is in determining which parts of your system should maintain state and which should remain stateless.

Thoughtfully distributing state across your components is based on specific needs:

  • Stateless where you need horizontal scaling and resilience
  • Stateful where you need context retention and user continuity
  • External state stores where you need both

State management is just one dimension of your architecture. It intersects with decisions about synchronous vs. asynchronous communication, monolithic vs. microservice design, and other critical choices that shape your system.

Get free interview practice

One software engineering interview question every week, with detailed explanations and resources.