Understanding Stateless Microservices and the Mystery of Session Management

“If REST APIs are stateless, how come our app still remembers who I am?”
That’s the exact question that unlocked a cascade of insights for me—and probably the reason you’re reading this right now.

🔹 What is "State" in Software?

In software, state simply means: stored information about a user or process that persists across requests.

It could be:

• Logged-in user information

• Items in a shopping cart

• Preferences or roles

• Temporary application data

When we say something is stateful, it means it remembers things. The server stores information from our response.
When we say it’s stateless, it forgets everything between requests — meaning the server holds no cache or data from our transaction between request and response.

---

🔹 What Does It Mean When a Micro-service is Stateless?

So as we know, micro-services are multiple services or components deployed independently which communicate with each other.

For example, you log into Amazon and then go to:

• Orders

• Wishlist

• Buy Now

All these different components are deployed independently. This is great for scaling, load balancing, and fault tolerance.

But how do we share the data between all these components?

You cannot be logging in to check your orders and then again logging in to check your wishlist.
That provides a bad user experience and creates unnecessary API calls to login.

---

🔹 So… What is a Session, Exactly?

A session is a server-side storage of user data across multiple requests.

Think of it as a temporary memory slot the server gives to a user once they log in.
It typically includes:

• User ID

• Roles / Permissions

• Auth token or session ID

• Timestamps, IP, etc.

In traditional monolithic apps, session data is stored in memory (HttpSession in Java, for example).
But in distributed systems, that approach breaks.

So how do we communicate between these components without creating a new API just for session sharing?

After all, you may have noticed that when you run your application locally it creates a Tomcat server, and if we save our session data on the Tomcat server, then that data will be limited to that one server only.

How will a different server access it, making sure your session is continuing without a hassle — providing a smooth experience?

---

🔹 The Challenge: Stateless Services Need Session Data

Let’s say you have:

• Microservice A for authentication

• Microservice B for user profile

• Microservice C for transactions

Each is deployed on separate servers, maybe auto-scaled.
How can they all recognize the same user and maintain consistency in session?

You can’t store session in the memory of just one server (like you might in Tomcat), because:

• Another service won’t have access to it

• Load balancers might route requests to different instances

• It won't survive server restarts

So how do we solve this?

---

🔹 So What Are the Options for Session Management in Microservices?

---

1. Session Stored in Redis (What My Project Uses)

This is what I just learned and found very smart.
To preserve statelessness while still maintaining session, we move session storage outside the micro-services to a centralized, fast, and scalable store like Redis.

Here’s how it works:

• When a user logs in, we create a session object (something like userId, email, maybe roles, etc.)

• We store this session in Redis

• A unique token (like X-Auth-Token) is given to the user

• For every API call, the client sends this token

• Our services read that token, fetch the session data from Redis, and proceed

This works well because:

• All services can access that same session

• Redis is super fast

• We can expire sessions easily

---

2. Session Stored Inside the Server Memory (Not Ideal for Microservices)

This is how old-school monoliths used to work.

• User logs in → session is stored in that specific server’s memory (like in Tomcat)

• If the next request goes to a different server → session is not found

You’d need to either:

• "Stick" the user to one server (called sticky sessions)

• Or build complex APIs to share that session data across services

It becomes a headache as soon as your system grows.

---

3. Stuff Everything in the Token Itself (JWT Approach)

Some systems don’t store sessions at all. Instead, they:

• Create a big, signed token (called JWT) and give it to the client

• That token contains everything the server needs to know (user ID, roles, etc.)

• Every time the client sends the token, the server reads it, trusts it, and moves on

Sounds nice, but here’s the problem:

• You can’t revoke or update a token easily once it’s issued

• If something changes (like user’s role), the token is now outdated

• It can also become too large if you stuff too much info in it

So it works well when you just need basic identity info, but not for large session data