Redis Architecture Diagram: Caching, Pub/Sub, Cluster & Sentinel Patterns (2026)

Redis architecture diagrams appear in nearly every production system — as a cache sitting in front of a database, a session store behind an API, a pub/sub broker between services, or a distributed lock manager coordinating workers. Redis's simplicity hides genuine architectural complexity: the topology changes significantly between standalone, Sentinel, and Cluster modes, and the correct diagram depends on which guarantees matter — availability, partition tolerance, or latency. This guide covers the key Redis deployment patterns, what to show in each, and AI prompt templates for generating accurate diagrams.

Redis deployment topologies

• Standalone (single node): A single Redis primary with no replication. Appropriate for development, ephemeral caching where data loss is acceptable, or very low-throughput use cases. Show your application service pointing directly to one Redis node with no failover path — make the single-point-of-failure explicit in the diagram.
• Primary/replica replication: One primary handles all writes; one or more replicas serve reads and can be promoted in a failover. Replication is asynchronous by default. Show the replication stream from primary to replicas, annotate whether reads are distributed across replicas, and mark the async replication lag risk.
• Redis Sentinel: Adds automated failover to primary/replica setup. Three or more Sentinel processes form a quorum that monitors the primary; on failure, Sentinels elect a new primary and update clients. Clients connect to Sentinels to discover the current primary address. Show: Sentinel nodes (typically 3), primary, replicas, and the quorum election flow. The “split brain” prevention via odd quorum count is worth annotating.
• Redis Cluster: Horizontal sharding across multiple primary nodes. The keyspace is divided into 16,384 hash slots distributed across N primaries. Each primary can have its own replicas. Clients use cluster-aware libraries and are redirected via MOVED/ASK responses. Show: all primary nodes, their hash slot ranges, their replicas, the gossip protocol between nodes, and how a client gets redirected on a MOVED response.
• Managed Redis (Elasticache, Upstash, Redis Cloud): Cloud-managed deployments abstract Sentinel or Cluster internals. Show the managed cluster as a logical unit, annotate the VPC endpoint or private link, and show your application's connection pooling layer (typically via a library like ioredis or lettuce with connection pooling configured).

Common Redis usage patterns to diagram

• Cache-aside (lazy loading): Application checks Redis first; on cache miss, fetches from the primary database, writes to Redis with a TTL, and returns the result. Show the read path (Redis hit), the miss path (DB read → Redis write → return), and annotate the TTL and eviction policy (LRU, LFU).
• Write-through cache: Application writes to Redis and the primary DB atomically (or via a cache-writing layer). Keeps cache consistent with DB at write time. Show the dual-write path and any rollback logic on partial failure.
• Session store: Stateless API servers store session tokens in Redis (keyed by session ID). Show multiple API instances all pointing to the same Redis cluster, annotate key structure (e.g., session:{id}), TTL, and any session renewal logic.
• Pub/sub messaging: Publisher services write to channels; subscriber services receive messages. Show publishers, the Redis pub/sub channel topology, subscribers, and note that pub/sub in Redis is at-most-once (no persistence) — useful for real-time events where missed messages are tolerable.
• Redis Streams: Persistent, consumer-group-based message streaming. Unlike pub/sub, Streams persist messages and support consumer groups with at-least-once delivery. Show producers, the stream (named key), consumer groups, consumers, and the acknowledgment flow. Contrast with Kafka for smaller-scale use cases.
• Distributed lock (Redlock): Acquiring a lock across 2N+1 independent Redis nodes. Show the lock acquisition flow (SET key value NX PX TTL), the quorum majority check (N+1 nodes must respond), and the lock release flow. Annotate the clock drift risk and why Redlock requires independent nodes.
• Rate limiting: Using Redis INCR + EXPIRE (or a sliding window with sorted sets) to enforce per-user or per-IP rate limits at the API gateway or middleware layer. Show where in the request path the Redis rate-limit check occurs and the fallback on Redis unavailability.

Prompt examples for Redis architecture diagrams

Redis Sentinel with cache-aside pattern

Redis Cluster for horizontal scaling

Redis Streams as a lightweight Kafka alternative

Multi-layer caching with Redis

Redis vs other caching and messaging solutions

What to annotate on a Redis diagram

• Persistence mode: Whether RDB snapshots, AOF (append-only file), or no persistence is configured. This determines data recovery behavior on restart.
• Eviction policy: The configured maxmemory-policy (noeviction, allkeys-lru, volatile-lru, etc.) and maxmemory limit. Critical for understanding behavior under memory pressure.
• Connection pooling: Show the connection pool configuration in your client libraries (min/max pool size). Redis is single-threaded — unbounded connections degrade performance.
• TLS and authentication: Whether TLS is enabled for client connections (critical for production) and the authentication method (requirepass, ACL users for Redis 6+).
• Key naming conventions: Annotate the key namespace pattern (e.g., app:env:type:id) on the diagram — prevents key collisions when multiple teams share a cluster.

Related guides: Kafka architecture diagrams, WebSocket architecture diagrams, microservice architecture patterns, and streaming data architecture.