Redis for Beginners: Keys, Data Types, TTLs, and When to Use It

Redis for Beginners: Keys, Data Types, TTLs, and When to Use It

Redis is easiest to understand as a fast data-structure server. Your application connects to Redis, stores values under keys, and uses commands to read or modify those values.

The important part is that Redis does more than simple key-value storage. A key can hold a string, hash, list, set, sorted set, stream, JSON document, and other specialized structures.

If you are new to Redis, learn these four ideas first:

1. keys identify data;
2. each key has a data type;
3. commands operate directly on those data types;
4. keys can expire automatically with a TTL.

Once those ideas click, most Redis use cases become much easier to understand.

The basic mental model

Think of Redis as a server containing named pieces of data:

user:42:name          -> "Asha"
session:abc123        -> hash
online_users          -> set
leaderboard:weekly    -> sorted set
notifications         -> stream

Your application sends commands such as:

SET user:42:name "Asha"
GET user:42:name

Redis returns the result immediately over the client connection.

The Redis quick-start documentation describes Redis as usable for databases, caches, streaming, messaging, and other workloads because these data structures can model many common application problems directly.

Start with strings

Strings are the simplest Redis type.

SET greeting "hello"
GET greeting

Result:

"hello"

Strings can also store numbers and support atomic counters:

SET page_views 0
INCR page_views
INCR page_views
GET page_views

This is useful for counters because Redis performs the increment on the server instead of requiring the application to read the old value, calculate a new one, and write it back.

The SET command can also attach an expiration when the value is created:

SET verification:abc123 "842931" EX 300

That key expires after 300 seconds.

TTLs are one of Redis' most useful features

A TTL—time to live—defines how long a key should remain in Redis.

You can set one separately:

SET session:abc123 "user-42"
EXPIRE session:abc123 1800

Then inspect it:

TTL session:abc123

According to the official TTL documentation, Redis returns the remaining lifetime in seconds, -1 when a key exists without an expiry, and -2 when the key no longer exists.

TTLs make Redis a natural fit for short-lived data such as:

• sessions;
• verification codes;
• temporary locks;
• cached responses;
• rate-limit buckets;
• idempotency keys.

The key disappears automatically when it expires, so the application does not need a cleanup query for every temporary record.

Redis data types in plain English

Redis provides several useful structures. The full current list is in the Redis data type documentation, but beginners should understand these first.

Strings

Store text, bytes, numbers, counters, or serialized values.

SET feature:dark_mode "enabled"
INCR api:requests

Use them for simple values and counters.

Hashes

A hash stores fields under one Redis key.

HSET user:42 name "Asha" plan "pro" city "Delhi"
HGET user:42 plan
HGETALL user:42

A hash is useful for compact objects whose fields you want to update independently.

Lists

Lists keep ordered values and support pushing or popping from either end.

LPUSH recent_jobs job-123
LPUSH recent_jobs job-124
LRANGE recent_jobs 0 9

They are useful for simple ordered sequences. For reliable event-processing workflows, however, understand Redis Streams before treating a plain list as a complete queue system.

Sets

Sets contain unique members.

SADD online_users user-42
SADD online_users user-77
SISMEMBER online_users user-42

They are useful for membership questions such as “is this user currently in this group?”

Sorted sets

Sorted sets store unique members ordered by a numeric score.

ZADD leaderboard 950 player-a
ZADD leaderboard 1200 player-b
ZRANGE leaderboard 0 9 REV WITHSCORES

The Redis sorted-set documentation highlights leaderboards and rate-limiters as common examples.

Streams

Streams store ordered entries and support consumer-oriented event processing.

They are useful when you need an append-oriented event log with richer processing semantics than a simple list.

Redis keys need a naming convention

Redis does not force a key-naming scheme, so your application should create one.

A practical pattern is:

resource:id:purpose

Examples:

user:42:profile
user:42:session:abc123
product:991:cache
rate_limit:user:42

Good key names make debugging easier and reduce accidental collisions.

Do not make keys unnecessarily huge, and do not depend on scanning the entire keyspace as part of normal request handling.

Avoid KEYS * in normal production code

Beginners often discover this command:

KEYS *

It is useful while experimenting with a tiny local database, but Redis' keyspace documentation warns that KEYS can block the server while it walks a large keyspace.

For incremental iteration, Redis provides SCAN:

SCAN 0 MATCH user:* COUNT 100

Even then, application data should usually be accessed through known keys or explicitly maintained indexes rather than broad key scans.

Redis is fast, but that does not mean “put everything in Redis”

Redis often serves data from memory, which makes it attractive for latency-sensitive workloads. But memory is not free, and Redis has a different query model from relational databases.

Redis is a strong fit when you need:

• cached data;
• fast counters;
• expiring state;
• session storage;
• sets and leaderboards;
• real-time state;
• streams or queue-like workflows;
• known key-based access patterns.

A relational database such as PostgreSQL or MySQL is usually a better default when you need:

• complex joins;
• rich ad-hoc queries;
• durable business records;
• relational constraints;
• large historical datasets;
• complex multi-row transactions.

Redis can also be configured with persistence, but beginners should not assume that “Redis is fast” means it should automatically replace the application's primary database.

A common beginner architecture

One of the most useful patterns is to keep durable business data in the primary database and use Redis for data that benefits from fast temporary access.

For example:

1. the application requests product 42;
2. it checks product:42:cache in Redis;
3. if the key exists, use it;
4. otherwise query the main database;
5. place the result in Redis with a TTL.

This is called cache-aside and is one of the easiest ways to understand how Redis complements a normal database.

What happens when Redis restarts?

The answer depends on how Redis is configured.

Redis supports persistence options such as RDB snapshots and AOF logging, but some deployments deliberately run without persistence because all stored data is disposable cache data.

That means you should classify every Redis key:

• rebuildable: safe to lose and recreate;
• temporary: expected to expire anyway;
• important: needs persistence, replication, backup, and recovery planning.

Do not discover during an outage that an “important” key existed only in memory.

Five commands worth practicing first

Start with these:

SET demo "hello"
GET demo
EXPIRE demo 60
TTL demo
DEL demo

Then practice one structure at a time:

HSET user:1 name "Asha"
SADD active_users user:1
ZADD scores 100 user:1

Using redis-cli locally is often the fastest way to build intuition because you can see exactly what each command does.

Common beginner mistakes

Using Redis without a memory limit or capacity plan

A cache that grows forever eventually becomes a reliability problem.

Storing huge serialized objects for every key

Large values increase memory usage and network transfer. Model only what the workload needs.

Forgetting TTLs for temporary data

Session, cache, and verification keys often need expiration by design.

Treating Redis as a relational database

If you constantly need joins, arbitrary filters, and complex reporting, the data model probably belongs elsewhere.

Using key scans in request paths

Prefer direct key access or explicit Redis structures that model the lookup you need.

The beginner takeaway

Redis becomes much less mysterious once you stop thinking of it as simply “a faster database.”

Think in keys + data types + commands + TTLs.

Use strings for simple values, hashes for field-based objects, sets for membership, sorted sets for ranking, streams for event-oriented workflows, and expirations for temporary state. Keep Redis focused on access patterns that match its strengths, and let your primary database handle relational or long-term data when that model fits better.