Building my first Redis-powered feature

Viraj — Fri, 16 Jan 2026 18:33:00 GMT

When I started doing backend development, I was building the authentication module for a project. The flow was straightforward: the frontend sent a JWT token, the backend verified and decoded it, extracted the user id, and then queried the database to confirm the user existed.

I ended up building three auth APIs: one for signup, one for login, and one for Google OAuth (login/signup). This post is about the login side—and more specifically, what I learned after it “worked.”

A couple of days in, I noticed a pattern: every time I hit a protected API, the backend repeated the same routine. JWT comes in → verify/decode → extract user id → query the database → respond. And it wasn’t a one-time thing. It happened on every request that required authentication.

That’s when I paused and asked myself: can this be faster? Instead of going to the database every time and searching through thousands of users, can I keep the frequently needed data somewhere quicker?

Coming from a frontend background, my first instinct was almost funny in hindsight: “What if I store the user in localStorage?” Then it clicked—there’s no localStorage on a server. That’s a browser feature, not something your backend can rely on.

While exploring better options, I came across Redis and the idea of in-memory caching. The promise was simple: keep hot data in RAM, fetch it in microseconds, and avoid unnecessary database queries. I dug into the docs and implemented it step by step.

Here’s what I changed: on login (and on subsequent authenticated requests), after verifying and decoding the JWT, I’d take the user id and check Redis first. If Redis had the user (or the minimal data I needed), I could skip the database call. If Redis didn’t have it, only then I’d query the main database—and immediately store the result in Redis with a TTL, so future requests could be served faster.

After doing this, I could clearly see the difference. The system stopped hitting the database for the same repeated lookups, and overall latency dropped noticeably (in my case, roughly half for those paths).

The bigger lesson for me wasn’t just “Redis is fast”—it was understanding why the bottleneck existed and how caching fits into backend thinking: reduce repeated expensive operations, and use the database for what it should do best, not for the same lookups again and again.

Retrieval-Augmented Generation (RAG) Explained: A Complete Guide

Viraj — Tue, 14 Oct 2025 08:00:34 GMT

What is RAG?

RAG stands for Retrieval-Augmented Generation. It's an AI architecture that combines information retrieval systems with generative AI models to produce more accurate, up-to-date, and contextually relevant responses.

Simple Analogy: Think of RAG like a student taking an open-book exam. Instead of memorizing everything (like traditional AI), the student can reference textbooks (external knowledge) to give accurate answers. This reduces the chance of making up incorrect information.

The Two Core Phases of RAG

Phase 1: Ingestion/Indexing (The Knowledge Storage Phase)

This is where we prepare and store data in a vector database for quick retrieval.

The Process:

Document Upload - You have a PDF (could be 100, 1000, or 10,000 pages)
Chunking - Breaking the document into smaller, digestible pieces
Vector Embeddings - Converting these chunks into mathematical representations
Storage - Saving these embeddings in a vector database

Why Chunking?

LLM APIs have rate limits and token constraints
Processing everything at once would overload servers
Smaller chunks enable precise retrieval

Analogy: Imagine organizing a massive library. Instead of memorizing every book, you create an index card system where each card contains a summary and location. When someone asks a question, you quickly find the relevant cards instead of reading every book.

Phase 2: Retrieval/Generation

In the retrieval phase, the process unfolds in several key steps:

User Query - The user submits a prompt or question through the interface
Query Embedding - The prompt is converted into a vector embedding using the same embedding model used during the indexing phase (this consistency is crucial for accurate matching)
Similarity Search - The query embedding is compared against all stored embeddings in the vector database. The database uses similarity metrics (like cosine similarity or Euclidean distance) to find the most relevant chunks
Context Retrieval - The vector database returns the top-k most similar chunks (typically 3-5 chunks, though this is configurable based on your needs)
Prompt Augmentation - The retrieved context is combined with the user's original query to create an enriched prompt. This gives the LLM relevant background information
LLM Generation - The augmented prompt is sent to an LLM (ChatGPT, Claude, Gemini, Llama, or any other model). The LLM generates a response grounded in the retrieved context
Response Delivery - The final output is returned to the user

The Result: Users receive responses that are contextually accurate, grounded in your specific data source, and significantly less prone to hallucinations.