What Is Redis? Cache, Sessions and Queues Guide

The shortest answer to what is Redis is this: it is an extremely fast, in-memory, key-value data store. Short for Remote Dictionary Server, Redis keeps data in RAM rather than on disk, which lets it read and write in microseconds. In this guide I explain why Redis is so fast, when it actually helps, and how it fits into a web project as a cache, a session store and a queue, with practical examples.

What is Redis, and why is it so fast?

Redis is not designed to replace traditional relational databases (MySQL, PostgreSQL) but to sit in front of them as a fast layer. Because the whole dataset lives in memory, disk latency disappears. A few core traits build on top of that:

• It uses a single-threaded, event-driven model, which lets it handle hundreds of thousands of operations per second without lock contention.
• It offers more than plain text: rich data structures such as lists, sets, sorted sets, hashes and counters.
• If you want, it can also write data to disk (RDB snapshots or the AOF log) for durability across restarts.

So Redis is not just a "cache"; used well it can be a session store, a queue broker, a real-time counter and even a simple messaging channel.

Core commands and data structures

The fastest way to start working with Redis is the command-line client redis-cli. The most common commands are quite intuitive:

SET user:42:name "Aslain"
GET user:42:name
EXPIRE user:42:name 3600   # auto-delete after 1 hour
INCR page:views           # atomic counter
LPUSH queue:mail "id:1001" # push to the head of a list
HSET product:7 name "Keyboard" price 450

The EXPIRE and INCR commands here matter. Automatic expiry (TTL) makes Redis ideal for caching, while atomic increment lets you keep counters without race conditions. Using a colon-separated convention in key names like user:42:name makes it easy to group data logically.

Scenario 1: A cache layer

The most common use of Redis is storing the result of expensive queries or computations. The logic is always the same: check Redis first and return it if present; otherwise compute from the database, write it to Redis and return. In Laravel this pattern collapses to a single line, because once you pick Redis as the cache driver the whole Cache API uses Redis behind the scenes:

# .env
CACHE_STORE=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

use Illuminate\Support\Facades\Cache;

$popular = Cache::remember('projects:popular', now()->addHour(), function () {
    return Project::where('is_published', true)
        ->orderByDesc('views')
        ->take(10)
        ->get();
});

This turns a heavy query that hit the database on every page load into one that runs once an hour. To invalidate it at the right moment you use Cache::forget('projects:popular'); binding that line to model events when the content changes is the cleanest solution.

Scenario 2: A session store

On small single-server projects, keeping sessions in files is fine. But once several servers run behind a load balancer, a user may hit server A on one request and server B on the next; file-based sessions then keep logging the user out. Redis solves this at the root as a central, shared session store:

# .env
SESSION_DRIVER=redis

Now every server reads sessions from the same Redis instance, so the user stays logged in regardless of which server they land on. The same logic applies to cart data, "remember me" tokens and temporary user state. Since sessions naturally have a TTL, Redis's automatic expiry is a perfect fit here.

Scenario 3: Queues and background jobs

Work like sending an email, resizing an image or generating a report should not make the user wait. The solution is to push these jobs onto a queue and process them in the background, and Redis is an excellent broker for this because its list structure behaves like a natural queue. In Laravel the configuration is again simple:

# .env
QUEUE_CONNECTION=redis

// Push the job onto the queue — the request returns immediately
SendWelcomeEmail::dispatch($user);

// Run the worker on the server
php artisan queue:work redis --tries=3

Here the dispatch call adds the job to a Redis list and finishes the request instantly; the background queue:work worker pulls jobs off the list one by one and runs them. With --tries=3 failed jobs are retried a few times. This pattern speeds up the user experience while spreading server load over time.

Things to watch in production

Redis is powerful, but it can surprise you when misused. A few practical rules:

• Watch memory. Redis lives in RAM; if you write unbounded keys, memory fills up. Set maxmemory and an eviction policy (such as allkeys-lru).
• Make giving a TTL a habit. Cache keys written without expiry slowly turn into garbage buildup.
• Clarify your durability needs. If you only use it for cache, data loss is harmless; for sessions and queues, enabling AOF persistence is the safe choice.
• Lock down access. Do not leave Redis exposed to the outside world; bind 127.0.0.1 and a password (requirepass) are basic security steps.

Frequently Asked Questions

What is the difference between Redis and Memcached?

Memcached only does simple key-value caching. Redis adds data structures like lists, sets, hashes and sorted sets, plus persistence, replication and queue/pub-sub patterns. For pure throwaway caching either works; if you need more, Redis is far more flexible.

Is Redis data persistent, or is it lost on restart?

By default it lives in memory, but it has persistence options. RDB takes periodic disk snapshots, while AOF writes every operation to a log. Using both, you can restore data on restart; in a pure cache scenario, turning them off is also an option.

Is Redis mandatory for a small project?

No. On a single-server, low-traffic site, file cache and file sessions are more than enough. Moving to Redis makes sense once you have multiple servers, high traffic, real-time counters or a need for queues.

Want to speed up your project with Redis? Let's measure your web app's bottlenecks together and set up the right Redis configuration for cache, sessions and queues — get in touch with me.