Key-ValueOps: low

Redis

Redis is an in-memory data structure store used as a database, cache, message broker, and streaming engine. It supports rich data structures including strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLogs, and streams, all operated on with atomic commands in a single-threaded event loop. Redis achieves sub-millisecond latency for both reads and writes, making it the de facto choice for caching layers, session management, and real-time leaderboards.

Strengths

Sub-millisecond latency for reads and writes due to in-memory architecture with optimized data structuresRich data structures (sorted sets, streams, bitmaps, HyperLogLog) enable complex operations atomicallyLua scripting and MULTI/EXEC transactions provide atomic multi-key operations on a single shardRedis Streams provide a persistent, consumer-group-based log structure similar to KafkaPub/Sub and Keyspace Notifications enable real-time event-driven patterns

Weaknesses

Dataset must fit in memory; cost per GB is 10-50x higher than disk-based storageSingle-threaded command execution limits throughput to ~100K ops/sec per core (I/O threads help in 6.x+)Persistence options (RDB snapshots, AOF) can cause latency spikes during fork() on large datasetsRedis Cluster provides eventual consistency; failover can lose acknowledged writes (async replication)No built-in query language for filtering or aggregation; application must maintain secondary index structuresRedis Cluster slot migration during resharding can cause brief unavailability for migrating keys

Ideal Workloads

-Application-level caching with TTL-based expiration and cache-aside or write-through patterns
-Rate limiting using sliding window counters with sorted sets or the Redis Cell module
-Real-time leaderboards and ranking systems using sorted sets with O(log N) insertions
-Distributed locking (Redlock) and semaphores for coordination across services
-Session storage for web applications requiring fast read/write with automatic expiration

Scaling Model

Scales vertically by adding memory and using I/O threads for network handling (Redis 6+). Horizontal scaling via Redis Cluster which partitions data across up to 16,384 hash slots distributed among master nodes, each with one or more replicas. Client-side consistent hashing or a proxy layer (e.g., Twemproxy, Envoy) can also distribute load. Read replicas serve read traffic but introduce replication lag.

Consistency Model

Single-master, asynchronous replication to replicas. Writes acknowledged by the master before replication means failover can lose the most recent writes. WAIT command can block until N replicas acknowledge a write, providing a form of synchronous replication. Redis Cluster uses last-failover-wins and does not provide cross-shard transactions. Within a single node, all operations are linearizable due to single-threaded execution.

When to Use

You need sub-millisecond latency for reads and writes in a caching or session layer
Your use case maps naturally to Redis data structures (sorted sets for rankings, streams for logs)
You need atomic operations on complex data structures without external coordination
You want a lightweight pub/sub or message queue for real-time features
You need distributed locking or rate limiting primitives

When Not to Use

Your dataset exceeds available memory or cost constraints make in-memory storage impractical
You need durable, strongly consistent storage as your primary database
You require complex queries, joins, or ad-hoc filtering across your dataset
You need multi-key transactions across different hash slots in a cluster
Data loss of recent writes during failover is unacceptable for your use case

Source: editorial — Based on Redis 7.x documentation and common production caching architecture patterns