DEV Community: Abhishek

Redis is fast, not loyal: why it should never be your main DB

Abhishek — Tue, 30 Jun 2026 18:02:54 +0000

So so so... you're going through Redis.

POV: You googled it or chatgpted it, AND wired Redis up. You run a read. It comes back before your finger even leaves the Enter key. You run a write. Done. Instant. No waiting, no spinner, nothing. (Must be the wind lol..)

import redis from 'ioredis'

const redis = new Redis(process.env.REDIS_URL || "redis://localhost:6379")

// redis.set redis.get redis.getTTL blah blah blah operations...

And then your super intelligence reached to nirvana and think like -

"Wait. This thing is insanely fast. Why am I still dragging Postgres around like a heavy backpack? Why not just put everything in Redis and call it a day?"

Like bruh seriously?? I had that exact thought. A lot of people do. It feels like you found a cheat code.

So let me walk you through why that cheat code gets you killed in the next level, in plain language, no textbook voice.

Why Redis feels like it broke the laws of physics

Redis keeps your data in memory. Just RAM. It does not run to the hard disk and back for every little thing the way a normal database does. That round trip to disk is the slow part of most databases, and Redis simply skips it.

Talking to it is almost too simple:

SET user:42 "Abhishek"
GET user:42

You hand it a key, it hands you the value. No tables. No joins. No query planner sitting in the corner judging your life decisions. Just key in, value out.

That speed is real and that simplicity is lovely. But hold that exact simplicity in your mind, because it is also the trapdoor you are about to fall through.

Redis is the funny guy at 2AM: here is what actually goes wrong

People expect one boring reason. There are four, and each one bites in a different spot.

1. RAM is the rich, picky friend who needs a hotel suite

Your data lives in memory. Sounds great until you remember memory is the most expensive room in the whole house.

A cheap disk holds a terabyte and nobody blinks. A terabyte of RAM is a fat server and a fatter invoice. So the day your data grows past what fits in memory, you hit a wall. Two choices. Pay a painful amount of money, or start throwing data out to make space.

A primary database is supposed to grow quietly for years without you thinking about it. Redis wants the whole dataset to fit in RAM today, comfortably, with legroom. Those two wishes do not get along, and your wallet is the one that suffers.

2. It can ghost you with your data (🚩)

This is the scary one. Read it twice.

Because Redis lives in memory, a crash or a restart wipes that memory clean. Redis does try to save copies to disk, but not on every single write. It either snapshots every few seconds, or appends writes to a file with a tiny delay.

Now play this out. A customer pays you. Redis says "got it, all good." One second later the server trips and dies. That payment can just vanish, because it was sitting in memory and had not been written to disk yet.

Think about that. The user has the money leaving their account, and your system has no memory of it ever happening. That is not a bug you debug at 2 in the morning. That is a refund email and a very awkward apology.

A real database refuses to play this game. When it tells you something is saved, it is saved, full stop. That promise is the entire reason databases exist. Redis trades a slice of that promise for speed, which is a brilliant deal for a cache and a terrifying one for your source of truth.

3. You can only find things if you already know where they are

Picture Redis as a giant wall of labeled drawers. Know the label, and the drawer flies open instantly. Do not know the label, and you are standing there sweating.

Here are questions your app asks every single day:

show me everyone who signed up last week
find every unpaid order above 500
how many users come from each city

In SQL, that last one is basically a single breath:

SELECT city, COUNT(*) FROM users GROUP BY city;

In Redis there is no clean way to ask that. There is no "search by city" button unless you personally built that index by hand and kept it perfectly updated on every write, forever. Forget one update and your data quietly lies to you, and you will not notice until a customer does.

So you end up rebuilding half of what a database already gives you for free, just to ask the most basic questions about your own data. That is a lot of homework to volunteer for.

4. It has no idea your data is connected

Most apps are a web of relationships. A user has orders. An order has items. An item belongs to a product. Pull one thread and the others should follow.

A relational database understands these links and guards them. It will not let you create an order pointing to a user who does not exist. It keeps the story straight on its own.

Redis does not care even a little. To Redis it is all just keys and values sitting next to each other like strangers in an elevator. Keeping every connection correct becomes your job, in your code, forever, with no safety net. One bad deploy and you have got orders floating in space attached to nobody.

So where do you actually let Redis cook?

Enough theory. Here is where Redis earns its paycheck, with the code to match. Nothing fancy, just the patterns you will reach for again and again.

Caching (the famous one). Check Redis first. If it is there, great, you skip the slow database. If not, go ask the real database, then stash the answer for next time.

async function getUser(id) {
  const cached = await redis.get(`user:${id}`)
  if (cached) return JSON.parse(cached)        // fast path, straight from memory

  const user = await db.users.findById(id)     // slow path, hit the real DB
  await redis.set(`user:${id}`, JSON.stringify(user), "EX", 3600) // keep it for 1 hour
  return user
}

That EX 3600 is the magic. It tells Redis to forget this on its own after an hour, so you never have to clean up.

Sessions and login tokens. Same idea, except expiry is the whole point. The token should die by itself when the session ends.

// when the user logs in
await redis.set(`session:${token}`, userId, "EX", 60 * 60 * 24) // gone in 24h, no cron job needed

Rate limiting. Stop one angry user from hammering your API. Count their hits, and start a timer the first time you see them.

const hits = await redis.incr(`rate:${userIp}`)
if (hits === 1) await redis.expire(`rate:${userIp}`, 60) // open a 60 second window
if (hits > 100) throw new Error("Slow down buddy, too many requests")

This is the kind of thing Redis does in microseconds without breaking a sweat, while doing it in a normal database on every request would set your server on fire.

Leaderboards and live counts. Redis has a special list that stays sorted by score for you. Perfect for "top players" or "trending now".

await redis.zadd("leaderboard", 1500, "player:42")             // add or update a score
const top10 = await redis.zrevrange("leaderboard", 0, 9)       // grab the top 10 instantly

Notice the theme across all four. None of these is your source of truth. If Redis lost every bit of this tomorrow, your app would hiccup for a second and recover. That is exactly the kind of data Redis was born to hold.

The whole thing in one breath

Redis is fast because it skips the slow, boring, careful work.

A primary database exists to do exactly that slow, boring, careful work, because that is what keeps your data safe, findable, and honest.

So let Redis do speed. Let a real database do truth. Stand them side by side and you get both, instead of betting your business on one of them pretending to be the other.

Asking Redis to be your only database is like asking a race car to be your moving truck. Sure, it is fast. No, it is not getting your entire life across town without scattering half your furniture across the highway.

Use the race car to race. Use the truck to move. Stop expecting a cruiser bike to climb Himalayas.

Last but not the least if you enjoy my content, don't forget to leave a like & follow 𝕏 @0bhishek .✦ ݁˖
See you in next one (˶˃ ᵕ ˂˶)

Why AI Agents Cost More Than LLMs (And How to Stop Bleeding Tokens)

Abhishek — Mon, 11 May 2026 07:23:58 +0000

I was building a small bookmark app last weekend. You send it a URL, Gemini
summarizes and tags the page, the result goes into Postgres. A few hundred lines
of TypeScript.

The first version cost almost nothing. One LLM call per URL, that's it. Then I
added "tools" so the model could fetch pages, look up similar bookmarks, or
check things against Google Search.

My token bill quadrupled.

That's where most people building agents land for the first time. Going from a
plain chat call to an agent loop is way more expensive than docs make it sound,
and the reason isn't obvious until you watch the round trips happen one by one.
Let's do that.

What a plain LLM call costs

Here's the simplest LLM call in TypeScript with @google/genai:

import { GoogleGenAI } from '@google/genai';

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });

const res = await ai.models.generateContent({
  model: 'gemini-2.5-flash',
  contents: 'Summarize this article: ...',
});

console.log(res.text);

One request out, one response back. You pay for two things:

Input tokens for your prompt
Output tokens for the model's reply

That's it. Two numbers on your bill. If your prompt is 500 tokens and the answer
is 200, you pay for 700 tokens. Done.

Now add a single tool

Tools are how the model talks to the outside world. Calling an API, querying a
database, fetching a URL, anything. You describe each tool with a small JSON
schema, and the model can ask to "call" one mid-conversation. You actually run
the function, send the result back, and the model writes its final answer using
that result.

The basic version:

import { GoogleGenAI, Type } from '@google/genai';

const tools = [{
  functionDeclarations: [{
    name: 'getWeather',
    description: 'Get the weather of any city',
    parameters: {
      type: Type.OBJECT,
      properties: {
        location: { type: Type.STRING },
      },
      required: ['location'],
    },
  }],
}];

const first = await ai.models.generateContent({
  model: 'gemini-2.5-flash',
  contents: 'What is the weather in Tokyo?',
  config: { tools },
});

console.log(first.text);
// → undefined

undefined?

The model didn't answer. It returned a structured request:

first.functionCalls
// → [{ name: 'getWeather', args: { location: 'Tokyo' } }]

This is the part that surprises people. The model got asked a question, and
instead of answering, it asked you to run a function. So you do that and
ship the result back:

const result = getWeather('Tokyo');  // { temperature: 23, condition: 'sunny' }

const second = await ai.models.generateContent({
  model: 'gemini-2.5-flash',
  contents: [
    { role: 'user',  parts: [{ text: 'What is the weather in Tokyo?' }] },
    { role: 'model', parts: [{ functionCall: { name: 'getWeather', args: { location: 'Tokyo' } } }] },
    { role: 'user',  parts: [{ functionResponse: { name: 'getWeather', response: result } }] },
  ],
  config: { tools },
});

console.log(second.text);
// → "It's 23°C and sunny in Tokyo."

Two LLM calls. One question. That's the agent tax.

Why we can't just do it in one call

The first reaction (mine too): why can't the model just answer in one shot?

The reason is simple. The model can't predict what the tool will return. The
temperature in Tokyo isn't in its training data, the API hasn't been hit yet,
the result doesn't exist. You can't write "It's 23°C in Tokyo" before you know
it's 23°C.

So turn 1 is "decide what to do." Turn 2 is "use what you learned." They can't
be merged. The model has no memory between calls.

One exception is worth knowing about: server-side tools. Things like
googleSearch or urlContext in Gemini run inside Google's own servers, and
the API returns one merged response. From your side it looks like a single call.
You lose some control (you can't see exactly what got searched), but you save
a round trip.

Counting the actual tokens

Here's where the cost lives. Look at what turn 2 has to send compared to turn 1:

	Turn 1 in	Turn 1 out	Turn 2 in	Turn 2 out
System prompt	yes		yes, billed again
Tool schemas	yes		yes, billed again
User question	yes		yes, billed again
Model's tool call		yes	yes, as input
Your tool result			yes
Final answer				yes

Your system prompt and tool definitions get sent to the API twice. Turn 1
doesn't free you from re-sending everything in turn 2, because the model is
stateless. It forgets the whole conversation between calls.

Real numbers from my bookmark agent:

System prompt: ~200 tokens
4 tool declarations: ~400 tokens
User question: ~50 tokens
Tool result (a few rows from Postgres): ~300 tokens

Plain LLM call:    ~650 in  +  ~200 out  =  ~850 tokens
One-tool agent:   ~1300 in  +  ~230 out  = ~1530 tokens (about 1.8x)

And that's the best case. Exactly one tool call, no follow-ups. Real agents are
worse. A lot worse.

Real agents grow quadratically

The bookmark agent does three things on a new URL:

Fetch the page (fetchUrl tool)
Look for similar existing bookmarks in the DB (searchSimilar tool)
Pick a category from the user's existing taxonomy (getTaxonomy tool)

That's 4 LLM turns total. Ask, get tool calls, send back results, ask again,
get more calls, send results, finally write the summary.

What the cumulative input size looks like each turn:

Turn	What gets sent	Input tokens
1	system + schemas + URL	700
2	+ previous calls + `fetchUrl` result (~1500 of page)	2200
3	+ `searchSimilar` result	2400
4	+ `getTaxonomy` result	2600

Total input across all turns: about 7900 tokens to summarize one webpage.

For comparison, a plain generateContent({ contents: "summarize this:\n" + pageText })
costs ~1500 input + 200 output. About 1700 tokens.

Same task. Almost 5x the bill.

It gets worse. Cost grows quadratically with the number of turns, because
each turn replays everything that came before. A 10-turn agent isn't 10x the
cost. It's closer to 30x.

Three ways to stop the bleeding

You're not stuck. Here's what actually works.

1. Prompt caching

The biggest lever by far. Every major provider supports it now: OpenAI,
Anthropic, Google. The system prompt and tool schemas don't change between
turns, so cache them once and pay about 25% of the input cost on every reuse.

With @google/genai:

const cache = await ai.caches.create({
  model: 'gemini-2.5-flash',
  config: {
    systemInstruction: 'You are a bookmark organizer...',
    tools,  // these never change across turns
  },
});

const res = await ai.models.generateContent({
  model: 'gemini-2.5-flash',
  contents: history,
  config: { cachedContent: cache.name },
});

For my 4-turn flow this cuts input costs by roughly half. Anthropic and OpenAI
do the same thing with different syntax.

Gemini also has implicit caching. It auto-caches recent prefixes for you with
zero code changes. You just see cheaper retries. Check if your provider has it
on before reinventing the wheel.

2. Different model per turn

The "decide which tool to call" turn is dumb work. It barely needs reasoning.
It's pattern matching on a question. The final synthesis turn is where you
actually want a smart model.

// Cheap, fast: decides what to do
const decision = await ai.models.generateContent({
  model: 'gemini-2.5-flash-lite',
  // ...
});

// Smarter: writes the actual answer
const finalAnswer = await ai.models.generateContent({
  model: 'gemini-2.5-pro',
  // ...
});

In a 4-turn flow, three of the turns can run on the cheap model. Only the last
one, the user-facing answer, needs the expensive one. For high-volume agents
this saves more than caching does.

3. Parallel tool calls

The model can ask for multiple tools in a single response. Code I see in
tutorials usually does functionCalls[0] and silently drops the rest, turning
what could be one round trip into many.

The fix is one line of Promise.all:

const results = await Promise.all(
  resp.functionCalls.map(async (c) => ({
    name: c.name!,
    response: await dispatchers[c.name!](c.args),
  }))
);

For "summarize all my React bookmarks from last month," the model might call
searchBookmarks and getDateRange in parallel. Handle both, and you save a
whole round trip.

What you can't optimize away

Tools have a real cost, and they buy you real value. The reason you reach for
them is the same reason they're expensive. You're forcing the model to use
facts that exist outside its head instead of making them up.

A plain LLM call will happily tell you the weather in Tokyo. It'll just be
wrong.

Quick way to think about it when picking an architecture:

Plain LLM is a guess from training data. Cheap, fast, hallucinates.
Tools / agent is real data. Expensive, slower, honest.

Most apps shouldn't be agents. If your task is "summarize this text I'm pasting
in" or "rewrite this email," you don't need tools. You need one call. A lot of
agent frameworks make it really easy to add tools by default, which makes it
really easy to spend 5x what you should.

Tools earn their cost when you have side effects (writing to a DB, sending a
message), grounded data (today's weather, this user's bookmarks, current docs),
or chained reasoning where intermediate steps actually need verification.

They don't earn it on anything you could solve with one good prompt.

The receipt

Last week I added one tool to a Gemini call and watched the cost go from 850
tokens to 1530 for the same question. Once I started parallelizing calls and
caching the system prompt, I got the bookmark agent down to about 4500 tokens
across all four turns. Still 2.5x a plain call, but way better than the 7900
the naive version was burning.

Your agent isn't a smarter LLM. It's the same LLM with a longer receipt. Once
you can read the receipt, every optimization becomes obvious.

If you like my content support by like and share 💟 also dont forget to follow me on Twitter/X and LinkedIn. If you want me to connect, checkout my site. See you in next one.

How I Build an NPM Package that lets you Scaffold React Apps

Abhishek — Wed, 03 Sep 2025 17:31:48 +0000

Okay, So I finnaly made an NPM package so that you don't need to find each and every dependencies. In this blog, I am going to walkthrough the process how you can try this package yourself.
I will also share how I came to making one more npm thingy, here we go.

Let first start with a question:

What is An NPM Package?

=> NPM is a package manager for Node. js packages, or modules if you like. www.npmjs.com hosts thousands of free packages to download and use. The NPM program is installed on your computer when you install Node.js. If you installed Node.
That's a preety boring definition, here is the simpler version

An npm package is basically a bundle of reusable code that you (or anyone) can install and use in a Node.js project. Think of it as a little Lego piece—easy to plug in, whether it’s for adding a button component, handling dates, or powering a whole framework.

My First NPM package

I found out the process of setting up each package one by one, why not make a scaffold tool like a thing so that anyone can just hit the command, do some'enter...enter' and get their react project as it it.
I tried to implement some CI/CD files and vercel.json to make the process further helpful.

To install the npm package, you need to enter this command in your terminal-

npx react-starter-plus

The prompts you need to follow

Project name → my-react-app
Language → JavaScript / TypeScript
Git setup → Initialize repo & push to GitHub (provide remote URL)
Extras →

CI/CD with GitHub Actions?
Zustand for state?
React Testing Library?
1. Deployment → Deploy with Vercel (make sure you’re logged in with vercel login)
2. Deploy now or later → Your call.

Get the Summary & Setup

The CLI shows a summary before proceeding. If everything looks good, it:

Installs dependencies
Sets up Tailwind + routing
Initializes Git & pushes to remote
Configures CI/CD
Deploys to Vercel

And done

You’ll end up with something like:

✔ Deployment successful:
https://johndoes-project.vercel.app

→ Run it locally with `npm run dev`

Then you can choose how your React project gonna be-
and finnaly you get this-

That's all for this project, if you find this helpful at any point, leave a start 🌟.