Technology · Cache & queues
Redis
Redis · Pub/Sub · Streams
Redis is not the system of record and should never be mistaken for one. It is the layer in front: the cache that stops the same query running ten thousand times, the queue that lets slow work happen later, the counter that enforces a rate limit. Most "our database is slow" problems are really "we have no cache" problems.
How TrivialWorks uses it.
Redis appears in our architectures the moment read volume or background work becomes real — caching hot paths, backing job queues with retries and dead-letter handling, holding sessions, and enforcing rate limits at the edge of an API. It sits beside PostgreSQL or MongoDB rather than replacing either, and we treat everything in it as losable by design.
Decision guide
Should your project use Redis?
Practical selection guidance — the conversation we would have with you before writing a line of code.
When it’s the right choice
- Read-heavy endpoints hitting the same data repeatedly — the cheapest performance win available
- Background and deferred work: queues with retries, scheduled jobs, fan-out to workers
- Sessions, feature flags and short-lived state that should not occupy your primary database
- Rate limiting and abuse control that has to be fast enough to run on every request
When it isn’t
- As a primary system of record — it is memory-first, and treating durable business data as safe there is how people lose it
- Complex querying, reporting or joins, which belong in a relational or document store
- Small, low-traffic applications where a cache adds an operational moving part and solves a problem you do not yet have
Consider PostgreSQL — The data must survive a restart and be queried properly — that is a system of record, not a cache.
Best use cases
Where Redis makes practical sense.
Caching hot paths
Dashboards, catalogues and feeds served from memory, so the database only sees the queries that actually changed.
Job queues
Emails, exports, webhooks and integrations processed out of band, with retries and dead-letter handling designed in.
Sessions & short-lived state
Login sessions, one-time tokens and feature flags, expiring on their own rather than accumulating forever.
Rate limiting
Per-key request budgets enforced in microseconds — the same pattern that protects this site's own contact endpoint.
Related services
Services that commonly use it.
Questions
Redis, asked straight.
Do we need Redis, or is our database enough?
Early on, your database is usually enough — adding a cache before you have a load problem buys complexity, not speed. Redis earns its place when the same reads repeat at volume, or when work needs to happen outside the request. We will tell you which of those you actually have.
Is data in Redis safe?
Treat it as losable. Persistence options exist and we configure them, but the right architecture assumes a flush costs you a cold cache and nothing more. Anything you cannot afford to lose lives in PostgreSQL or MongoDB.
Redis or a managed queue service?
If Redis is already in the system, its queues are usually the simpler answer. If the workload needs guaranteed ordering, long retention or cross-region delivery, a purpose-built managed queue is the more honest choice and we will point you there.
Thinking about Redis?
Send the requirement and you get back a functional specification — screens, data model, stack and an estimate — at no charge. If Redis is the wrong choice for it, that will be in there too.