Distributed Systems··
Redis Caching Without Surprises
Notes on cache-aside, expiration, hot keys, invalidation, and choosing when a cache truly belongs in the architecture.
Redis is powerful when it has a clear job. The hard part is not putting data into a cache. It is knowing when cached data becomes wrong.
Cache-aside
Cache-aside keeps the application in control: read from Redis first, fall back to the database, then populate the cache.
Expiration and invalidation
Every cached value should have an expiration policy. For data that changes often, invalidation needs to be part of the write path.
Hot keys
Popular keys can become pressure points. Watch access patterns and design keys so a single value does not quietly become a bottleneck.
Related work and writing
projectSpring Service LabA production-minded Spring Boot service used to practice API design, persistence, caching, security, and operational boundaries.blogMySQL Indexes: From a Slow Query to a Better B+ TreeTracing one slow query through execution plans, composite indexes, selectivity, and the tradeoffs behind faster reads.projectLocal Development StackA repeatable Docker Compose environment for the website API, MySQL, and Redis with explicit health checks.