+994512060920
A new site goes live, and for the first few days everything runs fast. Then the user count grows, a campaign starts, traffic climbs, and suddenly pages take three or four seconds to open. The team upgrades the server, which helps a little, but the problem comes back a week later. Sound familiar?
Very often the cause isn't a weak server. The system is simply doing the same work over and over. The same product list is pulled from the database again for every user, and the same calculation is repeated on every request. Caching exists to remove that repetition, and Redis is the most widely used tool for the job.
What Is Caching?
Caching means preparing a frequently needed result once, keeping it somewhere fast, and taking it from there next time instead of preparing it again.
Here's an everyday example. You drink tea every morning. Instead of brewing it from scratch each time, you fill a thermos and keep it on your desk. The thermos is the cache: the tea is already made and within reach, and you don't have to walk to the kitchen. The kitchen is the database. The result is available there too, but getting to it takes longer.
Why Does a Site Slow Down?
There are many possible causes, but these are the most common:
- Too many database queries: Dozens of queries run every time a page opens, and when traffic grows the database can't keep up.
- Heavy calculations: Reports, filter results and price calculations are recomputed from scratch every time.
- Dependence on external APIs: Exchange rates, delivery prices or payment status require a call to an outside service on every request.
- Large files: Images, scripts and stylesheets aren't optimized.
- Re-fetching the same data: Data that never changes is rebuilt for every user.
The fix for many of these is the same: remember the result. That raises the next question, though. Where do you keep it?
What Is Redis?
Redis is an open source system that keeps data directly in memory (RAM). A database usually stores data on disk, and disk is much slower than memory. Because Redis keeps everything in memory, its response time is very short, typically measured in milliseconds.
Redis works on a key and value principle. You give it a key (for example, products:popular) and store a result under it. The next time you ask for the same key, the answer comes back immediately.
How Does a Cache Work? A Simple Scenario
The most common approach goes like this:
- A user opens the popular products page.
- The system first checks Redis: is this result there?
- If it is, the result is returned right away and the database is never touched.
- If it isn't, the system gets it from the database, writes it to Redis and returns it to the user.
- The next users get the ready-made result.
In simple form, the logic looks like this:
result = redis.get("products:popular")
if result is missing:
result = database.query("popular products")
redis.set("products:popular", result, ttl=5 minutes)
return result
The "ttl" part is an important detail. Data in a cache doesn't stay forever. After a set time it expires and is rebuilt on the next request. This is called TTL.
Where Is Redis Used?
| Use case | Example |
|---|---|
| Page and query result caching | Popular products, category lists, news feed |
| Session storage | A user's logged-in state, cart contents |
| Rate limiting | Limiting how many requests one user can send per minute |
| Queues and fast calculations | Notification queues, leaderboards, counters |
| Temporary codes | SMS verification codes, one-time links |
Rate limiting is closely tied to security as well. We covered it in more detail in our API security article.
Is Caching Possible Without Redis?
Yes. Caching isn't only Redis, it works on several levels:
- Browser cache: Images, styles and scripts are stored in the user's browser and aren't downloaded again each time.
- CDN cache: Static files are served from a server geographically close to the user.
- In-application cache: Small results kept in the program's own memory. It's simple, but when the app runs on several servers, each server has its own separate cache.
- Shared cache (Redis): All servers use the same cache.
For a small project, browser caching and a CDN are often enough. Redis becomes necessary when there is a lot of dynamic data, traffic has grown, and the system runs on several servers.
The Hardest Part of Caching: Stale Data
There's a well-known saying among developers: there are two hard problems in computer science, and one of them is knowing when to invalidate a cache. The joke points to a real problem.
Say a product's price changes but the cache still holds the old one. The user sees the old price and places an order. That's no longer a speed problem, it's a business problem. So a cache strategy has to answer these questions:
- How often does this data change? If it rarely changes, a long TTL is fine.
- How dangerous is showing stale data? A few minutes of delay on a blog post is fine, but not on prices and stock.
- How will we refresh the cache when data changes? The safest way is to delete the relevant cache key at the moment of the change.
What Should You Cache, and What Not?
Good candidates for caching: data that is read a lot and changes rarely. Category lists, popular products, a homepage block, exchange rates, configuration settings.
Handle with care: data that differs for each user, stock counts, payment status, balances. You can cache these, but the refresh rules need to be thought through very carefully.
Never cache: sensitive data (passwords, card details) and financial operations that must be exact every time.
Is the Cache Working? How to Check
Setting up a cache is only half the job. You need to measure that it works. The key indicator is the cache hit ratio: what percentage of requests were answered from the cache. If that number is low, either the TTL is too short or the wrong data is being cached.
You should also watch response time, database load and Redis's own memory usage. If you haven't set up monitoring for these yet, our monitoring and logging article is a good place to start.
Redis in Microservices and Kubernetes
If your system is built on a microservices architecture, Redis often acts as a fast shared memory between services. For example, one service writes a session and another reads it.
Two points matter when you run Redis in a Kubernetes Cluster. First, when a Pod restarts, data held in memory can be lost, so it's safer to use Redis as a cache, meaning for data whose loss isn't a disaster. Second, if you store critical data, you need to set up persistence and a backup replica.
The Most Common Mistakes
- Caching everything: A cache adds complexity. Target only the places that create real load.
- Not setting a TTL: Data stays forever, memory fills up and stale results get shown.
- Treating the cache as the source of truth: The main data should always live in the database. The cache is only an accelerator.
- Leaving Redis unprotected: A Redis instance with no password, exposed to an open network, is a serious security risk.
- Not looking for the real cause: If a slow query is missing an index, a cache hides the problem instead of fixing it. Optimize the query first.
- Ignoring the load when the cache is empty: If the cache is suddenly cleared, all requests can hit the database at the same moment. In a high-traffic system this causes serious trouble.
How to Get Started
- Measure first: which pages and queries are the slowest?
- Optimize the queries themselves (indexes, fewer unnecessary queries).
- Set up browser caching and a CDN properly.
- Move one or two of the most-read, least-changed results into Redis.
- Define the TTL and the refresh rules.
- Track the cache hit ratio and response time.
- If the results are good, expand gradually to other places.
For projects that run under heavy load or have complex data flows, planning the cache strategy at the architecture stage is far more cost-effective than fixing it later. Decisions like these are usually part of the initial design in custom software projects.
Frequently Asked Questions
Can Redis replace a database?
Usually not. Redis is fast because it works in memory, but for large and long-term data a classic database is a better fit. Redis is most often used alongside it as a helper.
Does a small website need Redis?
Most of the time, no. Browser caching, a CDN and query optimization are usually enough at first. Redis starts to make sense when traffic and dynamic data grow.
Does caching affect SEO?
Indirectly, yes. Site speed is one of the factors that influence user experience and search results. If a cache lowers response time, that helps.
Can data in Redis be lost?
Yes, especially on a restart. That's why it's more reliable to keep data there whose loss isn't a disaster, and to configure persistence for anything critical.
When should a cache be cleared?
When the data changes. The safest approach is to delete the relevant key at the moment of the change, while keeping the TTL as a safety net.
Conclusion
When a site slows down, the first reaction is usually to upgrade the server. But often the problem isn't a lack of power, it's the same work being done again and again. Caching removes that repetition, and Redis makes it one of the most practical options for dynamic data. The rule is simple: measure first, cache where it counts, and think through the risk of stale data in advance.
If you'd like to look into the speed problems of your site or system together, get in touch with the Crocusoft team. We'll first find where the bottleneck is, then choose the right solution.
