Redis: Introduction & Fundamentals

Source: Chai aur Code — Advanced Backend: Redis

Series: Advanced Backend Playlist

⚠️ Opinions Disclaimer

Database boundaries are getting blurred. Postgres can behave like Redis in some cases. The opinions in these notes are standard industry opinions but can be challenged as databases evolve rapidly with new enhancements.

1. What is Redis? (The Kirana Store Analogy)

Analogy: Imagine a kirana (grocery) store.

First request: A user asks “What’s the price of tea?” → The shopkeeper goes to the back store, opens a register, looks up the price, comes back, and tells the user.
Second request (same question): Another user asks the same question → The shopkeeper repeats the entire process, goes to the back, opens the register, looks it up again.
At scale (10,000× requests): This becomes a bottleneck. The shopkeeper can’t keep going to the back store for every identical question.
The solution: Put a board at the front with frequently asked prices (e.g., “Tea = ₹20”). Now every user reads the board directly, comparatively much faster.

That board is essentially what Redis is.

2. Redis at a Glance

Full Form- REmote DIctionary Server

Type- In-memory data store (key-value)

Speed- Lightning fast, serves from RAM, not disk

Persistence- Supports persistent data (reloads from disk files on server restart, but always serves from memory)

Common Names- In-memory store, hashmap store, in-memory DB, caching layer

Why is it fast? Everything is loaded and served from RAM. Reading from RAM is orders of magnitude faster than reading from disk (even SSD).

“But it’s in-memory, won’t data vanish on restart?” No. Redis supports persistence. On restart, it reloads data from its dump files back into memory. But it always serves from memory.

3. Where Redis Fits in Your Architecture

                    ┌──────────────┐
   User ──────────► │  Backend App │
   (req/res)        │ (Node/Spring/│
                    │  FastAPI etc)│
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼                         ▼
        ┌──────────┐            ┌──────────────┐
        │  Redis   │            │   Database   │
        │ (Cache)  │            │ (Mongo/PG/   │
        │          │◄───────────│  MySQL etc)  │
        └──────────┘  populate  └──────────────┘
                      cache on
                      miss

Flow

Request comes in → Backend checks Redis first.
Cache Hit → Data found in Redis → respond immediately (fast path).
Cache Miss → Data NOT in Redis → query the Database → store result in Redis for next time → respond to user (slower path, but only happens once per unique query).

Critical Rules

Redis is NEVER a replacement for your database. Your database (Mongo, Postgres, MySQL) remains the source of truth.
Think of it as: Database = your notebook (permanent record), Redis = writing on your hand (quick temporary reference).
Write operations mostly go directly to the database. Redis is primarily used to speed up reads.

4. Network Latency Consideration

┌──────────────────────────────────────────┐
│             Same VPC / Network           │
│                                          │
│  Backend App ◄──► Redis ◄──► Database    │
│                                          │
└──────────────────────────────────────────┘
         ▲
         │ If Redis is OUTSIDE your network,
         │ network latency will eat into
         │ the performance gains.

The speed comparison (Redis vs DB) does not account for network latency.
Network call overhead exists for both Redis and your DB.
If everything is in the same VPC (same network) → it stays fast (local calls).
If Redis is moved inside your application process (in-app memory), it becomes ridiculously fast — but this is rarely done in production.

5. The Bottleneck Problem Redis Solves

Scenario: E-commerce app listing products.

Traffic grows → you scale horizontally (multiple Node servers behind a load balancer).
All servers hit the same database → DB becomes the bottleneck.
Your API queries are already optimized, the database lookup time itself is the bottleneck.
Solution: Introduce Redis between your servers and the DB.

Cache Miss vs Cache Hit

Cache Hit | Request → Redis has data → Respond immediately |⚡ Fast

Cache Miss | Request → Redis doesn’t have data → Query DB → Store in Redis → Respond | 🐢 Comparatively slower (first time only)

What Redis achieves here

Reduces read pressure on the database (writes still go to DB).
Faster responses for hot/frequently-requested data.
The data that users ask for repeatedly (hot data) gets cached.

Real-World Example

Swiggy/Zomato — the restaurant menu for your city doesn’t get fetched from the DB on every request. It’s served from a cache (Redis or similar).

6. Common Use Cases of Redis

6.1 Caching (Primary Use Case)

Client ──► Redis ──► DB
             │
             ◄── (populate on miss)

Already covered above. Cache frequently read data to reduce DB load.

6.2 Session Store

┌──────────┐
│ Server A │──┐
└──────────┘  │    ┌────────────────────────────┐
              ├──► │        Redis               │
┌──────────┐  │    │  user:1 → active           │
│ Server B │──┘    │  user:2 → inactive         │
└──────────┘       └────────────────────────────┘

Store user sessions (logged in / logged out) in Redis.
All servers can check the same Redis instance — no need to query DB every time.
When a user logs out → update DB and Redis.
Fast lookups since Redis is in-memory.

6.3 OTP Storage

Client ──► "Request OTP" ──► Redis
                              │
                    ┌─────────┴─────────┐
                    │ otp:9876543210    │
                    │ value: 4343       │
                    │ TTL: 3 minutes    │
                    └───────────────────┘

OTPs are temporary — valid for only a few minutes.
No need to store in a permanent database.
Store in Redis with a TTL (Time To Live) → auto-deletes after expiry.
If Redis crashes? User simply requests a new OTP — no critical data loss.

6.4 Rate Limiting

Client (repeated login attempts)
   │
   ▼
Redis: ip:xxx.xxx.xxx → count: 6, TTL: 10 min, status: cooldown

Track how many times a user/IP has attempted an action (login, OTP request, etc.).
If count exceeds threshold → block them for a cooldown period.
Store the counter + cooldown status in Redis with a TTL.
After TTL expires → record auto-deletes → user is unblocked.
No database hit needed for this entire flow.

6.5 Job Queues (Background Jobs)

┌──────────────────────────┐
│  Redis List / Queue      │
│  [batch1, batch2, ...]   │
└────────┬─────────────────┘
         │
    ┌────┴────┐
    ▼         ▼
 Worker 1  Worker 2
(Node App) (Node App)

Redis maintains a list/queue of jobs.
Workers (just regular backend applications) pick tasks from the queue and process them.
Example: Sending emails in batches of 10 → Worker picks a batch, sends emails, marks success/failure.
A “worker” is nothing special — it’s just another backend application that processes queue items instead of serving HTTP requests.

7. Key-Value Pairs in Redis

Redis stores everything as key-value pairs. This is the fundamental data model.

Naming Conventions

Key                          Value
─────────────────────────    ─────────────────────────────
product:all                  [{ id: 1, name: "..." }, ...]
product:hot                  [{ id: 5, name: "..." }, ...]
otp:9876543210               "4343"
session:abcd1234             { "userId": 4, "email": "...", "role": "user" }

Best Practices for Keys

Human-readable — easy to understand at a glance.
Use colons (:) as separators — otp:9876543210, session:userId123.
Avoid collisions — make keys specific: product:all vs product:hot.
Think about debugging — you’ll thank yourself later when inspecting Redis in production.

8. TTL (Time To Live)

TTL defines how long a key-value pair stays alive in Redis.

Timeline:
──────────────────────────────────────────────►
t=0          t=90s                    t=180s
◄── Key is VALID ──►  ◄── Key is INVALID / AUTO-DELETED ──►
     (TTL = 90s)

TTL: Time To Live — duration for which a record is valid

Auto-delete: After TTL expires, Redis automatically removes the key

Use cases: OTPs, sessions, rate-limit counters, cached data

This is one of Redis’ most powerful features, automatic expiry and cleanup with zero application logic.

9. When to Use Redis (Checklist)

Ask yourself these questions before reaching for Redis:

Question If Yes → Redis could help

Do I need to reduce read pressure on my DB? ✅ Caching

Do I have temporary/expiring data (OTPs, tokens, sessions)? ✅ TTL-based storage

Do I need shared counters across multiple servers (rate limits, page views, likes)? ✅ Atomic counters

Do I need to handle background jobs (email queues, notification queues, report generation)? ✅ Job queues

10. When NOT to Use Redis

Not a database replacement. Your DB is always the source of truth.
Not a solution for every performance problem. If you don’t understand the bottleneck, Redis won’t magically fix it.
Not a substitute for MongoDB/Postgres. Saying “why not just use Redis instead of Mongo?” is a fundamental misunderstanding of their roles.
Write-heavy workloads — writes mostly still go to your primary DB.

If you can’t identify which problem from the checklist above applies to you, you probably don’t need Redis yet.

11. Redis Alternatives & Ecosystem

All of these are drop-in replacements for Redis (same API, same client libraries, just swap the connection string):

KeyDB: Fully open-source, backed by Snap, multi-threaded (faster at scale)

Dragonfly DB: High-performance, used by Instacart, Meesho, and others

Valkey: Born after the Redis license controversy, one of the most popular forks

Memcached: Older alternative, simpler feature set

Upstash Platform: (not a DB itself) — gives you managed Redis + queues as a service

“Drop-in replacement” means: change the connection URL in your env vars → all your existing Redis code works as-is. Everything learned in this series applies to all of these.

12. Quick Revision Summary

Redis = In-memory key-value store (serves from RAM, persists to disk)

Primary Use Cases:
  1. Caching          → Reduce DB read pressure, serve hot data fast
  2. Session Store    → Shared session state across multiple servers
  3. OTP / Temp Data  → Auto-expiring data with TTL
  4. Rate Limiting    → Track + block excessive requests with TTL
  5. Job Queues       → Background task processing via lists

Key Concepts:
  • Key-Value pairs with colon-separated naming (product:all, otp:9876543210)
  • TTL (Time To Live) → auto-expiry and cleanup
  • Cache Hit (fast) vs Cache Miss (slower, populates cache)
  • Redis ≠ Database replacement. DB = Source of Truth.
  • Network latency matters — keep Redis in the same VPC as your app.

Next: Docker setup & hands-on Redis commands.