🔥 Stateful vs Stateless APIs — Explained Simply
One of the most common backend + frontend interview questions.
Many developers know the definitions, but interviewers want to know how they work, when to use them, and their trade-offs.
🧠 What is State?
State = Information about a user's previous interactions.
For example:
- Is the user logged in?
- What's in their shopping cart?
- Which page were they on?
The key question is:
Who remembers this information?
🟢 Stateful API
A stateful API remembers the client between requests.
The server stores the session.
Flow
Login
│
▼
Server creates Session
│
▼
Session ID stored in Cookie
│
▼
Every request sends Session ID
│
▼
Server looks up session
Example
POST /login
Server:
Session ID: abc123
Next request:
Cookie: sessionId=abc123
Server already knows:
- User ID
- Login status
- Permissions
Advantages
✅ Easy logout (delete session)
✅ Easy to invalidate sessions
✅ Sensitive data stays on the server
Disadvantages
❌ Server must store sessions
❌ Harder to scale across multiple servers (unless sessions are shared using Redis or sticky sessions)
🔵 Stateless API
A stateless API remembers nothing.
Each request contains everything needed to authenticate and process it.
Usually with a JWT:
Authorization: Bearer <token>
Flow:
Login
│
▼
Server generates JWT
│
▼
Client stores token
│
▼
Every request sends JWT
│
▼
Server validates token
The server doesn't need to remember previous requests.
Advantages
✅ Easier to scale
✅ No session storage
✅ Better for distributed systems
✅ Perfect for REST APIs and microservices
Disadvantages
❌ Logout is harder (you can't "delete" a JWT that's already issued without extra mechanisms like token blacklists)
❌ Token expiration must be handled carefully
🧩 Comparison
| Feature | Stateful | Stateless |
|---|---|---|
| Server stores session | ✅ Yes | ❌ No |
| Client sends token/session every request | Session ID | JWT/API Token |
| Easy horizontal scaling | ❌ Harder | ✅ Easier |
| Easy logout | ✅ Yes | ⚠️ Requires token invalidation strategy |
| Common use | Traditional web apps | REST APIs, mobile apps, microservices |
🌍 Real-World Examples
Stateful
- Banking websites
- Traditional server-rendered applications
Stateless
- Mobile applications
- Single Page Applications built with React
- Public REST APIs
- Microservices
🚨 Interview Traps
❌ "Stateless means no authentication."
Wrong.
Authentication still exists.
The difference is:
State lives inside the token instead of on the server.
❌ "JWT is always stateless."
Mostly true, but if you maintain a blacklist or session store for JWTs, the overall system is no longer purely stateless.
❌ "REST requires JWT."
REST is stateless, but it doesn't require JWT specifically.
You can use:
- API Keys
- OAuth access tokens
- JWTs
- Other bearer tokens
💡 Senior-Level Insight
Modern applications often combine both approaches.
Example:
- Access Token (JWT) → Stateless authentication for API requests.
-
Refresh Token → Stored securely (often in an
HttpOnlycookie) and validated by the server to issue new access tokens.
This provides:
✔ Fast API authentication
✔ Better scalability
✔ Improved security
🎯 Interview One-Liner
A stateful API stores client session information on the server, while a stateless API stores no client state and requires each request to contain all the information needed for processing, typically using tokens like JWTs.
Top comments (0)