Redis Services

While both are in-memory caching systems, Redis offers significantly more functionality. Redis supports complex data structures (lists, sets, sorted sets, hashes, streams), persistence to disk, replication, Lua scripting, pub/sub messaging, and transactions. Memcached is simpler, supporting only string key-value pairs with a multi-threaded architecture. Redis is the better choice for most modern applications due to its versatility, while Memcached can be preferred for simple caching scenarios where multi-threaded performance is critical.

For production, use a combination of RDB and AOF persistence. RDB creates point-in-time snapshots at configured intervals, which are compact and fast to load. AOF logs every write operation and can be configured with fsync policies: always (safest, slowest), everysec (good compromise), or no (fastest, delegates to OS). Set appendonly yes and appendfsync everysec for most workloads. Use RDB as a backup mechanism alongside AOF for the best balance of durability and recovery speed.

Redis Sentinel provides high availability for a single Redis instance through monitoring, automatic failover, and service discovery, but does not partition data. Use Sentinel when your dataset fits in a single server's memory and you need automatic failover. Redis Cluster provides both horizontal scaling by partitioning data across multiple nodes and high availability with replica failover. Use Cluster when your dataset exceeds single-server memory or you need to scale write throughput across multiple primaries.

Redis is ideal for rate limiting due to its atomic operations and sub-millisecond latency. The simplest approach uses INCR with EXPIRE for fixed-window rate limiting. For sliding-window rate limiting, use sorted sets with ZADD and ZRANGEBYSCORE to track request timestamps. The token bucket algorithm can be implemented using a hash with MULTI/EXEC transactions. Redis modules like redis-cell provide the CL.THROTTLE command implementing the Generic Cell Rate Algorithm for production-ready rate limiting.

Redis Streams is a log-like data structure introduced in Redis 5.0 that supports consumer groups, acknowledgment, and message persistence. Streams work well for lightweight event streaming, activity feeds, and moderate-throughput messaging. Kafka is designed for high-throughput distributed event streaming with multi-datacenter replication, long-term storage, and exactly-once semantics. Choose Redis Streams for simpler use cases where Redis is already in your stack, and Kafka for enterprise-scale event-driven architectures.

Redis memory usage includes the data itself plus per-key overhead for the hash table entry, key string, and value encoding. A simple string key-value pair uses roughly 90-100 bytes of overhead beyond the actual data. Small hashes, lists, and sets use ziplist encoding which is more memory-efficient. Use MEMORY USAGE to check specific keys, and redis-cli --bigkeys to find memory-heavy keys. For large datasets, consider using hashes to group related small values, which can reduce per-key overhead significantly.