Stateless vs Stateful Architecture for Backend Interviews

An interviewer asks why an API can add ten servers behind a load balancer while a live game room cannot be moved so casually. The answer is not that one system has data and the other does not. Almost every useful system has state. The real question is where that state lives and whether the next request can safely land on a different instance.

This guide explains that distinction, the operational trade-offs, and how teams move session state out of application memory. Continue from HTTP status codes and use the Backend Developer Interview Guide for the complete path.

Table of Contents

What State Means

State is information from an earlier interaction that changes how a later interaction must be handled: a login session, websocket connection, cart, lock, workflow step, or database record. A stateless application server may still read a database or Redis. It is stateless at the server layer when no particular process must remember the client for the next request.

Stateless Servers

In a stateless API, each request brings its credentials and input, while durable data lives in shared stores. Any healthy instance can verify a token, read an order, and respond. That makes rolling deploys, autoscaling, and failover simpler because the load balancer can send a retry to another server.

The cost is an extra shared dependency. Moving sessions to Redis improves routing flexibility but makes Redis availability, eviction, security, and latency part of the request path. Stateless is not “no state”; it is deliberate state placement.

Stateful Servers

A stateful server keeps client-specific context in its own memory or local storage. This can be efficient for a websocket connection, game room, streaming session, or an in-memory actor. The downside is affinity: if the process dies or a request reaches another instance, that instance cannot continue without recovering the state.

Sticky sessions are a tactical bridge, not a cure. They preserve routing while an instance is healthy, but they complicate rebalancing and do not make local state durable. Replication or an external state store is still needed for recovery.

Request Flow and Failure Recovery

flowchart TD
    A[Client request] --> B[Load balancer]
    B --> C[Stateless API instance]
    C --> D[(Shared session or data store)]
    D --> C
    C --> E[Response]
    C --> F{Instance fails?}
    F -->|Yes| B
    B --> G[Another API instance]
    G --> D
    G --> E
    F -->|No| E

    classDef flow fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#000000;
    class A,B,C,D,E,F,G flow;

The diagram shows the key recovery property: another API instance can resume because the required state is shared. A stateful connection-oriented service instead needs partition ownership, replay, replication, or reconnect logic.

Scaling Trade-offs

Stateless APIs scale horizontally with ordinary load balancing. Add instances when CPU, latency, or request volume rises, then remove them during quiet periods. Stateful services can also scale, but ownership and movement matter: partition by user or room, replicate the partition, and plan what happens during rebalancing.

For example, a checkout API should usually externalize sessions because every request benefits from flexible routing. A multiplayer match coordinator may keep a room in memory for low-latency updates, but must snapshot or replicate enough state to recover when its host disappears.

When Stateful Design Is Correct

Choose stateful design when locality or continuity is a first-class requirement: long-lived websocket connections, databases, stream processors, actor systems, and game rooms. Choose stateless application servers when requests are independent and availability, elastic scale, and simple deployment matter more. Most production systems are hybrids: stateless edge/API layers in front of explicitly stateful storage and connection services.

Interview Questions

1. Does using a database make an API stateful?

No. The overall system has durable state, but the API tier is stateless if any instance can handle the next request by using shared data. In an interview, name the layer you are describing; otherwise the word “stateful” becomes misleading. The important operational question is whether a replacement instance can continue the work.

2. Why are sticky sessions risky?

Sticky sessions tie a client to one instance, so an imbalance, deployment, or crash creates an uneven or broken experience. They can be useful temporarily for legacy session storage, but they make failover and autoscaling less flexible. A shared session store or a token-based design normally gives a cleaner long-term path.

3. When would you deliberately keep state in memory?

I would keep hot, short-lived state in memory when local latency is valuable and I have a recovery plan. A chat connection registry or game-room loop is a common example. The design still needs ownership, backpressure, reconnect behavior, and replication or snapshots when losing the process is unacceptable.

4. Are JWTs always the best way to become stateless?

No. JWTs reduce server-side session lookup, but revocation, token size, key rotation, and claim freshness become trade-offs. An opaque session ID backed by Redis can leave the API tier stateless while allowing immediate revocation. Choose based on security and operational requirements, not as a slogan.

5. How would you migrate a local-session application?

First measure session size and access patterns, then move the minimum required data to a shared store with TTL and encryption. Deploy support for reading both stores during a migration window, then remove local writes after traffic has drained. Test failover explicitly: kill an instance during an active session and verify the next request succeeds elsewhere.

Conclusion

1. Stateless does not mean data-free; it means no single application instance owns essential client context.
2. Stateless API tiers simplify load balancing, failure recovery, and autoscaling.
3. Stateful workloads are valid when continuity or locality matters, but need ownership and recovery design.
4. Shared sessions trade routing flexibility for a dependency that must be operated well.

The next topic in this series covers authentication vs authorization - how an API establishes identity and then enforces permissions. For the request layer beneath these choices, revisit client-server architecture.

References

1. Stateful vs Stateless Architecture - AlgoMaster https://algomaster.io/learn/system-design/stateful-vs-stateless-architecture
2. REST - MDN Web Docs https://developer.mozilla.org/en-US/docs/Glossary/REST

YouTube Videos

1. “Stateful vs Stateless (The #1 Concept You Must Understand)” https://www.youtube.com/watch?v=MBI_YiT6QNs