Redis keeps data in memory, which makes reads dramatically faster than disk. We use it for caching, sessions, rate limiting and job queues — never as the permanent home for data that matters.
What is Redis?
Redis is a key-value store that lives in RAM. That single design decision is where its speed comes from and also where its limitation comes from: memory is fast and finite, and it is lost when the process restarts unless persistence is configured.
It is best understood as somewhere to put things that are expensive to compute and cheap to lose. A cached page, a session, a rate-limit counter, a queued job.
When we choose Redis
When a page is expensive to build and changes rarely. Caching the rendered result turns a page that hits nine tables into one memory read, which is most of what makes a busy site feel fast.
For sessions on a site running on more than one server, so a visitor stays logged in regardless of which server answers.
For job queues, where work that would block a request gets handed off and processed in the background.
And for rate limiting, which needs a counter shared across every server and updated thousands of times a second. That is a workload a relational database handles badly and Redis handles as its default case.
When we do not use Redis
On a single small site on shared hosting. The database cache driver is adequate there, and adding a service to run for a site with modest traffic is complexity without payback. This site ships with the database cache driver for exactly that reason.
And never as the only home for data that matters. Redis is a cache; if losing it would lose something, it belongs in a database.
What we build with Redis
Page and query caching
Rendered pages and expensive query results held in memory with a sensible expiry, and invalidated when an editor saves so nobody ever sees stale content.
Queues for slow work
Image processing, emails, report generation and model calls moved out of the request so a page never waits on them. This is the single most effective way to keep a site responsive as features accumulate.
Rate limiting and abuse protection
Login attempts, form submissions and API calls counted per user and per address, so a brute-force attempt is throttled before it reaches the database.
Session storage across servers
So a visitor stays logged in regardless of which server answers their next request. This is the thing that quietly breaks when a site is scaled to two servers without planning for it.
Cache invalidation tied to the admin
An editor saves and the affected pages clear immediately. Time-based expiry alone means someone eventually sees an old price, which is worse than a slow page.
Leaderboards and live counters
Sorted sets update and rank in constant time, so a live count or ranking stays accurate under load without hammering the database. Useful anywhere a number has to be right and immediate at the same time.
How we ship Redis projects
With a memory limit and an eviction policy set. A Redis instance with no limit will consume everything available and then take the server with it.
With every cached value carrying an expiry, and invalidation wired to the admin save so an edit is visible immediately rather than in an hour.
And with persistence configured according to what the data is. A cache can be lost on restart; a queue of jobs that have been accepted but not run cannot, or a customer's order quietly disappears. Those are different configurations and treating them the same is a real bug.
What Redis costs you
Memory costs more than disk, so a large cache is a real hosting line item.
Cache invalidation is also genuinely hard — the failure mode is a customer seeing yesterday's price, which is worse than a slow page. We invalidate on write rather than relying on expiry alone for anything that matters.
It is also one more service to monitor and secure. An exposed Redis instance with no password is a well-known way to get compromised, and it happens because the default configuration is convenient rather than safe.
Redis questions we get asked
Not for a typical brochure or content site — the database cache handles that fine. You need it when traffic is high enough that database load is the bottleneck, when you run more than one server, or when background jobs are a significant part of the system.
The cache is empty and rebuilds from the database as pages are requested. There is a brief period of slower responses and nothing is lost — which is exactly why nothing that matters should live only in Redis.
Less than people expect for a typical site — cached pages and sessions are small. We set a limit and an eviction policy so it discards the least-used entries rather than growing until it takes the server down with it.
Not if invalidation is wired to the writes. When an editor saves or a price changes, the affected entries clear immediately rather than waiting for an expiry. Relying on time-based expiry alone is how a customer ends up seeing yesterday's price, which is worse than a slow page.
Yes, usually with no code changes on a Laravel or Node application — it is a driver swap and a service to run. We would measure first though: on a site where the database is not actually under pressure, adding Redis is a service to maintain in exchange for nothing measurable.
There is no single number — it depends on how expensive your pages are to build. A site with heavy queries benefits at a few thousand visits a day; a simple one may never need it. We measure database load first and add Redis when the measurement says so, not because the architecture looks more serious with it.