Redis

Redis is my first tool for the hot path: caching, session storage, rate limiting, and pub/sub real-time messaging. Its data structures — strings, lists, sets, hashes, sorted sets — are expressive enough to model queues and leaderboards directly.

I design Redis to be fast and safe: sensible TTLs to bound memory, careful key design to avoid hot partitions, and persistence settings (RDB/AOF) tuned to how much loss a use case can tolerate. For critical queues I still reach for dedicated brokers where durability matters.

It also earns its place in AI pipelines — as the backing store for rate limiters, feature gates, and low-latency lookups that keep inference-serving responsive.

The data structures are what make it more than a cache. A sorted set is a leaderboard, a list is a lightweight queue, a hash is a row-like object — expressive primitives I use directly instead of serialising everything as opaque strings.

Caching is designed, not sprinkled. I put a real TTL on every cache, size the cache to memory, and model the invalidation around the data's actual write pattern, so the hot store stays bounded and never silently serves stale reads forever.

Sessions and rate limits live naturally in Redis. In-memory latency and the atomic increment/decrement primitives make per-user rate limiting and session reads predictable, which is exactly what the hot request path needs.

Reliability is tuned per use case. I choose between RDB snapshots and AOF persistence based on how much loss a case can tolerate, and I keep a deliberate line: Redis for fast ephemeral state, a durable broker when a message absolutely must be safe.

Key design avoids hot partitions. Hashing, sharding-aware naming, and steering hot keys away from single instances keep the in-memory store from becoming the bottleneck it was meant to relieve.

In AI systems it does the unglamorous but essential work — rate-limiters, feature gates, low-latency lookups — keeping the inference path responsive and the spend predictable, which is why it ends up beside almost every stack I touch.

I use Redis's data structures for what they are. A sorted set is a leaderboard, a list is a lightweight queue, a hash is a row-like object — not everything serialised as an opaque string.

Caching is designed, not sprinkled. Every cache has a real TTL, an explicit invalidation model, and a bounded memory, so the hot store never silently serves stale reads.

Sessions and rate limits live naturally here. In-memory latency and atomic increments make per-user rate limiting and session reads predictable on the hot path.

Key design avoids hot partitions. Careful naming and sharding-aware keys keep the in-memory store from becoming the very bottleneck it was meant to relieve.

Persistence is tuned per use case. RDB or AOF is chosen by how much loss a case can tolerate, and durability is not assumed where it is not configured.

The line between Redis and a durable broker is explicit. Fast ephemeral state and queues belong to Redis; a message that absolutely must not be lost belongs to a real broker.

Memory is monitored like a budget. Long-running TTLs and unbounded keys are tracked so the store stays within its size and predictable.

High availability is configured deliberately. Replication and sentinel/cluster topology give the availability that production needs without overbuilding.

In AI systems it does the essential quiet work — rate limiters, feature gates, low-latency lookups — keeping the inference path responsive and the spend predictable.