Redis
7.xSummary
In-memory key-value store with optional persistence, supporting strings, hashes, lists, sets, sorted sets, and pub/sub.
Primary Use Case
Application-layer caching, session storage, rate limiting, leaderboards, and lightweight pub/sub messaging.
Workload Fit
Strengths
Best for
- ·Application-layer caching to absorb read load from primary datastores
- ·Session storage requiring sub-millisecond access latency
- ·Rate limiting and throttling with atomic increment operations
- ·Leaderboards and sorted sets via ZADD/ZRANGE
Excels when
- ·Data fits in memory and cache hit rate stays above 90%
- ·Access patterns are key-based with no complex queries
- ·Workload tolerates eventual consistency on cache misses
Architectural advantages
- ·Sub-millisecond latency dramatically reduces database read pressure
- ·Atomic data structures (sorted sets, HyperLogLog) enable complex operations without application-layer coordination
- ·Pub/sub provides simple decoupling for lightweight event fan-out
When to Avoid
Avoid when
- ·Data must be durable with strong persistence guarantees: Redis is a cache, not a database
- ·Object sizes regularly exceed 1MB: single-threaded processing causes latency spikes
- ·Total dataset exceeds available RAM across all nodes
Common misuses
- ·Using Redis as the primary database for business-critical data: durability is not guaranteed
- ·Storing session data without TTLs: unbounded key growth causes OOM eviction
- ·Applying cache-aside without stampede protection: cold cache spikes overwhelm the backend
Consistency & Transactions
Scaling
Read scalability
Read replicas scale read throughput horizontally. Redis Cluster shards keyspace across nodes for write and memory scaling.
Write scalability
Single-threaded command processing on a single node. Redis 6+ uses I/O threads for reads, but writes remain single-threaded. Redis Cluster shards writes across multiple primaries.
Failure Behavior
Known failure modes
- ·Memory eviction under OOM: LRU eviction silently drops cache entries
- ·Async replication data loss: replication is asynchronous; failover can lose recent writes
- ·Split-brain in Redis Cluster under network partition
- ·Cold cache thundering herd: cache miss storm after restart or flush
Bottlenecks
- ·Single-threaded write path: CPU-bound on a single core for write-heavy workloads
- ·Memory bound: cannot hold more data than RAM across the cluster
- ·Large key scanning (KEYS *, SMEMBERS on large sets) blocks the event loop
Degradation patterns
- ·Memory eviction (LRU/LFU) silently degrades cache hit rate as dataset grows
- ·AOF persistence with fsync=always halves write throughput
- ·Cluster rebalancing under node addition causes temporary latency spikes
Recovery considerations
- ·RDB snapshots are point-in-time; writes between snapshots are lost on crash
- ·AOF + RDB hybrid provides best recovery guarantees but increases disk I/O
- ·Redis Cluster failover requires quorum and takes 5-15 seconds by default
Operational Pitfalls
- ·Not setting maxmemory and maxmemory-policy: unbounded growth causes OOM and process crash
- ·Storing large objects (>1MB): large payloads block the single-threaded event loop
- ·Using Redis as a primary database: persistence is not designed for durability guarantees
- ·Not monitoring eviction rate: high eviction rate means the cache is too small
Architecture Guidance
Common topology roles
Migration notes
- ·Migrating away from Redis: audit all patterns that rely on atomic operations: application-layer replacements add complexity
- ·Moving to Redis Cluster: key hash slot distribution breaks MGET/MSET on keys in different slots
- ·Upgrading source_available to commercial Redis: evaluate operational overhead vs managed cloud options
Advisor Guidance
When: scenario has read_heavy workload with high cache miss risk
Implement cache stampede protection (probabilistic early expiry or locking) to prevent thundering herd on cold start
When: scenario relies on Redis for data that cannot be re-derived
Redis is not a durable store: add persistence layer or treat Redis as expendable cache only
When: scenario stores session data in Redis
Set TTLs on all session keys; monitor eviction rate as leading indicator of cache undersizing
Comparison Factors
operational complexity
Low: managed options reduce ops burden to near-zero
latency
Sub-millisecond: lowest latency of any tier in a typical stack
durability
Configurable but weak: not a substitute for a durable datastore
cost
Low: in-memory instances are small; cost scales with dataset size
Managed Cloud Options
Enables Patterns
Basis
Ubiquitous technology with well-understood operational characteristics
Learning Modules
Cache Invalidation
Why cache invalidation is hard, how stale data propagates, how invalidation failures cause cache poisoning, and how to design invalidation-safe patterns.
CAP Theorem and PACELC
Why distributed systems cannot simultaneously provide consistency, availability, and partition tolerance: and how PACELC extends this to the latency-consistency tradeoff that applies even when the network is healthy.
Consistency Models in Distributed Systems
The consistency spectrum from linearizability to eventual consistencywhat each model guarantees, which real systems implement each model, and how to design application code for the consistency level your infrastructure provides.
Replication Lag
How primary-replica replication lag forms, accumulates under write pressure, causes stale reads, and how applications should handle it.
Evolution Paths
Direct DB Queries → CQRS Read Models
Unified Read/Write Database → CQRS with Separate Read Projections
Single Cache Layer → Distributed Cache
Single Redis Node / Sentinel Cluster → Distributed Redis Cluster (Consistent Hash Ring)
Single Region → Multi-Region Replication
Single-Region Deployment → Multi-Region Replication
Simulations
Related Architecture Knowledge
Outbound: this entity affects
Redis sorted sets are the standard implementation substrate for fan-out-on-write news feed architectures. Each user's feed is a sorted set keyed by user_id, with post IDs scored by timestamp, enabling O(log N) per-follower write and O(1) feed reads with ZREVRANGE.
Tradeoffs
- ·Fan-out-on-write requires Redis memory proportional to total_users * avg_feed_size
- ·High follower accounts create write hotspots: requires hybrid fan-out strategy
- ·Deleted posts require a compensating fan-out sweep to remove the post ID from all follower feeds
Redis clients hold persistent TCP connections per thread or goroutine. Under connection pool misconfiguration or sudden traffic spikes, the Redis server can exhaust its maxclients limit, causing cascading cache misses that amplify load on the primary database.
Tradeoffs
- ·Mitigation (client-side pooling) adds configuration complexity
- ·Proxy layer adds latency and another failure point
Redis caching absorbs repeated read requests at the edge, reducing database load and latency for high read-to-write ratio workloads by orders of magnitude.
Tradeoffs
- ·Introduces eventual consistency: stale reads possible within TTL window
- ·Requires cache invalidation logic on writes; invalid on every schema change
- ·Increases operational surface: Redis must be sized, monitored, and replicated
Redis distributed locks (via SET NX EX or Redlock) prevent thundering herd by ensuring only one caller repopulates a cache entry at a time, with other callers either waiting or returning a stale value until the cache is warm.
Tradeoffs
- ·Distributed locking adds one Redis round-trip to every cache miss that triggers population
- ·If the lock holder crashes mid-population, the lock TTL must expire before recovery: causing a cache gap
- ·Redlock (multi-node locking) adds complexity: for most cache stampede cases, single-node SET NX is sufficient
Redis atomic increment (INCR) with TTL (EXPIRE) is the standard implementation for sliding window and token bucket rate limiting, providing sub-millisecond rate limit enforcement.
Full relationship →Redis is itself vulnerable to thundering herd when it restarts or flushes: all cache entries expire simultaneously, and many concurrent requests all miss and race to repopulate the same keys from the database, causing a stampede that can overwhelm the downstream database.
Tradeoffs
- ·Pre-warming requires either a warm replica or a cache loader process: adds operational complexity
- ·Jitter reduces synchronized expiry risk but requires all cache writers to implement TTL jitter
- ·Redis Cluster (with replicas) reduces but does not eliminate cold-start risk: slot resharding warms new nodes
Inbound: affects this entity
NATS provides durable messaging with JetStream; Redis provides in-memory caching and pub/sub. NATS is used for reliable event delivery; Redis is used for low-latency session state and rate limiting, with both used in the same application stack.
Full relationship →Read-heavy APIs benefit directly from Redis as a caching tier that absorbs repeated identical reads and provides sub-millisecond response times for hot data, reducing both latency and database load.
Tradeoffs
- ·Additional infrastructure to operate, monitor, and scale
- ·Consistency guarantees weaken: reads may return stale data within TTL
- ·Cache stampedes possible on TTL expiry of high-traffic keys
Used In Architecture Scenarios
AI / RAG Application
A Retrieval-Augmented Generation (RAG) architecture that combines vector similarity search for semantic document retrieval with relational metadata filtering, using PostgreSQL with pgvector as the unified store for both embeddings and structured data. Redis provides a semantic cache to avoid redundant embedding model inference and reduce vector index query load for repeated or similar queries. Kafka manages the asynchronous embedding generation pipeline that keeps the vector index current as source documents are added or updated.
Multi-Tenant SaaS
A multi-tenant API gateway providing authentication, distributed rate limiting, request routing, payload transformation, and per-tenant usage analytics for API publishers. The hot path: authentication check, rate limit evaluation, and routing decision: must complete in under 1ms using Redis-only data structures to avoid proxying latency dominating upstream service response time. PostgreSQL stores tenant configuration, subscription plans, and API key definitions. Kafka receives API usage events for downstream billing and analytics. Configuration changes (rate limit updates, routing rule edits) must propagate to all gateway replicas without restart.
Financial Ledger
An append-only audit log architecture for capturing system actions: user operations, data access events, configuration changes, and financial operations: with cryptographic integrity chaining, immutable storage, and dual-path query serving. PostgreSQL stores the authoritative append-only event log in time-partitioned tables; ClickHouse serves historical aggregate queries and retention analytics; Kafka streams audit events in real time to SIEM integrations and security dashboards; Redis caches hot audit query results for compliance-facing read paths. No record is ever updated or deleted: only inserts are permitted. Each record includes a hash of the previous record, forming a tamper-evident chain verifiable without external tooling.
Read-Heavy Application
A CMS for publishing and serving structured content: articles, documentation, product pages, and localized variants: where read APIs serve 50–100x more traffic than editorial write APIs. PostgreSQL stores the content graph (articles, authors, categories, taxonomy) and workflow state (draft, in-review, scheduled, published). Redis caches published content objects for read APIs. Elasticsearch powers full-text content search with faceting and relevance ranking. Cache invalidation on publish must be fast and complete; N+1 query patterns on content relationship traversal are the dominant database performance risk during reads.
Multi-Tenant SaaS
A multi-tenant developer tooling platform providing CI/CD pipeline execution, log aggregation, code analysis, and dependency scanning across isolated tenant organizations. Tenant isolation is the primary correctness constraint: a security boundary violation between tenants is a critical incident, not a performance event. PostgreSQL row-level security enforces data isolation; Redis manages job queues and distributed locks; Elasticsearch indexes pipeline log output for search; Kafka delivers webhook events to tenant-registered endpoints; MinIO stores pipeline artifacts. Resource quota enforcement prevents any single tenant's burst from affecting others.
Write-Heavy Application
A durable background job execution platform where jobs are enqueued via API and executed by competing consumer worker pools. PostgreSQL is the durable job store, job definitions, retry state, scheduling metadata, and dead-letter records persist in PostgreSQL with ACID guarantees, surviving any worker or queue infrastructure failure. Redis tracks in-flight job state (which worker claimed which job, visibility timeout lease expiry) to enable fast lease checks without PostgreSQL queries on the hot path. Temporal provides workflow orchestration for multi-step jobs that require coordination across multiple execution stages, with built-in state machine semantics and durable activity execution. Kafka carries job completion events to downstream consumers (analytics, billing triggers, notification fan-out). Backpressure between the job enqueue rate and worker execution rate prevents runaway job accumulation when workers are degraded.
Marketplace Platform
An e-commerce order lifecycle platform handling cart, checkout, payment, fulfillment, and returns across a mixed read/write workload where product discovery is read-heavy, checkout is write-transactional, and fulfillment is event-driven. The saga pattern orchestrates multi-step checkout: reserve inventory → charge payment → confirm order → notify fulfillment. PostgreSQL owns order records and inventory with row-level locking; Redis holds session state and cart contents with sub-millisecond access; RabbitMQ delivers fulfillment notifications with dead-letter handling; Elasticsearch serves product search and order history with faceted navigation. CQRS separates the write command path from the read model: the order read model is denormalized for fast order history queries without joining across domain tables.
Realtime Collaboration
An online multiplayer game backend built around authoritative server game state synchronization. Game rooms run as distributed state machines where the server is the single source of truth for game state: client predictions are reconciled against the server state at every tick. WebSocket connections provide low-latency bidirectional communication for state deltas. Redis stores active game room state (in-flight, with sub-millisecond access), session affinity tokens (routing players to the same server instance as their game room), and matchmaking queues. PostgreSQL is the durable store for player profiles, persistent inventory, leaderboards, and achievement records. Kafka carries post-game event streams for analytics, anti-cheat processing, and achievement evaluation. NATS provides low-latency pub/sub for intra-cluster game state broadcasting when multiple game server instances must coordinate on shared state. Event sourcing records every game action as an immutable event for replay, dispute resolution, and anti-cheat audit.
Realtime Collaboration
A real-time location tracking platform for moving entities: vehicles, delivery couriers, field workers, and assets: receiving position updates at 1–30 second intervals from thousands of simultaneously tracked objects. Redis geospatial indexes (GEOADD / GEOSEARCH) serve sub-10ms proximity queries against the live position surface; PostgreSQL stores durable entity metadata and historical location records; TimescaleDB stores high-frequency time-series location data with automatic hypertable chunking and retention policies; Kafka streams location events to downstream consumers (dispatch systems, customer tracking apps, analytics pipelines). Geofence evaluation runs at ingestion time: each incoming position update is tested against active geofences for the entity's region, and geofence entry/exit events are emitted as Kafka messages to downstream consumers.
Financial Ledger
An electronic health record (EHR) architecture built around strict auditability, HIPAA compliance, and append-only correctness. Clinical records are mutable by design (amendments, addenda) but corrections must be explicitly attributed, not silently overwritten. Event sourcing provides a reconstructable audit log; PostgreSQL row-level security enforces patient-level access control at the database layer; Kafka streams HL7 FHIR events to downstream clinical systems. The architecture must support breach detection, access auditing, and state reconstruction at any historical point: not just current state retrieval.
Write-Heavy Application
A high-rate device telemetry ingestion architecture designed for millions of devices emitting metrics at 1–60 second intervals. Kafka absorbs device writes as an ingestion buffer, decoupling device-facing ingest endpoints from the storage write path so that downstream storage pressure never propagates back to devices. TimescaleDB provides time-series storage with automatic chunk partitioning by time range, native compression, and continuous aggregate views for rollup queries. ClickHouse serves as the OLAP layer for device fleet analytics queries. Redis caches last-known device state (current readings per device) for real-time alerting queries that must not scan historical storage. Backpressure on the Kafka consumer side prevents storage write throughput from being overwhelmed by burst ingestion events from device reconnect storms.
AI / RAG Application
A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.
Multi-Tenant SaaS
A multi-tenant SaaS architecture where multiple customers are served from a shared deployment, with PostgreSQL row-level security providing logical tenant isolation, Redis delivering per-tenant caching, and connection pooling managing the aggregate connection demand across tenant workloads. Tenant isolation, resource fairness, and operational simplicity are the three competing forces this architecture must balance.
Event-Driven System
A multi-channel notification delivery architecture that accepts upstream business events (order placed, payment received, comment posted, threshold alert triggered) and routes them to per-channel delivery workers (push via FCM/APNs, email via SendGrid, SMS via Twilio, in-app via WebSocket). Kafka carries raw business events from upstream producers. RabbitMQ handles per-channel fan-out with separate exchanges and queues per delivery channel, isolating email queue backlog from push notification delivery. PostgreSQL provides durable notification state tracking (sent, failed, bounced, suppressed). Redis enforces per-user rate limiting (notification frequency caps to prevent fatigue) and stores deduplication tokens to prevent duplicate sends across retry attempts. The inbox pattern on the consumer side ensures idempotent delivery even when Kafka produces duplicate events.
Analytics Pipeline
A metrics, logs, and traces ingestion and query platform built to absorb the telemetry output of a production system fleet: including the telemetry volume spikes that accompany the incidents the platform is meant to detect. ClickHouse stores metrics data with automatic time-based rollup via continuous materialized views; TimescaleDB provides complementary time-series storage for high-cardinality alert evaluation; Kafka buffers the ingestion stream against downstream write pressure, decoupling ingest acceptance rate from storage write throughput; Elasticsearch serves log full-text search and structured field filtering; Redis caches dashboard query results and active alert state for sub-100ms alert evaluation latency. The alert engine evaluates threshold and anomaly rules against pre-computed materialized views, not raw data, to bound alert evaluation cost independent of ingestion volume.
Read-Heavy Application
A standard SaaS API architecture optimized for read-dominant workloads. PostgreSQL serves as the primary data store, Redis provides a caching layer for hot data, connection pooling bounds database concurrency, and read replicas scale read throughput without scaling write capacity.
Realtime Collaboration
An architecture for multi-user document editing where users see each other's changes in near real-time. PostgreSQL provides durable state persistence, Redis coordinates ephemeral session state and pub/sub for live change propagation, and connection pooling protects the database from WebSocket-induced connection churn.
Search-Heavy Application
A content platform architecture centered on Elasticsearch for full-text search, faceted navigation, and ranked results, with PostgreSQL as the transactional source of truth and Redis for session management and hot content caching. WAL-based CDC maintains index freshness by streaming PostgreSQL changes into Elasticsearch asynchronously. The core tension is between search index freshness, query performance, and index maintenance cost under high write volume.
Event-Driven System
A social activity feed architecture where user actions (posts, likes, comments, follows) fan out asynchronously to follower timelines. Redis stores hot feed data as pre-materialized lists per user, enabling O(1) timeline reads for the 99th percentile of users. Kafka carries fan-out work to async workers that write to follower Redis keys. PostgreSQL is the durable store for the social graph, posts, and user content. The system uses a hybrid fan-out model: fan-out-on-write for users with fewer than ~10,000 followers (low fan-out cost), fan-out-on-read for high-follower celebrity accounts where pre-materialized fan-out would saturate workers and Redis write bandwidth.
Event-Driven System
A video and audio streaming architecture where content ingestion triggers an async multi-variant transcoding pipeline, CDN delivery handles 95%+ of playback traffic, and Cassandra absorbs the write volume of per-user viewing history. Kafka decouples upload events from transcoding workers; MinIO stores raw and encoded assets; Redis maintains playback session state and view counters. The architecture must handle upload spikes without blocking delivery, and cache cold starts without cascading database load.
Marketplace Platform
A two-sided marketplace architecture serving buyers, sellers, listings, transactions, search, and notifications from a shared infrastructure, where multiple independent domains must coordinate without tight coupling. Event sourcing captures every state transition; the saga pattern orchestrates multi-step transactions (create order, reserve inventory, charge payment, notify seller) with compensating transactions for partial failures. Kafka decouples domain event publication from consumption; RabbitMQ handles notification fanout; Elasticsearch serves listing search; Redis caches listing display and session state.