What is Redis?

Introduction

Redis (Remote Dictionary Server) is an open-source, in-memory data structure store. Salvatore Sanfilippo built it in 2009 to solve problems MySQL could not — real-time counters, rankings, and pub/sub at high throughput.

Today Redis acts as a cache, primary database for ephemeral data, message broker, and streaming platform. Major companies use it wherever latency and throughput matter more than complex relational queries.

If you have used Memcached, think of Redis as Memcached plus data structures, persistence, and replication.

Understanding the topic

Key concepts

• Key-value at the top level — every piece of data lives under a string key.
• Values can be strings, lists, sets, sorted sets, hashes, streams, and more.
• All commands are atomic — no partial updates visible to other clients.
• Optional persistence writes snapshots (RDB) or an append-only log (AOF) to disk.
• Clients speak RESP (Redis Serialization Protocol) over TCP, default port 6379.
• Redis is not a replacement for every database — use it where speed and simple access patterns dominate.

flowchart LR
  Client -->|RESP| Redis
  Redis -->|result| Client

Step-by-step explanation

1. Client connects and optionally authenticates (ACL/password).
2. Commands are read from the socket buffer and parsed.
3. Redis looks up the command handler and validates arguments.
4. The operation runs against the in-memory keyspace (dict + typed object).
5. Response is formatted in RESP and written back to the client.

Syntax reference

Common commands

• SET/GET — basic cache and counters.
• HSET/HGET — store objects without one big JSON blob.
• ZADD — score + member for rankings.

# Strings
SET user:1001:name "Ada"
GET user:1001:name

# Hash (object fields)
HSET user:1001 email "ada@example.com" role "engineer"
HGET user:1001 email

# Sorted set (leaderboard)
ZADD leaderboard 9850 "user:1001"
ZRANK leaderboard "user:1001"

Informative example

Store and retrieve a user profile using a hash — partial updates without rewriting the whole object:

HSET user:42 name "Ada" email "ada@co.com" plan "pro"
HGET user:42 name
# "Ada"
HSET user:42 lastLogin "2026-07-01T10:00:00Z"
HGETALL user:42

Hashes are ideal when you update individual fields (last login, plan tier) frequently.

Real-world use

Real-world use cases

• API response caching — GET/SET string with TTL.
• Shopping cart — hash fields per line item.
• Leaderboard — sorted set by score.
• Job queue — list with LPUSH/BRPOP.
• Feature flags — string or hash with short TTL.

Best practices

• Pick the Redis type that matches your access pattern.
• Use meaningful key names with colons as separators.
• Set TTL on data that can expire.
• Use Redis 7+ for latest encodings and security (ACL).
• Run managed Redis (ElastiCache, Redis Cloud) in production when possible.
• Keep values small — large blobs hurt memory and latency.

Common mistakes

• Storing everything as JSON strings when hashes or zsets fit.
• No key naming convention — impossible to debug or flush by prefix.
• Using Redis for heavy analytics that belong in a warehouse.
• Forgetting that default install has no password on localhost only.

Advanced interview questions

Summary

Redis is an in-memory data structure server with a flat key namespace.