Coder Legion - Recent posts tagged session

Sync Session: Rethinking Session Management in Microservices

Mon, 26 Oct 2026 09:17:47 +0000

Sync Session: Rethinking Session Management in Microservices

Shared storage provides the source of truth. Local caches provide performance. Events synchronize session state across service instances.

Since I started working with microservices in 2016, I have continuously explored and refined different approaches to session management.

One question has remained particularly important to me:

How can every service independently verify a user's session without turning authentication into a bottleneck?

The Challenge: Security vs. Performance

In a microservices architecture, services frequently communicate with one another. From a zero-trust perspective, a service should not blindly trust a userId simply because another service included it in a request.

Instead, each service should validate the session and enforce the appropriate authorization rules.

However, querying a shared database every time a service needs to validate a session can increase latency and database load, especially when requests pass through multiple services.

This creates a practical engineering challenge: how do we preserve session validity and revocation capabilities while reducing the cost of repeated remote access?

That question led me to develop Sync Session, an open-source session management library for Spring Boot.

The Design

The design combines four main components:

RDBMS as shared storage: The persistent source of truth for session state.
Local cache: Each service instance maintains a local copy of session data to reduce repeated database queries.
Event service: Session changes trigger events that allow other service instances to invalidate their corresponding local cache entries.
Session ID propagation: The session ID can be passed through a cookie or HTTP header, depending on the application's request flow.

The session itself is intentionally kept small. Rather than embedding a large amount of user data and permissions into the session, the application uses a protected session ID to retrieve the associated authenticated identity.

User information and authorization data remain under the responsibility of the relevant systems, where they can be updated independently.

This separation helps avoid relying on outdated user information stored in a session and supports centralized session revocation.

What Does This Approach Support?

The project aims to address several practical requirements:

Distributed session management across multiple service instances.
Sliding session expiration, allowing the expiration time to be extended according to the configured policy.
Administrative session revocation, enabling an administrator to force a user to log out.
Synchronization of session invalidation across service instances.
Reduced database access through local caching.

The key idea is that services can validate sessions locally in the common case, while shared storage and event-driven invalidation help coordinate changes.

Performance Reference

In my MySQL load tests, I measured the following results under a workload involving 100 threads and 1 million sessions:

Operation	Measured throughput
Session creation	~15,533 operations/sec
Local cache access	~20.01 million operations/sec
Direct database queries	~69,278 operations/sec

All 1 million session creation operations completed successfully in this test, with no reported failures.

Under these particular test conditions, local cache access achieved approximately 289 times the throughput of direct database queries.

These numbers are reference measurements from my test environment, not universal performance guarantees. The results depend on hardware, database configuration, query patterns, cache implementation, concurrency, and the exact benchmark methodology.

The comparison also measures different access paths, so it should not be interpreted as an end-to-end authentication benchmark.

Consistency and Security Trade-offs

Local caching introduces an important limitation: event-driven invalidation is asynchronous.

When a session is revoked, another service instance may still have a cached copy until it processes the invalidation event. Event delivery failures or temporary network partitions can extend this window.

For security-sensitive systems, this behavior needs to be considered explicitly. Depending on the threat model, additional safeguards may be necessary, such as bounded cache lifetimes, reliable event delivery, recovery mechanisms, or synchronous validation for particularly sensitive operations.

Likewise, validating a session is not the same as authorizing every operation. Services must still enforce their own authorization requirements, and internal service communication must be authenticated appropriately.

The goal is not to claim that local caching removes every security or consistency challenge. It is to explore a practical balance between independent session validation, efficient reads, and distributed session invalidation.

A Design Principle Worth Discussing

The principle behind Sync Session can be summarized as:

Shared storage for correctness. Local cache for performance. Events for synchronization.

This is not the only valid architecture, and it may not be appropriate for every workload. I am sharing it because session management is a recurring challenge in distributed systems, and I believe the trade-offs deserve discussion beyond the implementation of any single library.

I'd especially like to hear from engineers who have built authentication infrastructure at scale:

How do you handle session revocation across multiple service instances?
Would you accept a short invalidation delay, or require immediate revocation for every request?
How do you balance database load, cache consistency, and security requirements?
What failure scenarios would you consider essential to address in this design?

I'm happy to discuss the implementation, benchmark methodology, and architectural trade-offs.

Difference between session and cookies in php

Sun, 20 Sep 2026 07:36:12 +0000

Today, we're going to discuss about two common things, that are Session and Cookies, which are used in the website to keep track of the information provided by the users, but for different purposes. A lot of beginners are confused about their characteristics, functionalities, and differences. In this study blog, we'll explore both of them in a more comprehensive way.

Introduction to Session and Cookies #

Session

Session is used to store information across the multiple pages of a website momentarily on the server-side files. It's useful when the website needs to track who is the current user across multiple pages of the same website. Let's look at the example:
1. A user is using a POST method to send a request to the server for logging in the website.
2. The information provided is sent to the server for validation via HTTP context.
3. However, the HTTP context doesn't maintain the state of a user. As a result, the server is able to validate the current user at the moment only when the request is sent. The other pages are not informed about who is the current user.
4. To overcome this limitation, the server will generate a unique session ID for that particular user and sent back to be stored in the browser in form of Cookie.
5. Whenever the user navigates across different pages, as long as the user is showing the consistent and valid session ID, different pages may recognize the same user.
6. Finally, a session will end and the cookie is deleted (if expiration date is not set) when a user log out or the application is shut down.
Cookies

Cookies is used to remember the user information such as browsing history, user preferences and login credentials on the client-site computer. It can only store maximum of 4KB data in the browser. The server will forget everything about the user such as his/her credentials and activities after the connection breaks. Hence, Cookies are very useful when you want a browser to "remember" the user. Let's look at the example:
1. A user, called "Alex" has chosen Keep me signed in and logged in to a website, his login credentials are stored in a Cookies and the server creates a session ID for him and sent back to the browser.
2. While navigating across multiple pages of the website, he's able to use his unique session ID to verify he's the current user.
3. After a few moment, he feels tired and close the browser.
4. When he comes back again and open the website, the browser will send a request to the server to get the web page, the Cookies belongings to that page will be added to the request via HTTP headers.
5. Since Cookies remembers his login credentials, it'll check the informtion against the server, and thus log in "Alex" automatically.
6. The lifetime of Cookies can be set and it's deleted when its lifetime has passed..
Note Since Cookies are stored on client-site computer, it can only be accessed by the user that initially created it. Other user cannot see it.

Now, we've some basic understanding on what is Session and Cookies. Let's go through their differences.

Difference between Session and Cookies #

Although both are used to track the information provided by the users, they still have some distinct differences. Let's see one by one:

Storage Location #

Session
A Session is stored as server-site files temporarily on the server. It'll be deleted when the application is shut down or the user logged out.
Cookies
A Cookies is stored as a client-site files on the user's computer. It'll be deleted when the expiration date has reached.

Security #

Session
A Session is more secure compare to a Cookies because it's on server-site and cannot be tampered easily. Besides, the data in a Session is encrypted and converted to binary form in the server.
Cookies
A Cookies is less secure because it's stored in the form of string text file on the client's computer. Whenever an unauthorized user get access to the system, he can alter the data easily.
Caution When you choose "Keep me logged in", if someone has stolen the unique identifier in the cookies, it's called cookie stealing and now they can access your account. Always be aware of this option!

Lifetime #

Session
A Session will be deleted once the user logs out or the application is shut down.
Cookies
A Cookies is deleted when the user specified expiration date has passed.

Stored Data Type #

Session
A Session stores the any type of value or the data type of an Object.
Cookies
A Cookies can only stores data in "string" type only.

Purpose of Usage #

Session
A Session is used to track an user's activity over a period of time. It's used to store the specific information of a user which should be consistent across multiple pages of a website. The example can be login status, user preferences, and shopping cart. When a user logs in the website, a session is generated in the server-site and the unique session ID is generated and stored in the user's devices as a cookie.
Cookies
A Cookies are used to store user's information in their computer or mobile device to "remember" their information such as tracking login information, user behavior and storing user preferences. When the next time they visit the same website, the browser'll send the Cookies along with the request to get the web page which compromises of more personalized and desired data for that particular user.

The Conclusion #

In this study blog, we've learned what's Session and Cookies, what are their differences in term of storage location, security, lifetime, stored data type, and purpose of usage. Bear in mind, both of them have their own pros and cons, but Session is more secure compared to Cookies. Hence, you should choose which one to use according to your own condition.

The Reference #

You may go through this reference for more information:

What's Session and Cookies: https://docs.oracle.com/en/middleware/webcenter/sites/12.2.1.3/wbcsd/sessions-and-cookies1.html#GUID-F8F240F3-E769-4B8C-8B7C-3886010D27BE

# How Authentication Really Works (JWT vs Session vs OAuth)

Fri, 17 Apr 2026 06:14:22 +0000

Whenever you log in to a website…

You enter:

Email
Password

And suddenly…

You are “logged in”

But what actually happens behind the scenes?

How does the system remember you?

Let’s break it down simply

First: What is Authentication?

Authentication =

“Proving that you are who you say you are”

Example:

Login form
OTP verification
Google login

⚙️ Basic Flow (Before JWT / Session / OAuth)

User enters email + password
Server verifies credentials
Now server needs to “remember” the user

This is where things get interesting

1. Session-Based Authentication

How It Works

User logs in
Server creates a session
Stores session in database/memory
Sends a session ID to browser (via cookie)

Now:

Every request → sends session ID
Server checks → “Yes, this is the user”

Flow

✅ Pros

Simple to implement
Easy to invalidate (logout)

❌ Cons

Server has to store sessions
Not scalable for large systems

⚡ 2. JWT (JSON Web Token)

How It Works

Instead of storing session on server…

Server gives token to user

This token contains:

User ID
Expiry time
Signature

Example:

header.payload.signature

Now:

Client stores JWT (localStorage / cookie)
Sends it with every request

Server:

Verifies token → allows access

Flow

✅ Pros

Stateless (no server storage)
Scalable
Fast

❌ Cons

Hard to revoke instantly
Needs proper security handling

How It Works

Instead of creating your own login system…

You use another provider

Example:

“Login with Google”
“Login with GitHub”

Flow

User clicks Google login
Redirect to Google
User authenticates
Google sends token back
Your app trusts Google → logs user in

✅ Pros

No need to manage passwords
More secure
Faster user onboarding

❌ Cons

Dependency on third-party
Slightly complex setup

JWT vs Session vs OAuth (Simple Comparison)

Feature	Session	JWT	OAuth
Storage	Server	Client	Third-party
Scalability	Medium	High	High
Complexity	Easy	Medium	Medium-Hard
Use Case	Small apps	APIs / SPAs	Social login

When to Use What?

Small app → Session
Modern API / frontend → JWT
Social login → OAuth

Many apps use combination (JWT + OAuth)

⚠️ Common Mistakes

Storing JWT insecurely ❌
Not setting expiry ❌
Weak session management ❌

Security matters a lot here

Final Thought

Authentication looks simple on UI…

But behind the scenes:

It’s all about trust, identity, and security

As a developer:

Understanding this = real backend skill

Now next time you click “Login”…

You know exactly what’s happening

Coder Legion - Recent posts tagged session

Sync Session: Rethinking Session Management in Microservices

Sync Session: Rethinking Session Management in Microservices

The Challenge: Security vs. Performance

The Design

What Does This Approach Support?

Performance Reference

Consistency and Security Trade-offs

A Design Principle Worth Discussing

Difference between session and cookies in php

Table of Contents:

Introduction to Session and Cookies #

Session

Cookies

Difference between Session and Cookies #

Storage Location #

Session

Cookies

Security #

Session

Cookies

Lifetime #

Session

Cookies

Stored Data Type #

Session

Cookies

Purpose of Usage #

Session

Cookies

The Conclusion #

The Reference #

# How Authentication Really Works (JWT vs Session vs OAuth)

First: What is Authentication?

⚙️ Basic Flow (Before JWT / Session / OAuth)

1. Session-Based Authentication

How It Works

Flow

✅ Pros

❌ Cons

⚡ 2. JWT (JSON Web Token)

How It Works

Flow

✅ Pros

❌ Cons

3. OAuth (Login with Google, GitHub)

How It Works

Flow

✅ Pros

❌ Cons

JWT vs Session vs OAuth (Simple Comparison)

When to Use What?

⚠️ Common Mistakes

Final Thought