Redis database development
Redis is the layer that makes the rest of the stack feel fast — caching, sessions, rate limits and queues. It is rarely the interesting part of an architecture and often the reason it holds up.
Where we use Redis
Redis is part of the stack on these 4 services. Each page covers how we work, what you get and what it costs to start.
Redis in practice
Redis holds data in memory and answers in well under a millisecond, which is why it ends up in front of almost every database we run. Caching, sessions, rate limits and job queues are all the same underlying capability: shared state that several application instances can reach faster than they could reach disk.
The design work is entirely in invalidation. A cache that serves stale data is worse than no cache, so we decide up front what invalidates on write, what expires on a timer, and what is allowed to be slightly stale. That decision belongs in the design, not in an incident review three months later.
What we build with Redis
Cached query results and rendered fragments, with invalidation designed in rather than discovered during an incident.
Shared session state across instances, plus the counters that protect an API from abuse.
Background work — emails, imports, webhooks — kept off the request path.
Is Redis right for you?
Ask usA good fit when
- Caching expensive queries and rendered fragments
- Sessions shared across multiple application instances
- Rate limiting and counters
- Background job queues for application work
Probably not when
- As a primary datastore for anything you cannot lose
- Datasets far larger than memory
- Complex queries — it is a key-value store with useful structures, not a database
What we run alongside Redis
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- BullMQ, Sidekiq or Celery
- The queue layer on top, depending on your language.
- Managed Redis
- ElastiCache, Memorystore or Azure Cache — failover and patching handled.
- Sensible TTLs
- Every key gets an expiry unless there is a documented reason it should not.
- Redis Sentinel or Cluster
- High availability, once losing the cache would mean losing the site.
Why Redis
Let’s talkSub-millisecond reads
In-memory access removes database round trips from the hot path entirely.
Useful data structures
Sorted sets, hashes and streams solve leaderboards, counters and queues without extra services.
Simple to operate
A managed Redis is a small operational surface for a large performance return.
What we get called in to fix
Get a second opinionStale cache serving wrong data
Invalidation never designed, so users see outdated prices or permissions.
Keys without expiry
Memory filling until eviction starts removing things the application assumed were there.
Cache stampedes
A popular key expiring and a thousand requests recomputing it simultaneously.
Used as a database
Critical data living only in Redis with persistence not configured, one restart away from gone.
Redis or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Redis, almost always. Richer data structures, persistence options and the same simplicity.
Redis for application background work. RabbitMQ or Kafka when you need strict delivery guarantees or event replay.
In-process is faster but per-instance. Redis once several instances must see the same cache.
Redis works well with:
AWS
Azure
Docker
Google Cloud
Grafana
Kubernetes
Prometheus
Python
Terraform
Angular
AnsibleGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
Rarely, and only with persistence configured deliberately. We treat it as a cache and coordination layer.
Explicit invalidation on write plus conservative TTLs. Cache correctness is a design decision, not a setting.
Yes, for most application-level background work. For strict delivery guarantees we would use a dedicated broker.
That depends on design, and it should be a deliberate one. Caches should degrade to slower responses; sessions and queues need replication or a fallback.
From working-set measurement, not guesswork — with headroom, since eviction under pressure is where surprises come from.