DEV Community: Anubhav Gupta

The Hidden Cost of AI: Moving from Tutorial Code to Production Code

Anubhav Gupta — Mon, 22 Jun 2026 16:15:00 +0000

If you've watched a web development tutorial in the last year, chances are you've seen someone build an "AI-powered" app. The instructor pastes their OpenAI API key into an environment file, writes a simple fetch request, and within 10 minutes, the app is magically generating text.

It looks incredibly easy. So, you build your own version. It works perfectly on localhost:3000. You're ready to deploy and share it with the world.

Then, the panic sets in.

What happens if someone shares your link on Reddit? What if a user absentmindedly clicks the "Generate" button 50 times? What if a malicious bot finds your open endpoint?

Because AI APIs charge by the "token" (the amount of text processed), an unprotected endpoint isn't just a bug—it's a financial liability.

Here is what tutorials don't tell you, and how I had to adapt my backend architecture to safely deploy AI features.

The Problem: The Unprotected Wrapper
The standard tutorial implementation is essentially an unprotected wrapper. Your frontend talks to your Next.js/Node.js backend, and your backend blindly forwards the request to the LLM.

// ❌ The Tutorial Way (Dangerous in Production)
export async function POST(req) {
  const { prompt } = await req.json();

  // Blindly forwarding the request and paying for it
  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [{ role: "user", content: prompt }],
  });

  return Response.json(response.choices[0].message);
}

The Solution: Building a Defense Layer
To move this to production, I had to stop treating the AI API like a standard database query and start treating it like a precious resource. Here are the three pillars of production AI architecture I implemented.

1. Strict Rate Limiting
Before a request even touches the logic of my application, it has to pass a rate limiter. Using a tool like Redis (or Upstash), you can track how many requests a specific IP address or User ID has made in a given window.

If a user tries to generate 10 responses in 10 seconds, the server throws a 429 Too Many Requests error and refuses to talk to the AI. This instantly stops bots and button-mashers.

2. Token Tracking and Quotas
Rate limiting protects against bursts, but what about a user who slowly drains your API credits over a month?

To solve this, I had to update my database schema to include a tokens_used column for every user. Every time a successful AI request completes, the API returns a usage object. I extract the total_tokens from that object and add it to the user's profile in my database.

If their usage exceeds their tier (e.g., free tier vs. premium), they are locked out until they upgrade or the month resets.

3. Caching (Don't Pay for the Same Answer Twice)
This was the biggest "Aha!" moment. Why should I pay the AI to answer "How do I reverse a string in Python?" if another user asked the exact same question yesterday?

By implementing a caching layer (saving the Prompt and the AI's Response to my own database), I can check the database first. If the answer exists, I serve it instantly for free. If it doesn't, only then do I query the AI.

Your 5-line tutorial endpoint suddenly turns into this:

// ✅ The Production Way (Pseudocode)
export async function POST(req) {
  const user = await authenticateUser(req);
  const { prompt } = await req.json();

  // 1. Rate Limiting Check
  if (await isRateLimited(user.id)) return Error("Too many requests");

  // 2. Quota Check
  if (user.tokens_used > MAX_LIMIT) return Error("Upgrade your plan");

  // 3. Cache Check
  const cachedResponse = await checkDatabaseCache(prompt);
  if (cachedResponse) return Response.json(cachedResponse);

  // 4. The actual AI call
  const response = await openai.chat.completions.create({...});

  // 5. Save usage and cache the response
  await saveToCache(prompt, response);
  await updateUserTokens(user.id, response.usage.total_tokens);

  return Response.json(response);
}

The Takeaway
Integrating an AI API is the easiest part of building an AI application. The real engineering challenge lies in building the infrastructure around it—protecting your endpoints, managing costs, and optimizing performance.

Are you building an AI-powered app? What strategies are you using to manage API costs and prevent abuse? Let me know in the comments!

The Hidden Trap in Backend Tutorials: Why Your Webhooks Are Creating Duplicate Data (And How to Fix It)

Anubhav Gupta — Sat, 20 Jun 2026 05:19:25 +0000

We've all been there. You're sitting at your desk late at night, watching a backend tutorial, fueled by coffee and determination. The instructor shows you how to integrate a payment gateway or a webhook, and it looks incredibly simple:

Receive the webhook event.
Update the database.
Return a 200 OK.

You write the code, test it locally, and it works perfectly. You push it to production feeling like a senior engineer.

But a few days later, you check your database and notice something terrifying: Duplicate records. Users are being credited twice, or identical data entries are piling up.

Welcome to the real world of backend engineering, where the "Happy Path" is a myth, and network reliability is a lie.

Here is what went wrong, and the crucial concept of Idempotency that tutorials often skip.

The Problem : The Unreliable Network
In a perfect world, when an external service (like Stripe, GitHub, or Razorpay) sends a webhook to your server, your server processes it instantly and fires back a 200 OK to say, "Got it, thanks!"

But networks are inherently flaky. Sometimes, your server takes too long to process the data. Other times, a DNS hiccup drops your 200 OK response before it reaches the external service.

When the external service doesn't get your confirmation in time, it assumes the event was lost. So, what does it do? It retries. It fires the exact same webhook event again a few seconds (or minutes) later.

If your code blindly accepts data and inserts it into the database, you've just processed the same event twice.

The "Aha!" Moment: Enter Idempotency
To fix this, we need to design our API to be Idempotent.

Idempotency is a fancy mathematical term that simply means: Making multiple identical requests has the same effect as making a single request.

Think of it like an elevator button. Pressing the "Floor 5" button once tells the elevator to go to floor 5. Smashing the "Floor 5" button ten times in a row doesn't make the elevator go to floor 50. The end result is exactly the same.

Your webhook endpoint needs to act like that elevator button.

How to Implement an Idempotent Webhook
To stop duplicate data, you need to turn your server into a bouncer. Before letting any data in, it needs to check the guest list.

Here is the step-by-step logic to fix the issue:

1. Find the Unique Identifier
Every well-designed webhook payload contains a unique ID for that specific event (e.g., event_id or stripe_signature). This is your golden ticket.

2. Check the Database Before Processing
When the webhook hits your server, do not process the business logic immediately. First, query your database to see if you have already processed this event_id.

3. Handle the Duplicate Gracefully
If the event_id exists, it means this is a network retry. Your server should safely ignore the payload and immediately return a 200 OK to satisfy the external service.

If the event_id does not exist, process the data, save the event_id to your database, and return the 200 OK.

The Code Example (Node.js / Express)
Here is what that mental shift looks like in code:

app.post('/webhook', async (req, res) => {
  const eventId = req.body.event_id;
  const payloadData = req.body.data;

  try {
    // 1. Check if we've already processed this event
    const existingEvent = await db.processedEvents.findUnique({
      where: { id: eventId }
    });

    // 2. If it exists, it's a retry! Ignore it, but send a 200 OK.
    if (existingEvent) {
      console.log(`Duplicate event ${eventId} blocked.`);
      return res.status(200).send('Event already processed');
    }

    // 3. If it's new, process the business logic safely
    await updateUserData(payloadData);

    // 4. Save the event_id so we remember it for the future
    await db.processedEvents.create({
      data: { id: eventId }
    });

    // 5. Finally, send the success response
    return res.status(200).send('Webhook received and processed');

  } catch (error) {
    console.error("Webhook processing failed", error);
    return res.status(500).send('Internal Server Error');
  }
});

The Takeaway
Tutorials are amazing for learning the syntax and the basic flow of a framework. But the transition from a "learner" to a "builder" happens the moment you start dealing with real-world edge cases.

Building systems that work when everything goes perfectly is easy. Engineering systems that gracefully handle failure, retries, and latency is the real challenge and the real fun.

Have you ever had a network retry cause havoc in your database? How do you handle idempotency in your own APIs? Let me know in the comments below!