🚫 Why I Hate Sanctum for High-Traffic Applications and How I Overcame It 🚀| Scaling - SWE Blogs

🎮 The Pain of Using Sanctum in a High-Traffic Gaming Platform Profile System

When I first built a profile management system for a gaming platform, I opted for Laravel Sanctum for authentication. It seemed like a solid choice — session-based authentication with HTTP-only cookies, built-in security, and seamless integration with Laravel. However, when the platform launched and users started pouring in, things went south fast. 😓

🚨 The Disaster: Database Overload

Sanctum, by design, validates every request by checking the database for the user’s token. This wasn’t an issue during development or beta testing, but once thousands of gamers started interacting simultaneously, the database got hammered. The system was performing database queries every second just to validate user sessions. The result? 🤯

• Increased latency: Each request had to wait for a DB query. ⏳
• Server slowdowns: The shared database (also serving the main site, admin dashboard, and gaming APIs) struggled under the load. 🐢
• Frequent crashes: Under peak traffic, DB response times skyrocketed, leading to downtime and frustrated users. 🚨

I had built a system that failed under high load. It was a hard lesson in scalability. 📉

🧠 What I Learned from This Failure

After analyzing the problem, I realized three major flaws in my approach:

1. Database-bound Authentication: Checking the database for every request created a significant performance bottleneck. ⚠️
2. Inefficient Token Rotation: Every time a user session extended, the refresh token mechanism triggered unnecessary database writes. ✍️
3. Lack of a Caching Strategy: The system wasn’t leveraging in-memory storage like Redis to reduce DB queries. Even with a caching strategy for token rotation and a refresh token for long logged-in sessions, we still faced challenges. The access token was short-lived, meaning frequent refreshes were required, and for every refresh, the system had to check and write to the database. 🔄

I needed a stateless authentication system that wouldn’t bring down the database. That’s when I decided to switch to JWT. 🏆

💡 Proposed Solutions

1. Database Optimization & Isolation

• Separate Database for Gaming Platform: To reduce contention, the gaming profile system should have its own dedicated database. 🗄️
• Increase Server Resources: Even with database separation, if hosted on the same server, we need to scale up CPU, memory, and disk I/O to maintain reliability. 🏋️‍♂️

2. Implement Efficient Caching Strategy

• Token Storage in Redis: Instead of querying the database on every request, store access tokens in Redis with a TTL (Time-to-Live) of 1–2 hours. ⏱️
• Sliding Expiration: Rather than letting tokens expire all at once, implement a sliding expiration mechanism. This extends the TTL each time the user makes a valid request.
• Sliding Expiration Demystified:
  Unlike fixed expiration, where a token expires at a set time, sliding expiration extends the TTL each time the user makes a valid request. For example, if a token has a TTL of 30 minutes and the user makes a request at the 20-minute mark, the TTL resets to another 30 minutes from that point. This ensures active users don’t get logged out unexpectedly, while preventing inactive sessions from lingering too long. 🔄
• Session Stickiness: Maintain the session in memory cache to avoid repetitive database queries. 🧠

3. Switch to JWT for Stateless Authentication

• JWT (JSON Web Token) eliminates the need for database queries by storing all required claims within the token itself. 🔑
• It uses a secret key or public-private key pair for validation without the need for a database lookup. 🔐
• Reduces write operations, as no token rotation is required. ⛔
• Downside: JWTs cannot be easily revoked unless we implement a blocklist in Redis or use a short TTL. ⚠️

4. Redis Token Blocklist for Secure Token Revocation

Since JWTs are stateless, once issued, they remain valid until expiration unless explicitly revoked. A Redis token blocklist solves this problem by tracking revoked tokens. 🛑

How It Works:

• When a user logs out or an admin revokes access, their JWT or refresh token is added to a Redis blocklist with a TTL matching its remaining validity. 🔒
• On each request, the system checks:

— Is the token expired? → If yes, reject it. ⏳

— Is the token in the Redis blocklist? → If yes, reject it. 🚫

— Otherwise, allow access. ✅

• Once the Redis TTL expires, the blocked token is automatically removed. 🗑️

Advantages:

• Fast Performance: Redis is an in-memory data store, making token lookups and revocations extremely fast. ⚡
• Efficient Memory Usage: Tokens expire naturally, and Redis automatically removes them. ♻️
• Security Improvement: Prevents unauthorized access if a token is compromised. 🔐
• Supports Token Revocation: Unlike standard JWTs, the blocklist provides a mechanism for immediate invalidation. 🔒

🔄 Overcoming the JWT Weakness on Token Revocation

JWTs are stateless, which means once a token is issued, there is no easy way to invalidate it unless it expires. This presents a security challenge — what if a user logs out, or an admin wants to revoke access? The stateless nature of JWTs means that any revoked token would still be valid until expiration. 😔

To overcome this weakness, I implemented a Redis token blocklist. This allows the system to store tokens that need to be explicitly revoked.

• On token revocation: When a user logs out or an admin triggers a revocation, the corresponding JWT or refresh token is added to the Redis blocklist. ❌
• On request: Each time a request is made, the system checks the blocklist to see if the token is invalidated. If the token is in the blocklist, access is denied. 🚫
• Automatic Removal: Once the token’s expiration time has passed in the blocklist, Redis automatically removes it, ensuring that storage usage remains efficient. 🧹

With this solution, revoked tokens are immediately blocked, ensuring that unauthorized access is prevented. 🔒

🏆 Hybrid Approach for Best Performance

After extensive testing, I settled on a hybrid solution to achieve the best of both worlds:

JWT for Web & Mobile Clients:

• No database queries are needed for authentication. 🌐
• Uses HTTP-only cookies for security. 🔐
• Sliding expiration ensures active users stay logged in without sudden expirations. ⏱️

Redis Cache for Access Tokens:

• Reduces DB calls while maintaining security. 🛡️
• Prevents mass expiration spikes that could overload the system. ⚡

Sanctum for Admin & Dashboard Users:

• Secure and controlled access where traffic is lower. 📊

Device Fingerprinting for Extra Security:

• Ensures refresh tokens are bound to a specific device, preventing token theft. 🖥️

🌟 Final Thoughts

Sanctum works great for small applications, but for high-traffic platforms, JWT with Redis caching is the way to go. By removing the database bottleneck, I was able to turn a failing system into a scalable, high-performance authentication solution. ⚡

Lesson learned: Don’t rely on a database-driven authentication system for high-traffic applications. Use JWTs and caching instead. 🚀

JWT is a game changer — offering a stateless solution that reduces database dependency, enhances performance, and provides a more secure and scalable approach for high-traffic systems. 🔑🌍

#laravel #sanctum #jwt #high-traffic #applications