Cache-aside, write-through, and write-behind patterns with Redis — session storage, rate limiting, pub/sub, and TTL strategies for production web apps
Why Caching Changes Everything
Database queries are expensive. A typical PostgreSQL query takes 5–50ms. A Redis cache lookup takes 0.1–0.5ms. For endpoints called thousands of times per minute, caching transforms your application from sluggish to instant.
Redis is an in-memory data store that supports strings, hashes, lists, sets, sorted sets, and streams. It is not just a cache — it is a Swiss Army knife for high-performance data patterns. At The Beyond Horizon, we use Redis in nearly every production deployment.
Cache-Aside Pattern
The cache-aside pattern (also called lazy loading) is the most common caching strategy. The application checks Redis first. If the data exists (cache hit), return it. If not (cache miss), query the database, store the result in Redis with a TTL, and return it.
Implementation
Your data fetching function first calls redis.get(key). If the result exists, parse and return it. Otherwise, query the database, store the result with redis.set(key, JSON.stringify(data), “EX”, ttlSeconds), and return the data.
When to Use
Read-heavy workloads where the same data is requested frequently
Data that does not change often (user profiles, product listings, configuration)
When stale data is acceptable for a short window
Write-Through Pattern
In the write-through pattern, every write to the database simultaneously updates the cache. This ensures the cache is always consistent with the database — no stale data window.
When creating or updating a record, you write to the database first, then immediately set the value in Redis. This eliminates cache misses for recently written data at the cost of slightly slower writes.
Data that is read immediately after writing (social media posts, order status)
When cache consistency is more important than write latency
Applications with predictable access patterns
Write-Behind Pattern
The write-behind (write-back) pattern writes to Redis first and asynchronously persists to the database later. This provides the fastest write performance but introduces the risk of data loss if Redis fails before the database write completes.
When to Use
High-throughput write workloads (analytics events, activity logging)
Write on Medium
When write latency is critical and eventual consistency is acceptable
Batch processing where individual writes can be grouped
Storing user sessions in Redis is one of the most impactful quick wins for web applications. Unlike file-based or database-backed sessions, Redis sessions are fast, shared across multiple server instances, and automatically expire.
Use a session library like connect-redis with Express or iron-session with Next.js. Store the session ID in an httpOnly secure cookie and the session data in Redis with a TTL matching your desired session duration.
Redis is ideal for rate limiting API endpoints. The sliding window pattern uses a sorted set where each request adds an entry with the current timestamp as the score. Count entries within the last N seconds to determine if the limit is exceeded.
For simpler token bucket rate limiting, use Redis INCR with EXPIRE. Increment a counter keyed by the user’s IP or API key. If the counter exceeds the limit, reject the request. The EXPIRE ensures the counter resets after the window.
Redis Pub/Sub enables real-time messaging between services. A chat message published to a channel is instantly delivered to all subscribers. This powers features like:
Live notifications across multiple server instances
Real-time dashboard updates
Cache invalidation broadcasts (one server invalidates, all servers clear the stale entry)
TTL Strategies
Setting the right TTL (time-to-live) is an art:
Static content: (site configuration, feature flags): 1–24 hours
User profiles: 5–15 minutes
API responses: 30 seconds to 5 minutes
Search results: 1–5 minutes
Session data: Match your session timeout (typically 24 hours to 7 days)
When in doubt, start with shorter TTLs and increase based on observed cache hit rates and data freshness requirements.
Redis with Next.js
In Next.js applications, Redis integrates at multiple layers. Use it in API routes for response caching and rate limiting. Use it in server components with unstable_cache for data layer caching. Use it with Next.js middleware for session validation and geographic routing.
Our preferred Redis hosting is Upstash for serverless workloads (pay per request, global replication) and Redis Cloud for dedicated instances with higher throughput requirements.
Caching is not an optimization — it is an architecture decision. Want to build a high-performance application? Talk to us.
Originally published at https://www.thebeyondhorizon.com on August 19, 2025
