Delving into use cases of Redis/Valkey

Initial Upload 2025-08-24 / Last Modified 2025-08-24

I am a newbie in key–value stores but wanted to share the use cases I learned from the last few weeks of experience.

There are three main use cases of Redis/Valkey: NoSQL, Caching, and Distributed Locking

1. Caching

• Most developers reach for Redis when they need caching. It’s fast, reliable, and works great as a centrally managed data store.

• The most important topics to study (Pareto principle — focus on the vital 20%):

  1. Cache Invalidation & Consistency

     • Write Patterns: Write-through, write-around, and write-behind strategies.
     • Read Patterns: Cache-aside, read-through
     • Event-driven invalidation (pub/sub).
     • Keeping the cache and DB in sync.

  2. Expiration & Eviction

     • TTL strategies
     • Eviction policies(LRU, LFU, etc.) and tuning maxmemory.
     • Preventing cache stampedes

• Q: Invalidation vs. eviction — aren't they the same thing? Why the different terms?

• A: Eviction is the AUTOMATIC removal of a key:value pair (memory limits, TTL expiry, or an eviction policy like LRU/LFU), while invalidation is the EXPLICIT removal of data by the application (triggered by an event, like a DB update, to avoid stale data).

2. NoSQL

• What? You can use Redis as NoSQL? ...I feel you. I had the exact same feeling when I first encountered the concept.
• As traffic grows, many teams choose a key-value store as the primary data store for specific business logic.

When?

• "Amazon 90% discount coupon — first 1,000 customers, first-come, first-served"
• "Rihanna concert ticket reservation"
• "Recording popular ordered items"

Why?

• These have very high request concurrency.
• BUT they also make updates, which cause each request to hold locks on DB rows.
• That makes the database much less scalable.
• One optimization choice is using a key-value store as the primary data store.

How?

• You can choose from many data structures that Redis/Valkey has to offer.
• If you use Redis/Valkey as the main data store, make sure you consider them as the SINGLE SOURCE OF TRUTH.
  • For example, if you keep available stock count both on DB and Redis, it can easily become an antipattern.
  • One way to prevent a complicated situation is to simply remove the column from the DB and only keep it in Redis.

3. Distributed Locking

• I think there are mainly two reasons to use Redis/Valkey distributed locking:
  1. Application Level Lock. DB locks only protect database state; sometimes you need to coordinate operations at the application layer.
  2. Reduce backpressure on the DB.
• Number 2 is less tempting to me, since there are so many other solutions (Kafka, MQ, etc.).
• Number 1 is somewhat tempting, though you can still use other patterns to achieve it.
• Distributed Lock is a safe choice if you have a SINGLE REDIS CLUSTER
  • This is because multiple Redis clusters enforce you to use Redlock, which is an inherently flawed algorithm.