Redis

Valkey is an open-source fork of Redis created in March 2024 by the Linux Foundation after Redis Inc. changed its license from BSD to SSPL/RSALv2. It's backed by AWS, Google Cloud, Oracle, and Ericsson, with the former lead Redis maintainers as core contributors. Valkey 8.1 benchmarks 8% more ops/sec, 22% lower P99 latency, and 20% less memory than Redis OSS. Amazon ElastiCache offers Valkey at 20% lower cost. Ubuntu 26.04 LTS ships Valkey as its default redis-server package. The API is identical to Redis — migrating is a configuration change, not a code change. For new deployments: evaluate Valkey first, especially on AWS or Ubuntu 26.04. For existing Redis: the switch only matters if AGPL licensing or cost savings are driving factors.

Redis 8.0 was a major consolidation release: JSON (RedisJSON), TimeSeries (RedisTimeSeries), probabilistic data structures (Bloom filters, Cuckoo filters, Count-Min-Sketch, Top-K), vector sets for AI/semantic search, and hybrid search capabilities moved from separate Redis Stack modules (requiring paid licensing in production) into the open-source Redis core. This is significant — it means teams can use Redis for semantic search, time-series data, and probabilistic operations without the complexity of Redis Stack licensing. The trade-off is that Redis 8.0 also came with the license change that created Valkey.

No, for most applications. Redis is designed as an in-memory data structure store — memory-bound, with durability as a secondary concern. AOF persistence gets you near-zero data loss, but Redis is architecturally optimized for speed over durability. Critical business data (orders, payments, user accounts) belongs in PostgreSQL or MongoDB with Redis caching the hot subset. There are specific use cases where Redis as primary store makes sense — leaderboards with no backup requirement, ephemeral session data, rate limit counters — but it's the exception, not the rule.

Cache invalidation is the hardest Redis problem. The approaches we use in production: (1) TTL-based expiry — every cache key gets a TTL; stale data expires automatically; simplest but may serve stale data until TTL expires. (2) Write-through invalidation — when source data changes, delete the cache key immediately; guarantees freshness but requires careful coordination in distributed systems. (3) Tag-based invalidation — store sets of related cache keys under a tag key; when the tagged entity changes, SMEMBERS the tag set and DEL all members. Each approach has tradeoffs; we choose based on your consistency requirements and cache hit rate targets.

Pub/Sub: fire-and-forget. Messages are delivered to subscribers connected at the moment PUBLISH is called. No message persistence, no delivery acknowledgment, no consumer groups. Suitable for real-time notifications where missing a message is acceptable (live dashboards, presence indicators). Streams (XADD, XREADGROUP, XACK): persistent, durable message queues with consumer groups and acknowledgment. Messages survive connection drops and consumer failures. Each consumer group tracks its own read position; XACK confirms processing. Suitable for inter-service event streaming where message loss is not acceptable. We use Streams for everything that matters; Pub/Sub for display-layer real-time features.

Three levers: (1) Eviction policy — set maxmemory and maxmemory-policy. For caches, allkeys-lru evicts least-recently-used keys when memory is full. For mixed cache/persistent stores, volatile-lfu evicts only keys with TTL. Never leave maxmemory unset in production. (2) Key TTLs — every cache key should have a TTL. Keys without TTL accumulate indefinitely. We audit Redis keyspaces with SCAN and DEBUG OBJECT to find keys without expiry. (3) Data structure selection — HASH uses less memory than N separate STRING keys for the same object data; Redis's object encoding optimization compresses small hashes into ziplist format automatically.

Redis Cluster assigns 16,384 hash slots distributed across primary nodes. Each key maps to a slot via CRC16(key) % 16384. When a client sends a command to the wrong node, the node responds with MOVED slot destination_ip:port — the client should retry the command at the correct node. Modern Redis clients (ioredis, Lettuce, Jedis) handle MOVED redirects transparently. Hash tags override key-to-slot mapping: {user:123}:session and {user:123}:cart are forced to the same slot, enabling multi-key operations on data that logically belongs together.

Yes, Redis 8.0 integrates vector sets natively. VADD adds vectors, VSIM performs approximate nearest-neighbor search using HNSW, and VRANGE combines vector similarity with key filters. For applications already using Redis for caching where vector search is a secondary requirement, this eliminates a separate vector database deployment. The honest comparison: pgvector (PostgreSQL) and MongoDB Atlas Vector Search are more mature for production AI workloads with richer tooling. Redis vector sets are best suited for teams that want semantic search co-located with their existing Redis caching layer without adding infrastructure complexity.

Sliding window rate limiting with sorted sets is the most accurate approach: ZADD key:client_id timestamp timestamp; ZREMRANGEBYSCORE key:client_id 0 (now-window_ms); count = ZCARD key:client_id; if count >= limit reject. The critical requirement: the ZADD + ZREMRANGEBYSCORE + ZCARD sequence must be atomic — wrap in a Lua script. Alternative: fixed window with INCR + EXPIRE. Simpler but allows 2× the rate limit at window boundaries (burst at end of one window + start of next). Token bucket (maintained with HINCRBY + time calculation) allows configurable burst capacity. We choose based on your API's burst tolerance requirements.

Redis open-source (or Valkey) is free. Managed infrastructure: Redis Cloud Essentials from $0 (30MB free tier) to $200+/month for production clusters; AWS ElastiCache (Redis or Valkey) from ~$25/month for a cache.t3.micro to $500+/month for production-grade clusters; Valkey on ElastiCache runs 20% cheaper than the Redis tier. Development cost depends on cache architecture complexity, cluster configuration, data structure patterns, and integration scope. We scope specifically — describe your use case, traffic patterns, and data volume and we'll provide a detailed estimate.