JWT vs session-based decision in Spring Boot - Performance Comparison

Performance: JWT vs session-based decision

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by influencing server load, network payload size, and client-side processing.

Managing user authentication state efficiently

Spring Boot

Use JWT tokens stored client-side and sent with each request, avoiding server session storage.

Reduces server memory usage and session lookup delays by shifting state to client, improving scalability.

📈 Performance GainSaves server memory; reduces server response blocking; adds ~1-2kb payload per request.

Managing user authentication state efficiently

Spring Boot

Use server-side sessions storing user data in memory for every request without caching or load balancing.

This causes high server memory usage and can slow down response times under heavy load due to session lookups.

📉 Performance CostIncreases server memory usage linearly with users; can block response for 10-50ms per session lookup under load.

Performance Comparison

Pattern	Server Memory Usage	Network Payload	Response Delay	Verdict
Session-based	High (stores sessions per user)	Small (session ID only)	Medium (session lookup delay)	[OK]
JWT-based	Low (stateless server)	Medium (token with claims)	Low (no session lookup)	[OK] Good

Rendering Pipeline

Authentication state management affects server response time and network payload, influencing how fast the browser receives and processes content.

→Network

→Server Processing

→Client Parsing

⚠️ BottleneckServer Processing for session lookups or Network for large JWT payloads

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by influencing server load, network payload size, and client-side processing.

Optimization Tips

1Use JWTs to reduce server memory and improve scalability.

2Keep JWT payloads small to minimize network latency.

3Use sessions for smaller network payloads but watch server memory and lookup delays.

Performance Quiz - 3 Questions

Which authentication method reduces server memory usage the most?

A Using cookies without tokens

B Session-based authentication

C JWT-based authentication

D Storing sessions in database

DevTools: Network

How to check: Open DevTools, go to Network tab, inspect request headers for Authorization token size and timing.

What to look for: Look at request size and time to see if JWT payload is large or if session cookies are small and fast.

Practice

1. Which statement best describes JWT authentication in Spring Boot?

easy

A. User info is stored on the server and tracked with cookies.

B. User info is stored only in the database without tokens or sessions.

C. User info is stored in a token sent with each request, no server storage needed.

D. User info is stored in browser local storage only.

Solution

1. Step 1: Understand JWT storage method

   JWT stores user information inside a token that is sent with every request, so the server does not need to keep session data.

2. Step 2: Compare with session storage

   Sessions store user info on the server and use cookies to track users, unlike JWT which is stateless.

3. Final Answer:

   User info is stored in a token sent with each request, no server storage needed. -> Option C

4. Quick Check:

   JWT = token-based stateless auth [OK]

Hint: JWT stores info in tokens, sessions store on server [OK]

Common Mistakes:

• Confusing JWT with session storage
• Thinking JWT requires server-side storage
• Believing JWT info is only in browser storage

2. Which code snippet correctly sets a session attribute in Spring Boot?

easy

A. request.getSession().setAttribute("user", userObject);

B. request.setSessionAttribute("user", userObject);

C. session.setAttribute("user", userObject);

D. request.session().setAttribute("user", userObject);

Solution

1. Step 1: Recall correct method to get session

   In Spring Boot, you get the session from the request using request.getSession().

2. Step 2: Set attribute on session object

   Then call setAttribute("user", userObject) on the session to store data.

3. Final Answer:

   request.getSession().setAttribute("user", userObject); -> Option A

4. Quick Check:

   Use getSession() then setAttribute() [OK]

Hint: Use request.getSession() before setAttribute [OK]

Common Mistakes:

• Calling setAttribute directly on request
• Using incorrect method names like setSessionAttribute
• Trying to call session() as a method on request

3. Given this Spring Boot code snippet using JWT, what is the expected behavior?

String token = jwtUtil.generateToken(userDetails);
response.setHeader("Authorization", "Bearer " + token);
// No session is created on server

medium

A. User info is stored on server session and token is ignored.

B. Token is sent to client; server remains stateless without session.

C. Session is created on server with token stored inside.

D. Token is stored in server memory for each user.

Solution

1. Step 1: Analyze token generation and response header

   The code generates a JWT token and sends it in the Authorization header to the client.

2. Step 2: Note server session behavior

   The comment says no session is created on the server, meaning the server stays stateless.

3. Final Answer:

   Token is sent to client; server remains stateless without session. -> Option B

4. Quick Check:

   JWT = stateless token sent to client [OK]

Hint: JWT sends token, no server session created [OK]

Common Mistakes:

• Assuming server stores token in session
• Thinking token is ignored by server
• Believing token is stored in server memory

4. Identify the error in this Spring Boot session code snippet:

HttpSession session = request.getSession(false);
session.setAttribute("user", userObject);

medium

A. Session attributes cannot store user objects.

B. setAttribute method does not exist on HttpSession.

C. request.getSession(false) always creates a new session.

D. Using getSession(false) may return null causing NullPointerException.

Solution

1. Step 1: Understand getSession(false) behavior

   getSession(false) returns existing session or null if none exists; it does not create a new session.

2. Step 2: Check for possible null usage

   If session is null, calling setAttribute causes NullPointerException.

3. Final Answer:

   Using getSession(false) may return null causing NullPointerException. -> Option D

4. Quick Check:

   getSession(false) can return null [OK]

Hint: getSession(false) may return null, check before use [OK]

Common Mistakes:

• Assuming getSession(false) always returns a session
• Believing setAttribute is invalid method
• Thinking sessions cannot store objects

5. You are building a Spring Boot app that must scale across many servers without sticky sessions. Which authentication method should you choose and why?

hard

A. Use JWT because it is stateless and does not require server session storage.

B. Use JWT but store tokens in server memory for faster access.

C. Use session-based authentication with distributed cache to share sessions.

D. Use session-based authentication because it stores user info on the server.

Solution

1. Step 1: Understand scaling needs

   Scaling across many servers without sticky sessions means no single server holds user session data.

2. Step 2: Compare authentication methods

   Session-based auth stores user info on server, requiring session sharing or sticky sessions, which complicates scaling.

3. Step 3: Choose JWT for statelessness

   JWT stores user info in tokens sent with requests, so servers remain stateless and scaling is easier.

4. Final Answer:

   Use JWT because it is stateless and does not require server session storage. -> Option A

5. Quick Check:

   Stateless JWT best for scalable multi-server apps [OK]

Hint: Stateless JWT fits multi-server scaling best [OK]

Common Mistakes:

• Choosing sessions without sticky sessions or shared cache
• Thinking JWT requires server memory storage
• Ignoring stateless benefits of JWT