What Redis actually is
Redis is a key-value store that lives in memory. You give it a key ("user:1042:profile") and a value, and it hands the value back on request — typically in well under a millisecond, because nothing touches a disk on the read path. On top of plain strings it ships practical data structures: hashes for objects, lists and sorted sets for feeds and leaderboards, sets for membership checks, counters with atomic increments.
That combination — RAM speed plus real data structures — is why it shows up in almost every serious web stack. It is not competing with your database at being durable and queryable; it is competing with your database at being *fast to answer the same question repeatedly*, and it wins that contest by two or three orders of magnitude.
The problem it solves: repeated expensive work
Look at what a typical backend does per request: load the user, load settings, run the same product listing or menu query that has not changed since the last visitor, render it all. Most of that work produces the same answer it produced seconds ago. The database dutifully re-executes it anyway — parsing, planning, reading pages, joining — and under traffic those repeated queries become the bottleneck long before CPU does.
The cache-aside pattern fixes exactly this: check Redis first; on a hit, return the cached copy; on a miss, run the real query, store the result with a time-to-live, return it. A page that needed fifteen queries now needs fifteen memory lookups on the warm path. The database drops from being hit by every request to being hit once per TTL window — which is also why sites survive traffic spikes with Redis that would have flattened them without it.
Sessions are the second classic job. Keeping login sessions in Redis instead of on local disk means any of your app's replicas can serve any user — which is what makes horizontal scaling work at all.
Where Redis will not help
An honest boundary line saves you weeks. Redis does not make a slow query fast the first time — it only makes the *second* execution cheap, so a missing database index is still a missing index. It does not fix a slow origin network path or heavy images; those are delivery problems, solved at the edge, not in RAM. And it is not a durable system of record: memory is finite and evictions are by design, so anything you cannot afford to lose belongs in the database, with Redis holding a disposable copy.
The real cost of caching is invalidation: a stale price or an outdated permissions check is a bug your users see. Keep TTLs short where correctness matters, delete keys explicitly when the underlying data changes, and resist caching things that change on every request — a cache with a hit rate near zero is pure overhead.
Managed Redis: the add-on route
Running Redis yourself is not hard on day one — it is hard on day two hundred: memory limits, restarts, version upgrades, making sure the app reconnects. A managed instance folds all of that into the platform.
On cdn.com.tr's container platform, Redis is an add-on you attach to an app. Enabling it provisions the instance and injects the connection into your app's environment automatically — REDIS_HOST, REDIS_PORT, REDIS_DB and a ready-to-use REDIS_URL — so frameworks like Laravel, Django or WordPress pick it up with configuration, not code. The WordPress platform uses the same add-on as an object cache, which is one of the highest-leverage single changes for a busy WordPress site. Disable the add-on and the variables are cleaned up with it.
Enable managed Redis on an app with cdnctl
# attach a managed Redis instance to your app
cdnctl container addons enable-redis --account <uuid> --app <app_uuid> --env-prefix REDIS
# see what is attached
cdnctl container addons list --account <uuid> --app <app_uuid>
# remove it again
cdnctl container addons disable-redis --account <uuid> --app <app_uuid>Redis and the CDN: two cache layers, different jobs
It is worth being precise about how an in-memory cache relates to a CDN, because they are both "caching" and they are not interchangeable. The CDN caches *responses* — finished HTML, images, files — close to the visitor, so many requests never reach your application at all. Redis caches *data inside* the application, so the requests that do arrive are cheap to serve.
They compound: the edge absorbs the cacheable majority of traffic, and Redis makes the personalized, uncacheable remainder fast. A stack with both typically serves anonymous pages from the edge in tens of milliseconds and logged-in pages from a Redis-warmed backend — which is the architecture behind most sites that feel instant under load.
Frequently asked questions
Is Redis a database?
It can persist to disk, but that is not the job you should hire it for. Treat Redis as a fast, disposable copy of data whose source of truth lives in a real database. If losing the data would hurt, it does not belong only in Redis.
What should I cache first?
The query log answers this: the most frequent expensive queries whose results change rarely — product listings, menus, settings, rendered fragments. Cache those with a sensible TTL and you usually capture most of the win in an afternoon.
How much memory does a Redis cache need?
Less than most people assume — cached query results and sessions are small. Start modest, watch the hit rate and evictions, and grow only when evictions of still-useful keys appear. A high hit rate on a small instance beats a huge idle one.
Does WordPress benefit from Redis?
Noticeably. WordPress re-reads options and objects from MySQL constantly; a Redis object cache turns those into memory lookups. On the managed WordPress platform the same Redis add-on serves as the object cache, combined with edge caching in front.