Forem: Piyush Kumar Singh

https://dev.to/piyush_kumarsingh_da3833/how-redis-actually-works-ram-single-thread-and-the-expiry-behavior-nobody-explains-2j4n

Piyush Kumar Singh — Sun, 03 May 2026 16:48:10 +0000

Piyush Kumar Singh

May 3

How Redis Actually Works — RAM, Single Thread, and the Expiry Behavior Nobody Explains

#redis #softwareengineering #database #backend

Comments

7 min read

How Redis Actually Works — RAM, Single Thread, and the Expiry Behavior Nobody Explains

Piyush Kumar Singh — Sun, 03 May 2026 16:45:01 +0000

A RAM read takes about 100 nanoseconds. A disk read — even on a modern SSD — takes around 100,000 nanoseconds. That single gap explains most of Redis’s speed, before it does a single thing clever. Friend’s Link

But RAM alone isn’t the full story. The other half is a design decision that looks like a limitation on paper — and turns out to be one of the smartest choices in the codebase. More on that in a moment. Here’s what’s actually happening inside Redis when your app talks to it.

Why is Redis so fast?

The first reason is obvious once you hear it: Redis keeps everything in RAM. Your PostgreSQL instance, however well-tuned, writes to disk. Redis doesn’t. Every key lives in memory, which is why a GET on a Redis key can return in under a millisecond even under load. There’s no disk seek, no page cache miss, no I/O wait. But here’s where most explanations stop — and they shouldn’t.

Single-threaded — and that’s the point

Redis processes one command at a time—one thread. No parallelism, no concurrency. That sounds like a bottleneck. It’s actually a feature.

In a multi-threaded system, shared state requires locks. Locks mean threads waiting on each other. Waiting introduces latency spikes that are hard to reproduce and harder to debug. Redis avoids the entire problem by never having two threads compete for the same data.

# These three clients connect simultaneously
Client 1: SET counter 100     ← executes fully first
Client 2: INCR counter        ← executes next, sees 100, returns 101
Client 3: GET counter         ← executes last, returns 101

The order is deterministic. Always. You can reason about it. With threads and locks, you can’t—not without careful synchronization, which adds complexity and latency.

Redis is fast, not just because of RAM, but because it never waits on itself.

The six data structures — with the tradeoffs that actually matter

Redis isn’t just strings. Each data structure solves a specific problem, and knowing when to pick one over another is more useful than knowing the commands.

String

SET user:1001:name "John"
GET user:1001:name        # "John"
SET page:views 0
INCR page:views           # atomic - safe under concurrent load
GET page:views            # "1"

The default choice for simple values, flags, and counters. INCR is atomic — a thousand clients calling it simultaneously will never produce a wrong count.

Hash

HSET user:1001 name "John" email "j@example.com" role "admin"
HGET user:1001 name       # "John"
HGETALL user:1001         # all fields

A Hash is better than a String when you have a structured object with multiple fields you’ll update independently. If you stored this as a JSON string, updating a single field means deserializing the whole blob, changing one value, and reserializing. A Hash lets you update one field with one command.

List

RPUSH notifications:1001 "Order shipped"
RPUSH notifications:1001 "Payment received"
LRANGE notifications:1001 0 -1   # all items in order
LPOP notifications:1001           # "Order shipped"

Lists maintain insertion order. Use them for notification feeds, activity timelines, and simple job queues where you’re okay with at-most-once delivery. If you need guaranteed delivery, a List isn’t enough — use Kafka or RabbitMQ.

Sorted Set

ZADD leaderboard 9500 "alice"
ZADD leaderboard 11200 "John"
ZREVRANGE leaderboard 0 2 WITHSCORES
# John    11200
# alice   9500

Every member has a score. Redis keeps them sorted automatically. Real-time leaderboards, priority queues, and rate limiting windows — sorted sets handle all three. The reason to reach for this over a List is when rank or score matters, not just insertion order.

Set

SADD online:users "user:1001" "user:1002"
SISMEMBER online:users "user:1002"   # 1 (true)
SCARD online:users                   # 2

No duplicates, O(1) membership check. Good for tracking online users, visited pages, or anything where “is X in this group” is the question. Use a Set over a List when you need uniqueness and don’t care about order.

HyperLogLog

PFADD page:views:home "ip1" "ip2" "ip3" "ip1"
PFCOUNT page:views:home   # 3 (deduplicated)

HyperLogLog gives you approximate unique counts using a fixed 12KB of memory — regardless of whether you have 1,000 or 100 million unique values. A plain Set would work too, but each unique member consumes memory. For a site with 50 million daily visitors, the Set version could eat gigabytes. HyperLogLog stays at 12KB with a ~0.81% error margin. That tradeoff is almost always worth it for analytics.

TTL and the expiry behavior nobody explains

SET session:abc123 "user_data" EX 3600   # expires in 1 hour
TTL session:abc123                        # 3597
# one hour later
GET session:abc123                        # (nil)

Most developers assume Redis runs a background job that scans for expired keys and deletes them at the exact moment of expiry. It doesn’t. That would be expensive — imagine scanning millions of keys every second. Instead, Redis uses two strategies in parallel:

Lazy deletion: When you read a key, Redis checks its expiry first. If it’s expired, Redis deletes it right then and returns nil. Memory is reclaimed at access time, not expiry time.

Active sampling: Every 100ms, Redis randomly picks 20 keys that have TTLs set. If more than 25% of them are expired, it runs the loop again immediately. It keeps looping until the expired ratio drops below 25%.

The consequence: if you have 10 million keys expiring at 3 am and nothing reads them, the active sampler will gradually clean them up over the following minutes. Your memory won’t drop instantly. If you’re sizing Redis memory around key expiry, that lag is real, and you need to account for it.

Persistence — what survives a restart

Redis lives in RAM. Restart the process, lose everything — unless you’ve configured persistence.

RDB snapshots

# redis.conf
save 900 1       # snapshot if 1+ keys changed in 15 minutes
save 300 10      # snapshot if 10+ keys changed in 5 minutes
save 60 10000    # snapshot if 10000+ keys changed in 1 minute

Redis forks a child process and writes everything to dump.rdb. Fast to recover from. The risk: if your server crashes between snapshots, you lose whatever happened in that window. Fine for cache. Not fine for anything where losing recent writes matters.

AOF — Append Only File

# redis.conf
appendonly yes
appendfsync everysec   # flush to disk every second

Every write command gets appended to a log. On restart, Redis replays the log. With every second, you lose at most one second of data. With always, you lose nothing, but your write throughput drops noticeably.

Production setup — use both

save 900 1
appendonly yes
appendfsync everysec

RDB handles fast restarts. AOF handles durability. Together, they cover both failure modes without adding much overhead.

Spring Boot integration — with the why behind the config

Dependencies and connection

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
# application.yml
spring:
  redis:
    host: localhost
    port: 6379
    timeout: 2000ms

RedisTemplate — why you need a custom serializer
By default, Spring uses Java serialization for values. That works, but it stores class names alongside data, making keys unreadable and tying you to your class structure. Switch to JSON serialization so your data is readable outside Spring too:

@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
    RedisTemplate<String, Object> template = new RedisTemplate<>();
    template.setConnectionFactory(factory);
    template.setKeySerializer(new StringRedisSerializer());
    // Jackson JSON instead of Java serialization
    template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
    return template;
}
@Cacheable — the two-line cache layer
Spring’s caching abstraction lets you add Redis caching without touching repository logic. The first call hits the database; every subsequent call with the same ID returns from Redis:

@Cacheable(value = "users", key = "#id")
public User getUserById(Long id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new RuntimeException("User not found"));
}

@CacheEvict(value = "users", key = "#user.id")
public User updateUser(User user) {
    return userRepository.save(user);   // evicts stale cache on update
}
@SpringBootApplication
@EnableCaching   // don't forget this
public class Application { ... }

Rate limiting with sorted sets
A sliding window rate limiter is one of Redis’s cleanest use cases. The sorted set score is the timestamp — so you can count requests within a time window with a range query:

public boolean isAllowed(String userId, int maxRequests, long windowSeconds) {
    String key = "ratelimit:" + userId;
    long now = System.currentTimeMillis();
    long windowStart = now - (windowSeconds * 1000);
    ZSetOperations<String, String> ops = redisTemplate.opsForZSet();
    ops.removeRangeByScore(key, 0, windowStart);   // drop old requests
    Long count = ops.zCard(key);
    if (count != null && count >= maxRequests) return false;
    ops.add(key, String.valueOf(now), now);
    redisTemplate.expire(key, windowSeconds, TimeUnit.SECONDS);
    return true;
}

When your tech lead says “add Redis,” — ask this first

**
There’s a version of this story everyone knows: the tech lead says “add Redis,” you add Redis, and something gets faster. Nobody questions it. But Redis has real constraints, and using it wrong is a common way to create problems that look like infrastructure issues.

Don’t use it as your primary database. Redis has no foreign keys, no joins, no complex queries. If your data has relationships, use a relational database. Redis is the layer on top, not the foundation.

Don’t store large values. Redis works well with small, hot data. A 5MB JSON blob in Redis is possible and wasteful — you’re burning expensive RAM, hurting the event loop for every other client, and making serialization your bottleneck.

Don’t use pub/sub for anything you can’t afford to lose. Redis pub/sub has no persistence. If a subscriber goes offline for 30 seconds, those messages are gone. Use Kafka or RabbitMQ when reliability matters.

Set a memory limit and eviction policy — always. Without it, Redis will reject writes when it runs out of memory, and that failure mode is jarring in production:

# redis.conf
maxmemory 2gb
maxmemory-policy allkeys-lru   # evict least recently used keys when full
**

## ```


The one line that ties it all together
**
Redis is fast because it stays in RAM and never waits for itself. Use it for caching, sessions, leaderboards, rate limiting, and lightweight pub/sub, where dropped messages are acceptable. Don’t ask it to be your source of truth. Understand those two constraints, and Redis stops being magic — it becomes a predictable tool that does exactly what you’d expect. That’s a good thing.

How Spring Security Works Internally (Filters, Authentication & Authorization Explained)

Piyush Kumar Singh — Sat, 02 May 2026 16:57:49 +0000

If you have worked with Spring Boot for a while, you have used Spring Security without fully tracing what happens inside it.

You add a dependency, configure a SecurityFilterChain, and wire a UserDetailsService, and your APIs are suddenly protected. It works. But under the hood, there is a very disciplined flow that decides who the user is, whether the password is valid, and whether the request should even reach your controller.

Once that internal flow clicks, Spring Security stops feeling magical and starts feeling predictable.

The Big Picture

Every incoming HTTP request does not go straight to your controller. Before that request reaches DispatcherServlet, it passes through the servlet filter chain. Spring Security plugs itself into that chain and intercepts the request early.

That matters because security decisions should happen before business logic runs. The flow looks like this:

That is the full security journey in one line: intercept, authenticate, authorize, then continue.

Step 1: The Request Enters the Servlet Filter Chain
When a client sends a request, Tomcat receives it first. Tomcat then passes it through a chain of servlet filters.

These filters are not specific to Spring Security. They are part of the servlet infrastructure. Any framework can register filters here. Spring Security registers one important filter called FilterChainProxy.

You can think of FilterChainProxy as the front desk for all Spring Security logic. It does not do all the security work itself. Instead, it decides which internal security filters should handle the request.

Step 2: FilterChainProxy Picks the Right SecurityFilterChain
This is a key part that many developers miss. Spring Security does not always use one universal chain for every request. It can maintain multiple SecurityFilterChain configurations, each tied to different URL patterns or request matchers.

For example:

/api/** may use JWT authentication
/admin/** may require stricter role checks
/login may use a form login
FilterChainProxy checks the request and selects the correct chain using RequestMatcher. That means Spring Security is not just a collection of filters. It is a smart router for security filters.

Step 3: Authentication Filter Extracts Credentials
Once the correct security chain is selected, one of the authentication filters takes over. In the classic username-password login flow, that filter is usually UsernamePasswordAuthenticationFilter.

Its job is simple:

Read the username and password from the request
Create an unauthenticated Authentication object
Pass that object to AuthenticationManager
At this point, the user is not yet trusted. The filter has only collected credentials. Verification still has to happen. This distinction is important. Extracting credentials and validating credentials are two separate responsibilities.

Step 4: AuthenticationManager Coordinates Authentication
AuthenticationManager is the entry point for authentication logic. In most applications, the default implementation is ProviderManager.

ProviderManager does not usually authenticate the user directly. Instead, it delegates to one of the configured AuthenticationProvider implementations. That design makes Spring Security flexible. Different providers can handle different authentication mechanisms:

username and password
JWT token
OAuth2 login
LDAP
custom authentication rules
When ProviderManager receives an authentication object, it loops through the registered providers and calls supports() on each one.

The first provider that says, “Yes, I know how to handle this type of authentication,” gets the job. Then authenticate() is called on that provider.

Step 5: AuthenticationProvider Verifies the User
This is where the real authentication work happens. For username-password login, the provider is often DaoAuthenticationProvider.

Its job usually includes two things:

Load the user from a data source
Validate the submitted password
To load the user, it calls UserDetailsService.

To validate the password, it uses PasswordEncoder.

This split is one of the reasons Spring Security is so clean internally. Fetching user data and checking password hashing are handled by dedicated components, not mixed into one giant class.

Step 6: UserDetailsService Loads the User From the Database
UserDetailsService is a very small but important contract.

Its core method is:

loadUserByUsername(String username)
This method is responsible for fetching the user from your database, external system, or custom source. It returns a UserDetails object that contains:

username
password
roles or authorities
account status flags, such as locked or disabled
If the user is not found, Spring Security throws an exception, and authentication fails. At this stage, the system now knows what the stored user record looks like. Next, it needs to compare the password.

Step 7: PasswordEncoder Validates the Password
Spring Security does not compare raw passwords directly. Instead, it uses a PasswordEncoder such as BCryptPasswordEncoder.

Here is the idea:

The password submitted by the client is plain text
The stored password in the database is hashed
PasswordEncoder.matches(rawPassword, encodedPassword) checks if they match safely
If the password is wrong, authentication fails.

If it matches, Spring Security creates a fully authenticated Authentication object containing the user’s identity and authorities. That object is now trusted.

Step 8: SecurityContextHolder Stores the Authenticated User
Once authentication succeeds, Spring Security stores the authenticated user in SecurityContextHolder.

This is what makes the user available for the rest of the request lifecycle.

From here, other parts of the application can access the logged-in user through:

SecurityContextHolder.getContext().getAuthentication()
@AuthenticationPrincipal
Principal in controllers
In a regular servlet application, this security context is usually stored per request thread. That is why the controller can later know who the current user is without manually passing user details around.

Step 9: Authorization Happens Before the Controller
Authentication answers this question: Who are you?

Authorization answers this one: What are you allowed to do?

After the user is authenticated, Spring Security moves to authorization filters such as AuthorizationFilter.

This stage checks whether the current user has the required role, authority, or permission for the requested resource.

Examples:

hasRole(“ADMIN”)
hasAuthority(“PAYMENT_READ”)
Request matchers that restrict endpoints
If authorization fails, Spring Security stops the request and returns an error such as 403 Forbidden. If authorization succeeds, the request continues.

Step 10: The Request Reaches DispatcherServlet and Then the Controller
Only after authentication and authorization are complete does the request proceed to Spring MVC. Now, DispatcherServlet can route the request to the correct controller.

At this point, your controller can safely assume one of two things:

The endpoint is public, or
The user has already been authenticated and authorized
That separation is why controllers stay cleaner. Security is handled earlier in the pipeline instead of being scattered across business logic.

What Happens If Authentication Fails?
If authentication fails anywhere in the chain, Spring Security throws an authentication-related exception.

Common outcomes include:

401 Unauthorized for unauthenticated access
Redirect to the login page in form-based login
custom error response in REST APIs
The controller is never called.

This is a useful mental model: failed authentication stops the request before business logic begins.

What Makes Spring Security Feel Complex?
Usually, it is not the concepts. It is the number of moving parts.

There are many classes involved:

FilterChainProxy
SecurityFilterChain
UsernamePasswordAuthenticationFilter
AuthenticationManager
ProviderManager
AuthenticationProvider
UserDetailsService
PasswordEncoder
SecurityContextHolder
AuthorizationFilter At first glance, that looks like a lot.

But if you group them by responsibility, it becomes manageable:

_Filters _handle request interception
_Manager _and providers handle authentication delegation
_UserDetailsService _and PasswordEncoder validate identity
_SecurityContextHolder _stores the authenticated user
_Authorization _filters enforce access rules
That is really the whole story.

A Simple Way to Remember the Flow

Use this line:

Request comes in -> filter intercepts -> credentials extracted -> manager delegates -> provider authenticates -> context stores user -> authorization checks access -> controller runs

If you remember that sentence, you already understand the internals better than many developers who use Spring Security every day.

Final Takeaway

Spring Security works like a layered checkpoint system. It intercepts the request before your application code sees it, verifies identity using providers and encoders, stores the authenticated user in a security context, checks permissions, and only then allows the request to hit the controller. Once you understand that flow, the framework feels a lot less intimidating.