DEV Community: Agrima Gupta

RAG vs Fine-Tuning: Which One Should You Use for Your AI App?

Agrima Gupta — Mon, 19 Oct 2026 07:10:33 +0000

RAG vs Fine-Tuning Explained: The Difference Every AI Developer Should Know
Imagine you're building an AI assistant for a company.

It needs to answer questions about internal documents, follow a specific response format, and communicate in the company's tone.

You have two options: RAG and fine-tuning.

Both can help you customize an AI application, but they work in very different ways. Choosing the wrong one can add unnecessary complexity, cost, and development time.

Let's understand the difference with a practical example.

First, What Is RAG?

RAG stands for Retrieval-Augmented Generation.

Instead of expecting an LLM to already know all the information it needs, RAG retrieves relevant information from external sources and provides it to the model when answering a question.

Imagine you're building a customer support chatbot for an online store. The store's refund policy changes regularly, and customers ask questions about returns, delivery, and replacements.

With RAG, the chatbot can retrieve the latest relevant policy before generating an answer.

Customer asks a question
          ↓
Search company documents
          ↓
Retrieve relevant information
          ↓
Send context + question to LLM
          ↓
Generate an answer

You can update the documents without retraining the LLM. That's one of RAG's biggest advantages.

What Is Fine-Tuning?

Fine-tuning takes a pretrained model and trains it further on carefully prepared examples so its behavior adapts to a particular task.

For example, suppose your AI assistant needs to convert customer messages into structured support tickets.

You want it to consistently identify the issue, assign a category, and summarize the request in a particular style.

Fine-tuning may help the model learn that pattern from examples.

Pretrained LLM
      ↓
Training Examples
      ↓
Fine-Tuning
      ↓
Adapted Model
      ↓
Generate Responses

Unlike RAG, fine-tuning changes the model's learned parameters. It doesn't automatically give the model access to your latest company documents or guarantee that it will memorize every fact in your training data.

The Biggest Difference: Knowledge vs Behavior

Let's return to our customer support chatbot.

A customer asks, “What is your current refund policy?”

This information can change over time. RAG is a natural choice because the system can retrieve the latest policy from an approved source.

Now imagine the customer asks a question that requires the assistant to produce a ticket in a consistent format:

{
  "category": "refund",
  "priority": "medium",
  "summary": "Customer requests a refund"
}

Fine-tuning may help the model learn this output pattern when prompt instructions alone aren't giving reliable enough results.

Here's a simple way to think about it:

Requirement	Approach to consider
Answer using changing documents	RAG
Reference private company information	RAG
Follow a specialized response style	Fine-tuning may help
Perform a consistent task using examples	Fine-tuning may help
Improve access to current facts	RAG
Improve both information access and task behavior	Combine them if needed

These aren't strict rules. Prompt engineering, structured outputs, and other techniques may solve some problems without fine-tuning.

How Does RAG Work in Code?

Here's a simplified Python example. Imagine retrieve_documents() searches your document collection and returns relevant text chunks.

def answer_question(question):
    context = retrieve_documents(question)

    prompt = f"""
    Answer using the context below.
    If the answer isn't available, say so.

    Context:
    {context}

    Question:
    {question}
    """

    return llm.generate(prompt)

The function retrieve_documents() and the method llm.generate() are placeholders; you'll need to implement them using your chosen retrieval system and model provider.

The important idea is that the relevant information is supplied at answer time. When the refund policy changes, you update the document collection rather than retraining the model.

How Does Fine-Tuning Look in Code?

Fine-tuning depends on the model and training framework. Here's a simplified example using the Hugging Face Transformers ecosystem:

from transformers import (
    AutoTokenizer,
    AutoModelForCausalLM,
    Trainer,
    TrainingArguments
)

model_name = "your-base-model"

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

training_args = TrainingArguments(
    output_dir="./fine-tuned-model",
    num_train_epochs=3,
    per_device_train_batch_size=2
)

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=your_tokenized_dataset
)

trainer.train()

This illustrates the training setup, not a complete, ready-to-run fine-tuning pipeline. You still need a compatible model, a properly tokenized dataset, and any required configuration such as a padding token or data collator.

The idea is that the model learns from examples during training, and you can later use the resulting model for inference.

Can You Use RAG and Fine-Tuning Together?

Absolutely.

Imagine your company assistant needs to answer questions using current product documentation while consistently following a specific support workflow.

You could use RAG to supply relevant product information and a fine-tuned model to improve the response behavior.

User Question
      ↓
RAG retrieves relevant information
      ↓
Context + Question
      ↓
Fine-Tuned LLM
      ↓
Final Answer

This combination can be useful, but it adds complexity. It's better to start with the simplest approach that meets your requirements and combine techniques only when testing shows a real need.

What About Cost and Maintenance?

RAG requires a retrieval pipeline, document processing, and a way to store and search information. You also need to evaluate whether the retrieved context is relevant.

Fine-tuning requires suitable training examples, training resources or a supported fine-tuning service, and evaluation to make sure the model improves without losing important capabilities.

RAG can make updating factual information easier, while fine-tuning can require another training run when you want to change the model's learned behavior. Actual costs depend on model choice, usage, infrastructure, and implementation.

Neither approach is automatically cheaper or more accurate in every situation.

How Do You Choose?

Start by identifying the problem you're actually trying to solve.

If the model needs access to information that changes frequently, try RAG first. If it consistently struggles with a specialized task or response pattern despite good instructions and examples, evaluate fine-tuning.

If it needs both current external information and specialized behavior, consider combining them after measuring the results.

Most importantly, test your approach against realistic questions. Check answer correctness, retrieval quality, response consistency, latency, and cost instead of choosing based on hype.

Final Thoughts

RAG and fine-tuning aren't competing solutions to exactly the same problem.

RAG gives an LLM relevant information at the time it answers. Fine-tuning changes the model's learned behavior through additional training.

Remember the distinction:

Need better access to information? Consider RAG.

Need to adapt how a model performs a task? Consider fine-tuning.

And if your AI application needs both, you can combine them — as long as the added complexity is worth it.

The best choice isn't the most advanced technique. It's the one that solves your actual problem reliably.

How Do LLMs Predict the Next Word? Understanding Token Prediction

Agrima Gupta — Mon, 19 Oct 2026 07:06:01 +0000

Ever wondered how ChatGPT can finish your sentences, explain complicated topics, or write an entire story from a single prompt?

It might seem like the AI understands your question and then magically produces an answer.

But one of the fundamental ideas behind large language models (LLMs) is surprisingly simple:

They predict what token is likely to come next.

Let's understand what that actually means, how the process works, and how a simple prediction turns into an entire response.

First, What Is a Token?

We often say that an LLM predicts the next word, but that's not entirely accurate.

Most LLMs work with tokens. A token can be a whole word, part of a word, punctuation, or another piece of text.

For example, the sentence:

Machine learning is fascinating!

might be split into tokens resembling:

["Machine", " learning", " is", " fascinating", "!"]

The exact tokenization depends on the model's tokenizer.

Why not just use complete words? Because tokenization lets models handle common words, unfamiliar words, punctuation, and different languages using a manageable vocabulary.

So when we say an LLM predicts the next word, we're usually talking about predicting the next token.

How Does an LLM Predict the Next Token?

Imagine you start typing:

The sun rises in the ...

What could come next?

Maybe east, morning, or something else.

The model processes the text you've provided and estimates the probabilities of possible next tokens based on patterns learned during training.

For a simplified example, it might produce:

Possible next token	Example probability
east	75%
morning	15%
sky	7%
other tokens	3%

These numbers are illustrative, not actual model outputs.

The model can then select a token based on its generation strategy. If it selects east, the text becomes:

The sun rises in the east

But it doesn't stop there. It predicts the next token using the updated text, then repeats the process.

From One Token to an Entire Answer

Here's the important part: the model generates text one token at a time, repeatedly using the context available to it.

Your Prompt
    ↓
Process Existing Tokens
    ↓
Calculate Next-Token Probabilities
    ↓
Select a Token
    ↓
Add It to the Text
    ↓
Predict Again
    ↓
Continue Until Generation Stops

Suppose you ask:

“Explain machine learning in simple terms.”

The model generates a token, then another, and then another. Each new token becomes part of the context used for subsequent predictions.

This is how a single prompt can turn into paragraphs of coherent text.

But Where Do These Predictions Come From?

An LLM doesn't begin with a built-in list of every possible answer.

During training, it processes enormous amounts of text and learns statistical patterns in how tokens relate to their context.

For example, it may learn that certain words commonly appear together, how sentences are structured, how explanations are written, and how questions are often answered.

Modern LLMs typically use the Transformer architecture, which helps them process relationships between tokens through mechanisms such as self-attention.

During training, the model adjusts its internal parameters to improve its predictions. Over time, it learns complex patterns that help it generate useful text.

This is more sophisticated than simply looking up the most common next word. The predictions depend on the surrounding context and the patterns encoded in the model's parameters.

Let's Build a Tiny Next-Word Predictor in Python

We don't need a neural network to understand the basic idea. Let's create a tiny example using word frequencies.

from collections import defaultdict, Counter

sentences = [
    "machine learning is useful",
    "machine learning is powerful",
    "machine learning is fascinating",
    "deep learning is powerful"
]

next_words = defaultdict(Counter)

for sentence in sentences:
    words = sentence.split()

    for i in range(len(words) - 1):
        next_words[words[i]][words[i + 1]] += 1

context = "machine learning is"
last_word = context.split()[-1]

print(next_words[last_word].most_common())

Output:

[('useful', 1), ('powerful', 1), ('fascinating', 1)]

Our tiny program counts which words follow is in the training sentences.

Because all three candidates appear once after is in this small dataset, they have equal counts.

This is not how a modern LLM works internally. It simply demonstrates the core idea of using previously observed patterns to estimate what might come next. Real LLMs use learned neural network parameters to produce contextual probability distributions over their token vocabulary.

Why Doesn't ChatGPT Give the Same Answer Every Time?

If the model estimates probabilities for possible next tokens, why doesn't it always choose the most likely one?

Because text generation can use different sampling strategies.

With greedy decoding, the model selects the highest-scoring token at each step. With sampling, it can choose among candidate tokens according to their probabilities.

One setting you might encounter is temperature, which changes how concentrated or spread out the token probabilities are during sampling. Lower temperatures generally make choices more predictable, while higher temperatures generally allow more variation.

For example, when answering a factual question, you might prefer a more predictable response. When writing a creative story, you might want more variety.

Temperature doesn't add knowledge to the model; it changes how token choices are made.

If It's Predicting Tokens, Does That Mean It Doesn't Understand Anything?

This is where things get interesting.

Next-token prediction describes a fundamental part of how many LLMs are trained and generate text. But learning to predict tokens across diverse contexts can require the model to represent grammar, concepts, relationships, and aspects of the world in its internal parameters.

At the same time, fluent text isn't proof that every statement is true or that the model understands things exactly as a human does.

An LLM can produce a convincing answer and still make a factual mistake. Its output depends on its training, context, model design, and generation process.

The Big Picture

An LLM doesn't write an entire answer in one magical step. It repeatedly processes context, estimates probabilities for the next token, selects a token, and continues generating.

Remember the basic loop:

Context → Predict → Select → Add → Repeat.

That simple-sounding process, powered by enormous neural networks trained on large amounts of data, is one of the foundations behind modern conversational AI.

And the next time ChatGPT gives you a surprisingly detailed answer, you'll know the basic mechanism behind how those words appear — one token at a time.

What Actually Happens When You Tap Your Phone to Pay?

Agrima Gupta — Mon, 19 Oct 2026 06:52:03 +0000

You've probably done this hundreds of times.

You walk into a store, pick up something, open your payment app or wallet, tap your phone against the payment terminal, and within seconds, you hear that familiar beep.

Payment successful.

But how did a small tap communicate with a payment terminal, verify your payment, contact the bank, and complete the transaction in seconds?

There's no magic involved. A combination of wireless communication, secure payment technology, and banking infrastructure makes it possible.

Let's break down what actually happens.

Step 1: Your Phone Communicates Using NFC

The first technology involved is NFC (Near Field Communication).

NFC allows two compatible devices to exchange small amounts of data when they're very close to each other, usually within a few centimeters.

It's the technology behind many contactless card payments, phone wallets, and other tap-based interactions.

When you tap your phone against a compatible payment terminal, the devices establish a short-range communication link and exchange the information required by the payment protocol.

Think of NFC as the messenger. It helps the devices communicate, but it doesn't independently approve your payment.

Your Phone
    ↓
  NFC Signal
    ↓
Payment Terminal

Your phone doesn't need to connect to the terminal through Wi-Fi or Bluetooth for this tap-based communication to happen.

Step 2: Your Phone Uses Secure Payment Credentials

Here's where things get more interesting.

You might assume your phone simply sends your actual card number to the terminal. Modern mobile payment systems often use a more secure approach.

Wallets such as Apple Pay and Google Wallet can use tokenization, where a payment token substitutes for the actual card number in supported transactions.

The wallet may also use a transaction-specific cryptogram: a piece of cryptographic data that helps the payment system verify that the transaction is legitimate.

The exact process depends on the wallet, device, payment network, and transaction type.

Here's a simplified example:

Your Actual Card Details
          ↓
Secure Wallet Setup
          ↓
Payment Token Stored
          ↓
Transaction-Specific Data
          ↓
Payment Terminal

This means that even if a payment uses a token instead of your actual card number, the payment system can still associate the transaction with the appropriate underlying payment account.

Your phone isn't simply broadcasting your full card details to every nearby device.

Step 3: The Payment Terminal Sends a Request

Once the terminal receives the required payment data, it creates a transaction request.

For example, imagine you're buying headphones worth ₹2,000.

The terminal combines the transaction amount with the payment information and sends the request into the payment processing system.

A simplified version looks like this:

Amount: ₹2,000
Payment Credential: Token
Transaction Data: Security Information
              ↓
      Payment Request

The terminal typically communicates with a payment processor or acquiring bank, which routes the transaction through the appropriate payment network.

The request eventually reaches the card issuer — the bank or financial institution responsible for the payment account.

Step 4: Your Bank Decides Whether to Approve It

Now the bank needs to decide whether the transaction should be authorized.

It may evaluate factors such as available funds or credit, account status, transaction details, security checks, and fraud signals.

The exact checks depend on the payment method and the issuer's systems.

Imagine the bank receives this request:

Transaction Amount: ₹2,000
Account Status: Active
Security Checks: Passed
Available Funds: Sufficient

These are illustrative fields, not a literal bank message.

If the transaction passes the relevant checks, the bank can approve the authorization. Otherwise, it may decline the request.

The response travels back through the payment processing system to the terminal.

Payment Terminal
       ↓
Acquiring Bank / Processor
       ↓
  Payment Network
       ↓
   Card-Issuing Bank
       ↓
  Approve or Decline
       ↓
Payment Terminal

That familiar beep or on-screen confirmation appears after the terminal receives the result.

Step 5: Is the Money Transferred Instantly?

Not necessarily.

This is an important distinction: payment authorization and settlement are different things.

Authorization means the transaction has been approved. Depending on the payment method, it may reserve funds or establish that the transaction can proceed.

Settlement is the process through which the financial institutions reconcile the transaction and move the corresponding funds.

The customer sees a successful payment almost immediately, but the underlying settlement process may happen later.

So, when your terminal displays "Payment Successful," it doesn't necessarily mean every part of the financial transaction has already been settled.

Let's Understand the Whole Process With a Flowchart

Here's the complete journey, simplified:

       Tap Your Phone
              ↓
       NFC Communication
              ↓
   Exchange Payment Information
              ↓
      Terminal Creates Request
              ↓
    Processor / Payment Network
              ↓
       Issuing Bank Checks
              ↓
       ┌──────┴──────┐
       ↓             ↓
    Approved      Declined
       ↓             ↓
  Confirmation   Failure Message

The actual architecture varies by wallet and payment network, but this captures the basic idea behind a typical contactless card transaction.

Can We Simulate This in Code?

Let's create a tiny Python example to understand how a payment terminal might handle an approval response.

This is only a simulation. It doesn't use NFC, contact a real bank, or process an actual payment.

def process_payment(amount, approved):
    print(f"Payment amount: ₹{amount}")

    if approved:
        print("Payment successful!")
    else:
        print("Payment declined.")

process_payment(2000, True)

Output:

Payment amount: ₹2000
Payment successful!

In a real payment system, the terminal wouldn't simply trust a Boolean value like approved. It would communicate with authorized payment infrastructure, receive a response, and follow the relevant security and transaction protocols.

The example only demonstrates the final decision in a much larger process.

What Happens If Your Phone Has No Internet?

This depends on the payment method and its configuration.

NFC communication itself doesn't require your phone to have an internet connection. However, the overall payment may still need network connectivity to reach the payment processing infrastructure.

Some payment systems support limited offline transactions under specific conditions, but offline acceptance isn't universally available and may involve additional limits and risks.

So, don't assume that every tap-to-pay transaction will work when your phone is disconnected.

Is Tapping Your Phone Safer Than Swiping a Card?

Mobile wallets can provide additional security through tokenization, device-level protections, and transaction authentication.

For example, a wallet may require a fingerprint, face authentication, or a device passcode before allowing a payment. The precise requirements depend on the device, wallet, transaction amount, and settings.

However, security isn't determined by one feature alone. The payment network, bank, device security, and how the user protects their account all matter.

Contactless payments are designed with security controls, but no payment method is completely immune to fraud.

The Bigger Picture

The next time you tap your phone at a store, remember that several technologies are working together behind that tiny interaction.

NFC establishes the nearby communication. Secure payment credentials help protect sensitive account information. The terminal sends a transaction request through the payment infrastructure, and the issuing bank decides whether to authorize it.

All of this happens quickly enough that the experience feels almost instantaneous.

One tap. Multiple systems. A whole lot of engineering.

How Can One Fake Email Compromise an Entire Company?

Agrima Gupta — Tue, 13 Oct 2026 05:00:37 +0000

Imagine you're working at a company and receive an email from the IT department.

It says your work account needs an urgent security update. There's a link to verify your credentials, and the email looks completely legitimate. It has the company logo, professional language, and even a convincing sender name.

You click the link, enter your email and password, and get back to work.

Nothing unusual happens.

But somewhere in the background, an attacker may now have access to your account.

This is how a phishing attack can begin. And in the wrong circumstances, one compromised account can become a much bigger security incident.

What Is Phishing, Really?

Phishing is a type of cyberattack in which someone impersonates a trusted person or organization to trick people into revealing sensitive information, clicking malicious links, or performing actions that compromise security.

The important part is that phishing doesn't necessarily rely on sophisticated hacking.

Sometimes, the attacker simply convinces someone to trust the wrong message.

And that makes it particularly dangerous in workplaces, where employees receive dozens of emails every day and often have to act quickly.

Let's Follow One Email

Imagine a fictional company called NovaTech.

An employee receives this message:

Subject: Urgent — Your Work Account Requires Verification

Hi,

As part of a scheduled security update, please verify your work account to avoid temporary access restrictions.

Complete the verification using the link below.

— IT Support Team

The email looks routine. The employee is busy, the request sounds reasonable, and the deadline creates a sense of urgency.

They open the link and land on a page that resembles the company's login portal.

They enter their credentials.

The page might display an error or redirect them somewhere else. The employee assumes it was a technical issue and moves on.

But if the page was designed to steal credentials, the attacker may now have the employee's username and password.

How Does One Click Become a Bigger Problem?

Getting someone's password is only the beginning. What happens next depends on the account's permissions, the company's security controls, and whether the attacker can bypass additional protections.

Here's a simplified view of how the incident could develop.

Fake Email
    ↓
Employee Clicks Link
    ↓
Credentials Are Stolen
    ↓
Attacker Attempts Account Access
    ↓
Unauthorized Access
    ↓
Sensitive Data May Be Exposed

Notice that every step isn't guaranteed to happen. A well-secured company might detect the login attempt, block it, or require additional verification.

But if the compromised account has access to internal documents, shared drives, customer records, or other business systems, the potential impact can extend beyond one employee.

Why Would an Attacker Target an Employee?

You might wonder why someone would target an ordinary employee instead of directly attacking the company's servers.

Because an employee's account can already have legitimate access to valuable systems.

For example, an employee might have access to internal project documents, customer information, shared folders, or business communication tools.

An attacker who compromises that account may be able to misuse those existing permissions.

This is why cybersecurity isn't just about protecting servers. It's also about protecting identities and controlling what each account can access.

How Does the Attack Become a Company-Wide Incident?

Let's say the compromised account belongs to someone who can access internal documents and communicate with other employees.

Depending on the situation, an attacker might misuse that access to collect sensitive files, impersonate the employee, or send convincing messages to colleagues.

Those messages may be more believable because they come from a real, trusted account.

If another employee trusts the message, the attack could spread further.

Compromised Employee Account
             ↓
   Access to Internal Systems
             ↓
  Sensitive Data or Communications
             ↓
 Potential Wider Security Incident

In more serious cases, attackers may discover additional weaknesses or gain access to more privileged accounts. However, a single phishing email doesn't automatically give someone control of an entire company.

The extent of the damage depends on the access obtained and how quickly the incident is detected and contained.

Why Are Phishing Emails So Convincing Today?

Phishing messages aren't always filled with spelling mistakes or suspicious formatting.

Attackers can imitate company branding, copy the tone of real business communications, and create convincing login pages. Some messages also use information about a person's role or workplace to make the request seem more believable.

A message can look professional and still be fraudulent.

That's why checking grammar or looking for a suspicious design isn't enough.

Pay attention to the actual sender address, the destination of links, unexpected requests for credentials, and unusual urgency. When a message asks you to perform a sensitive action, verify it through a separate, trusted channel.

How Can Companies Prevent This?

The answer isn't simply to tell employees to be more careful. People can make mistakes, especially when they're busy or under pressure.

Companies need multiple layers of protection.

Multi-factor authentication (MFA) makes account access harder for attackers who have stolen a password. Phishing-resistant methods, such as passkeys or hardware security keys, provide stronger protection against fake login pages than codes that can be captured or relayed.

Least-privilege access ensures employees and applications only have the permissions they need. If an ordinary account is compromised, limited permissions can reduce the potential damage.

Email security controls can help detect spoofed senders, suspicious links, and malicious attachments before they reach an inbox.

Employee awareness and reporting also matter. Employees should know how to recognize suspicious requests and report them without fear of blame.

Finally, monitoring and incident response help security teams detect unusual activity, disable compromised sessions, reset affected credentials, and investigate what was accessed.

No single measure is perfect. The goal is to prevent one mistake from turning into a major incident.

What Should You Do If You Clicked a Suspicious Link?

First, don't panic. Clicking a link doesn't automatically mean your account has been compromised.

If you entered your credentials, report it to your IT or security team immediately. Use a trusted device and official route to change the affected password, and follow your organization's instructions for revoking sessions or securing the account.

If you downloaded or opened a suspicious file, report that too. Don't try to investigate or delete evidence on your own if your organization's security team needs to examine the device.

Quick reporting gives the company a better chance of containing the incident before it spreads.

The Bigger Picture

A phishing attack is often described as a technical problem, but it usually involves technology, human behavior, and access controls working together.

An email alone doesn't compromise an entire company. The risk grows when stolen credentials provide access to important systems, permissions are too broad, and suspicious activity goes undetected.

That's why good cybersecurity doesn't depend on expecting every employee to spot every fake email.

It depends on building systems that can withstand mistakes, limit damage, and respond quickly when something goes wrong.

Because sometimes, the most important security boundary isn't a firewall.

It's the moment someone decides whether to trust an email.

From Localhost to the Cloud: Understanding AWS for Beginners

Agrima Gupta — Mon, 12 Oct 2026 12:59:42 +0000

If you've ever built a website, you've probably run it on localhost:3000 or localhost:8000.

Everything works perfectly on your laptop. Your frontend connects to your backend, your API returns data, and your application runs just fine.

But there's one problem.

What happens when someone else wants to use your application?

They can't access your localhost because it points to their own computer, not yours.

So, how do you take an application from your laptop and make it accessible to the entire world?

That's where cloud computing comes in. And one of the most popular platforms for it is AWS (Amazon Web Services).

Let's understand how it works.

What Actually Is the Cloud?

Forget the technical definition for a moment.

Imagine you want to run a backend application 24/7. You could buy a physical server, keep it running, maintain its hardware, manage its network connection, and handle failures yourself.

Sounds expensive, right?

Instead, you can rent computing resources from a cloud provider and access them over the internet.

That's the basic idea behind cloud computing.

The cloud is essentially someone else's infrastructure that you can use to run your applications, store your data, and build services without owning all the physical hardware yourself.

And AWS is one of the platforms that provides these services.

So, What Is AWS?

AWS stands for Amazon Web Services. It offers cloud services for running applications, storing files, managing databases, networking, security, and much more.

Think of it this way:

Your Laptop
    ↓
Write and test your code locally
    ↓
Deploy your application
    ↓
AWS provides the infrastructure
    ↓
Users access your application online

AWS isn't a single server or tool. It's a collection of services that work together to help you build and run applications.

Let's Understand This With an Example

Suppose you've built a simple Notes application.

Your frontend is written in React, your backend uses FastAPI, and your database stores users and notes.

On your laptop, everything might look like this:

React Frontend
      ↓
FastAPI Backend
      ↓
PostgreSQL Database

All three components run locally.

But now you want your friends to open the application from their own devices.

You need to deploy the application somewhere accessible over the internet.

AWS gives you different services to help with that.

The AWS Services You'll Actually Need to Know

You don't need to learn hundreds of AWS services as a beginner. Start by understanding what a few important ones do.

Amazon EC2 — A Computer in the Cloud

EC2 stands for Elastic Compute Cloud.

Remember how your backend runs on your laptop? EC2 lets you launch a virtual server in the cloud and run your backend on it.

You can choose its operating system, configure its resources, and install the software your application needs.

Think of it as renting a computer that can stay online and serve your application.

Amazon S3 — Storing Your Files

Suppose users can upload profile pictures, PDFs, or other documents.

Instead of keeping those files on your backend server, you can store them in Amazon S3, a service designed for storing objects such as files and media.

Your backend can then manage access to those files according to your application's requirements.

Amazon RDS — Your Database in the Cloud

Your application needs to save information such as user accounts, notes, and transactions.

Amazon RDS provides managed relational databases, including PostgreSQL and MySQL.

Instead of managing every aspect of the database infrastructure yourself, AWS handles many routine administrative tasks.

AWS IAM — Who Can Access What?

Imagine your backend needs access to files in S3.

You don't want to give it unlimited access to your entire AWS account.

IAM (Identity and Access Management) helps you control which users and applications can access which resources.

It's an essential part of building applications securely in the cloud.

How Do These Services Work Together?

Let's return to our Notes application.

A simplified setup could look like this:

         User's Browser
                ↓
          React Frontend
                ↓
        FastAPI on EC2
           ↙        ↘
     Amazon RDS    Amazon S3
     (Notes data)  (Uploaded files)

The frontend sends requests to the backend. The backend processes those requests, retrieves information from the database when needed, and returns a response.

If a user uploads a PDF, the application can store it in S3.

Each service has a different responsibility, but together they help run one application.

What About Deployment?

Deploying means making your application available in an environment where other people can use it.

When deploying to AWS, you typically configure your application, choose the appropriate services, set up networking and permissions, and make the necessary endpoints accessible.

For example:

Local Development
        ↓
Test Your Application
        ↓
Configure AWS Resources
        ↓
Deploy Frontend + Backend
        ↓
Connect Database and Storage
        ↓
Users Access Your App Online

The exact process depends on your tech stack and the AWS services you choose. EC2 is one option for hosting a backend, but AWS also offers services that reduce how much server management you need to do.

Does AWS Cost Money?

This is something beginners should understand before deploying anything.

AWS has different pricing models depending on the service. Some resources are charged according to usage, while others have different billing structures.

Some services offer free usage allowances for eligible accounts, but not everything is free.

Before experimenting, check the current pricing, configure billing alerts, and delete resources you no longer need. Simply stopping development doesn't always mean every resource has stopped generating charges.

How Should You Start Learning AWS?

Don't try to memorize every service name. Start with a project you already understand.

Build a small application locally, then learn how to deploy it. Understand EC2, S3, IAM, and basic networking before moving on to more advanced services.

Once you're comfortable, explore managed databases, serverless computing with AWS Lambda, and content delivery with CloudFront.

You'll understand cloud computing much faster when you can connect each service to a real problem you've faced while building software.

Final Thoughts

Moving from localhost to the cloud is an important step in becoming a developer who can build and deploy real applications.

AWS makes that journey possible by providing the infrastructure and tools you need without requiring you to own physical servers.

You don't have to learn everything at once. Start small, deploy something simple, understand how its components communicate, and build from there.

Because writing code is one thing.

Making it available to the world is where the real fun begins. ☁️

How Can AI Answer Questions About Your PDFs? Meet RAG

Agrima Gupta — Fri, 09 Oct 2026 11:44:33 +0000

Have you ever wanted to upload your college notes and simply ask an AI, “Explain Unit 3” or “What is the difference between these two concepts?”

Instead of searching through 50 pages yourself, the AI finds the relevant information and explains it to you.

But how does it know which part of your notes to look at?

One of the techniques that makes this possible is RAG (Retrieval-Augmented Generation).

Let's understand it with a simple example.

Imagine You're Preparing for an Exam

Suppose you have a PDF containing 100 pages of DBMS notes. You ask an AI:

“Explain primary keys with an example.”

The AI shouldn't need to read all 100 pages every time you ask a question. It should find the relevant section, understand the context, and explain it to you.

That's exactly what RAG helps it do.

Think of RAG as an open-book exam. You find the relevant page first, read it, and then answer the question.

So, How Does RAG Work?

The process has two main parts: finding the right information and using it to generate an answer.

Here's the complete flow:

Your PDF or Documents
        ↓
Break them into smaller pieces
        ↓
Make those pieces searchable by meaning
        ↓
Find the relevant pieces when asked
        ↓
Give them to the AI
        ↓
Generate the answer

Let's understand each step.

Step 1: Break Documents Into Smaller Pieces

Imagine your 100-page PDF is one huge book.

Searching through the entire book for every question would be inefficient. So, we divide the text into smaller sections called chunks.

For example:

DBMS Notes
    ↓
Chunk 1: Introduction to DBMS
Chunk 2: Primary and Foreign Keys
Chunk 3: SQL Joins
Chunk 4: Normalization

Now, if you ask about primary keys, the system can look for the section about keys instead of processing the whole document.

Step 2: Help the Computer Understand Meaning

Here's where things get interesting.

Suppose you ask:

“How do I get my money back?”

But your document contains the words “Refund Policy.”

A simple keyword search might miss the connection because the wording is different.

To help with this, RAG systems often use something called embeddings.

An embedding converts text into a list of numbers that represents its meaning. Text with similar meanings can have similar numerical representations.

Think of it like this:

"How do I get my money back?"
             ↓
          Embedding
             ↕
       Similar meaning
             ↕
       "Refund Policy"

This helps the system find relevant information even when the exact words don't match.

Step 3: Store the Information So It Can Be Found Later

Once the document chunks have been converted into embeddings, we store them in a system that can search these vectors. This is where a vector database comes in.

Tools like Chroma, Pinecone, and Weaviate can help with this.

Think of a vector database as a smart library. Instead of searching only by a book's title, it helps you find the sections that are closest in meaning to your question.

When you ask a question, the system converts it into an embedding and searches for the most relevant chunks.

Your Question
      ↓
Convert to Embedding
      ↓
Search Vector Database
      ↓
Find Relevant Text

Step 4: Give the Relevant Information to the AI

Now the system has found the right section of your notes.

It sends that information to the language model along with your question.

For example:

Relevant information:
A primary key uniquely identifies
each record in a table.

Your question:
What is a primary key?

AI instruction:
Explain using the information provided.

The AI uses this context to create a clear answer.

Notice something important: the AI isn't searching through your PDF by itself at this stage. The RAG system retrieves the relevant information and provides it to the AI.

Step 5: Generate the Answer

Finally, the AI responds:

“A primary key is a column that uniquely identifies each record in a database table. For example, a student ID can be a primary key because every student has a unique ID.”

And there you have it!

You asked a question, the system found the relevant information in your document, and the AI turned it into an understandable answer.

Where Is RAG Used?

Once you understand the idea, you'll start noticing how useful it is.

RAG can power PDF chatbots, AI study assistants, customer support bots, company knowledge assistants, and tools that answer questions from technical documentation.

For example, you could build an AI study assistant where students upload their notes and ask questions without manually searching every page.

Does RAG Always Give Correct Answers?

Not necessarily.

Imagine asking about SQL joins, but the system retrieves a section about normalization instead.

The AI might produce an answer that sounds convincing but doesn't answer your question correctly.

RAG improves the chances of getting a relevant answer by providing useful context, but it doesn't eliminate mistakes or hallucinations completely.

That's why retrieving the right information is just as important as generating the answer.

The Big Picture

You don't need to train a new AI model to build a chatbot that answers questions about your documents.

You can connect an existing language model to your own information using RAG.

Just remember this simple workflow:

Find the information → Give it to the AI → Generate the answer.

That's the basic idea behind Retrieval-Augmented Generation.

And if you want to put this into practice, a great next project is building a PDF chatbot that lets users upload their notes and ask questions about them.

How Does a Neural Network Actually Learn?

Agrima Gupta — Wed, 07 Oct 2026 15:27:03 +0000

We've all heard this sentence:

"Neural networks learn from data."

But what does learn actually mean?

Does the model somehow understand the data? Does it remember every example? And how does it know when it's getting something wrong?

The answer is surprisingly simple.

A neural network basically follows this loop:

Predict → Check the Error → Adjust → Repeat

Let's see what that actually means.

Let's Start With a Simple Example

Imagine we're building a model that predicts whether a student will pass an exam based on how many hours they studied.

Our data could look like:

Hours Studied     Result

2                 Fail
4                 Fail
5                 Pass
7                 Pass
9                 Pass

We give the model:

6 hours

and ask:

"Will this student pass?"

The model makes a prediction.

Maybe it says:

35% chance of passing

But the actual answer is:

Pass

So the model got it wrong.

Now comes the interesting part: how does it improve?

The Model Starts With Weights

Inside a neural network, there are lots of numbers called weights.

You can think of weights as the importance given to different inputs.

A very simple neuron looks roughly like this:

Input
  ↓
× Weight
  ↓
+ Bias
  ↓
Activation
  ↓
Output

Mathematically:

output = (input × weight) + bias

At the beginning, these weights are usually initialized with small values.

The model doesn't know the correct values yet.

So it starts making predictions with basically a rough guess.

First, It Makes a Prediction

This is called forward propagation.

Data moves through the network:

Input
  ↓
Hidden Layers
  ↓
Output
  ↓
Prediction

For example:

6 hours
   ↓
Neural Network
   ↓
Prediction = 0.35

But how do we know whether 0.35 is good or bad?

We compare it with the actual answer.

Then It Measures How Wrong It Was

This is where the loss function comes in.

The loss function basically asks:

"How far was the prediction from the actual answer?"

Prediction
    ↓
Compare with Actual
    ↓
Calculate Loss

Large loss:

❌ Very wrong

Small loss:

✅ Pretty close

The goal of training is to make this loss smaller.

Now the Model Has to Fix Itself

This is where you hear two important words:

Backpropagation and Gradient Descent.

Don't let the names scare you.

Backpropagation basically works backward through the network to figure out:

"Which weights contributed to this mistake, and how should they change?"

Then gradient descent helps decide which direction those weights should move.

Think about standing on a mountain and trying to reach the lowest point.

You look at the slope and take a small step downhill.

Then another.

And another.

That's the basic intuition behind gradient descent.

High Loss
    ●
     \
      ●
       \
        ●
         \
          ●  ← Lower Loss

And Then It Does It Again... and Again...

This is the part that makes the model learn.

Data
 ↓
Prediction
 ↓
Calculate Loss
 ↓
Backpropagation
 ↓
Update Weights
 ↓
Prediction again
 ↓
Calculate Loss
 ↓
Update Weights
 ↓
Repeat...

After thousands or millions of these tiny adjustments, the model's parameters become much better at making predictions.

That's basically training.

Where Do Epochs Come In?

You might see something like:

Epoch 1/50
Epoch 2/50
...
Epoch 50/50

An epoch simply means the model has gone through the entire training dataset once.

So if you have:

10,000 training examples

then:

1 epoch = model sees all 10,000 examples once

Train for 50 epochs, and it sees that dataset 50 times.

So What Is the Model Actually Learning?

This is probably the most important part.

The model isn't memorizing:

6 hours = Pass
7 hours = Pass

Instead, it's learning patterns by adjusting its weights and biases.

At a very high level:

Training Data
      ↓
Adjust Parameters
      ↓
Reduce Error
      ↓
Learn Patterns

And when we give it data it hasn't seen before, those learned patterns help it make a prediction.

The Whole Idea in One Picture

If you remember only one thing from this article, remember this:

             Training Data
                   ↓
             Neural Network
                   ↓
               Prediction
                   ↓
             Loss Function
                   ↓
              "How wrong?"
                   ↓
            Backpropagation
                   ↓
            Update Weights
                   ↓
               Try Again
                   ↓
              Better Model

That's neural network learning in its simplest form.

Of course, real-world models get much more complicated — millions of parameters, GPUs, different optimizers, regularization, huge datasets, and architectures like Transformers.

But underneath all that complexity, the basic idea is still:

Predict → Measure the mistake → Adjust → Repeat.

That's how a neural network actually learns. 🧠

How Caching Saves Your Website From Thousands of Requests

Agrima Gupta — Tue, 06 Oct 2026 11:18:00 +0000

How Does Netflix Load So Fast? The Secret Is Caching.

Have you ever wondered why Netflix can serve millions of users without making its database work insanely hard for every single request?

Or why YouTube thumbnails appear almost instantly?

Or why a website you've already visited sometimes loads noticeably faster the second time?

One of the biggest reasons is caching.

You might have heard this word a hundred times, but the idea behind it is actually pretty simple:

If you've already done the expensive work once, why do it again?

Let's see how this works in real applications.

So, What Exactly Is Caching?

Imagine you go to a restaurant and order coffee.

The waiter doesn't go to the farm, collect coffee beans, roast them, grind them, and make the coffee from scratch every time you ask for another cup.

The restaurant already has the ingredients ready.

Caching follows a similar idea.

Instead of repeatedly fetching or calculating the same data, we temporarily store the result somewhere that can be accessed much faster.

Without caching, a request might look like this:

User
 ↓
Server
 ↓
Database
 ↓
Get Data
 ↓
Server
 ↓
User

With caching:

User
 ↓
Server
 ↓
Cache ⚡
 ↓
Data
 ↓
User

The database doesn't have to do the same work over and over again.

Let's Take a Simple Example

Imagine your website has an API:

GET /api/products

Every time someone visits your website, the backend might query the database:

SELECT * FROM products;

Now imagine 10,000 people visit your website.

You could end up with:

10,000 requests
      ↓
10,000 database queries

But what if the product list only changes occasionally?

There's no reason to ask the database the exact same question 10,000 times.

Instead, we can cache the result.

The first request goes to the database:

Request
   ↓
Backend
   ↓
Database
   ↓
Products
   ↓
Cache

The next requests can simply use the cached result:

Request
   ↓
Backend
   ↓
Cache ⚡
   ↓
Products

That's the basic idea behind caching.

Cache Hit vs Cache Miss

You'll often hear developers use the terms cache hit and cache miss.

A cache hit means the data you're looking for is already in the cache.

Request
   ↓
Cache
   ↓
Found ✅
   ↓
Return Data

A cache miss means the cache doesn't have the data.

Request
   ↓
Cache
   ↓
Not Found ❌
   ↓
Database
   ↓
Store Result in Cache
   ↓
Return Data

The goal is generally to have a high cache hit rate for data that makes sense to cache.

Your Browser Is Already Using Caching

Caching isn't something you only encounter in backend development.

Your browser does it all the time.

When you visit a website, your browser may store things like:

Images
CSS
JavaScript
Fonts
Other static resources

Suppose you download:

logo.png

The next time you visit the same website, your browser may already have that image.

Instead of downloading it again:

Server → Browser

the browser can use:

Browser Cache → logo.png

This is one of the reasons websites can feel faster when you revisit them.

Then There Are CDNs

Now imagine your main server is located in the US, but your users are all over the world.

A user in India requesting a large image might have to communicate with a server thousands of kilometres away.

That's where a CDN — Content Delivery Network — becomes useful.

A CDN stores copies of content across servers distributed around the world.

Without a CDN:

India
  ↓
US Server
  ↓
Response

With a CDN:

India
  ↓
Nearby CDN
  ↓
Response ⚡

CDNs are commonly used for images, videos, JavaScript, CSS, static pages, and sometimes API responses.

This is one of the techniques that allows large platforms to deliver content efficiently to users around the world.

What About Backend Caching?

Let's move one level deeper.

Suppose your backend has this endpoint:

GET /api/products

Without caching:

Request
  ↓
Backend
  ↓
Database
  ↓
Response

With caching:

Request
  ↓
Backend
  ↓
Cache
 ↙     ↘
Hit    Miss
 ↓       ↓
Data   Database
         ↓
       Cache
         ↓
      Response

This is where technologies like Redis are commonly used.

Redis is an in-memory data store, which makes it extremely useful for storing frequently accessed data.

For example, we might store:

Key:
products

Value:
[
  { id: 1, name: "Laptop" },
  { id: 2, name: "Mouse" }
]

Instead of hitting the database for every request, the backend can first check Redis.

A Simple Backend Example

Imagine a Python backend.

Without caching:

@app.get("/products")
def get_products():

    products = database.get_products()

    return products

Every request goes directly to the database.

With caching:

@app.get("/products")
def get_products():

    products = cache.get("products")

    if products:
        return products

    products = database.get_products()

    cache.set("products", products)

    return products

Now the logic is basically:

Request
   ↓
Check Cache
   ↓
Is data there?
  ↙       ↘
YES       NO
 ↓         ↓
Return   Database
           ↓
         Cache
           ↓
        Return

Simple idea, but extremely powerful when an application gets large.

But Here's the Problem With Caching

Imagine your website stores:

Product price = ₹999

in the cache.

Then the actual price changes:

₹999 → ₹899

But the cache still contains:

₹999

Now your users are seeing old information.

This is called stale data.

So caches usually have an expiration time, commonly called TTL — Time To Live.

For example:

Cache Data
    ↓
TTL = 60 seconds
    ↓
60 seconds pass
    ↓
Cache expires

The next request can fetch fresh data and store it again.

Cache Invalidation Is Where Things Get Interesting

There's a famous saying in software:

"There are only two hard things in Computer Science: cache invalidation and naming things."

And cache invalidation really can become complicated.

Suppose we have:

Database:
₹899

Cache:
₹999

When the product changes, we need to make sure the cache is updated or removed.

One approach is to delete the cached value:

cache.delete("product:123")

Then the next request fetches fresh data from the database.

Another approach is to update the cache whenever the database changes.

The right strategy depends on the application.

Why Not Cache Everything?

If caching makes things faster, why not cache the entire application?

Because caching comes with trade-offs.

Caches consume memory.

Cached data can become stale.

And now you have another system to manage.

Instead of:

Backend → Database

your architecture becomes:

Backend → Cache → Database

Now you have to think about what should be cached, how long it should live, and what should happen when the cache is unavailable.

Caching is powerful, but it isn't free.

What Makes Good Data for Caching?

A good candidate is usually data that is:

Frequently requested, expensive to calculate or retrieve, and doesn't change constantly.

For example:

Product catalog
Popular posts
API responses
Configuration
Frequently accessed database queries

Data that changes constantly or must always be completely real-time may be less suitable.

The important question isn't:

"Can I cache this?"

It's:

"Does caching this actually improve my application?"

How Much Faster Can Caching Be?

Let's use a simplified example.

Imagine:

Database query = 200ms
Cache lookup   = 5ms

If 1,000 requests all hit the database, that's a lot of unnecessary work.

But if most of those requests can be served from the cache, the database can focus on requests that actually need it.

The exact numbers will vary depending on your architecture, network, database, query, and cache setup.

But the fundamental idea remains:

Avoid expensive work when you already have the answer.

Caching Exists at Multiple Levels

One interesting thing about caching is that there isn't just one cache.

A modern application might look something like:

              USER
                ↓
         Browser Cache
                ↓
               CDN
                ↓
        Application Cache
                ↓
             Redis
                ↓
            Database
                ↓
         Database Cache

Different layers solve different problems.

And together, they can dramatically reduce the amount of work your backend and database need to perform.

The Mental Model I Use for Caching

Whenever you hear the word cache, think about one simple question:

"Do I already have this?"

If yes:

Return it ⚡

If no:

Fetch / Calculate
       ↓
Store
       ↓
Return

That's caching at its core.

Everything else — Redis, CDNs, TTLs, cache invalidation, cache hit rates — is built around this basic idea.

Final Takeaway

Caching isn't some complicated trick that only companies like Netflix or YouTube use.

It's a simple idea that becomes incredibly powerful at scale:

Don't do expensive work repeatedly when you can reuse the result.

Your browser caches images.

CDNs cache content.

Backends cache API responses.

Redis stores frequently accessed data.

Databases have their own caching mechanisms.

Together, these layers help modern applications serve huge amounts of traffic without forcing the database to handle every single request.

So the next time Netflix loads your homepage almost instantly, remember:

It probably isn't asking the database to figure everything out from scratch.

Somewhere along the way, someone already did the work — and the result is waiting in a cache. ⚡

How API Calls Actually Work: From Button Click to Server Response

Agrima Gupta — Mon, 05 Oct 2026 16:12:45 +0000

If you've worked with React, Next.js, or any frontend framework, you've probably written something like:

const response = await fetch("/api/users");
const data = await response.json();

Looks simple, right?

But I used to wonder:

What actually happens after I call fetch()?

Where does the request go?

How does the backend know what I want?

Where does the database fit in?

And how does the response come back to my UI?

Let's break down the entire journey of one API call.

The Big Picture

Imagine we have a button:

<button onclick="getUsers()">
  Get Users
</button>

When the user clicks it, the flow looks roughly like this:

Button Click
     ↓
Frontend JavaScript
     ↓
HTTP Request
     ↓
Backend API
     ↓
Database
     ↓
Backend Response
     ↓
Frontend
     ↓
UI Update

That's it.

Now let's see what's actually happening at each step.

1. The Button Click

Let's say we want to fetch a list of users.

async function getUsers() {

    const response = await fetch(
        "http://localhost:8000/api/users"
    );

    const data = await response.json();

    console.log(data);
}

The important line is:

fetch("http://localhost:8000/api/users")

We're basically telling the browser:

"Hey, send a request to this API and give me whatever comes back."

2. The Browser Sends an HTTP Request

Behind that simple fetch() call, the browser creates an HTTP request.

Something like:

GET /api/users

GET is the HTTP method.

Some common methods are:

GET     → Get data
POST    → Create data
PUT     → Replace data
PATCH   → Update data
DELETE  → Delete data

So:

GET /api/users

basically means:

"Give me the users."

3. The Backend Receives It

Now imagine our backend is built using FastAPI.

from fastapi import FastAPI

app = FastAPI()

@app.get("/api/users")
def get_users():

    return [
        {"id": 1, "name": "Agrima"},
        {"id": 2, "name": "Rahul"}
    ]

This line:

@app.get("/api/users")

is basically telling the backend:

"Whenever someone sends a GET request to /api/users, run this function."

So our request:

GET /api/users

finds this function:

get_users()

4. What About the Database?

In a real application, we're obviously not going to hardcode users.

The backend would probably query a database.

For example:

SELECT * FROM users;

The database might return:

1 | Agrima
2 | Rahul
3 | Priya

The backend then converts this into a response, usually JSON:

[
  {
    "id": 1,
    "name": "Agrima"
  },
  {
    "id": 2,
    "name": "Rahul"
  }
]

So now our flow becomes:

Frontend
   ↓
API Request
   ↓
Backend
   ↓
Database
   ↓
Backend

5. The Response Comes Back

The backend sends an HTTP response.

For example:

200 OK
Content-Type: application/json

with:

[
  {
    "id": 1,
    "name": "Agrima"
  },
  {
    "id": 2,
    "name": "Rahul"
  }
]

And this is where our frontend gets the data.

Remember this?

const response = await fetch("/api/users");

Now we do:

const data = await response.json();

And data becomes:

[
    { id: 1, name: "Agrima" },
    { id: 2, name: "Rahul" }
]

We can finally use it in our UI.

6. What Does `await` Actually Do?

This was another thing that confused me when I started.

An API request takes time.

Maybe:

50ms
200ms
1 second

JavaScript can't just assume the response will instantly arrive.

That's why we use:

await fetch(...)

We're basically saying:

"Send the request and wait for the response before continuing this function."

That's why API calls are commonly written with:

async/await

7. What If the API Fails?

Things go wrong. A lot.

Maybe the server is down.

Maybe the URL is wrong.

Maybe the user isn't authenticated.

Maybe the backend crashes.

So don't write API calls assuming everything will always work.

A basic pattern is:

async function getUsers() {

    try {

        const response =
            await fetch("/api/users");

        if (!response.ok) {
            throw new Error(
                `Request failed: ${response.status}`
            );
        }

        const data =
            await response.json();

        console.log(data);

    } catch (error) {

        console.error(
            "Something went wrong:",
            error
        );

    }
}

Some status codes you'll see often:

200 → Success
201 → Created
400 → Bad Request
401 → Unauthorized
403 → Forbidden
404 → Not Found
500 → Server Error

The Complete Flow

So that tiny line:

fetch("/api/users")

actually triggers a much bigger process:

        USER
          │
          ↓
    Clicks Button
          │
          ↓
     JavaScript
          │
          ↓
     fetch()
          │
          ↓
    HTTP Request
          │
          ↓
      Backend
          │
          ↓
      Database
          │
          ↓
      Backend
          │
          ↓
    HTTP Response
          │
          ↓
     JavaScript
          │
          ↓
       UI Update

And that's basically the request-response cycle.

One More Real-World Example

Think about an AI notes app.

You type:

"Summarize these notes"

and click Summarize.

Behind the scenes:

You click "Summarize"
        ↓
Next.js frontend
        ↓
POST /api/summarize
        ↓
Backend
        ↓
AI API
        ↓
AI generates summary
        ↓
Backend sends response
        ↓
Frontend receives it
        ↓
Summary appears on screen

You only see a button and a result.

But underneath, multiple systems are talking to each other.

That's the part I find most interesting about APIs.

Final Takeaway

An API call isn't just:

fetch("/api/users");

It's a conversation between different parts of an application.

Client → Request → Server → Process → Response → Client

Once you understand this flow, things like REST APIs, Axios, FastAPI, Express, authentication, CORS, and even AI APIs start making a lot more sense.

So next time you write:

await fetch(...)

you'll know what's actually happening behind that one line. 🚀

If you're learning APIs right now, try this: build a tiny frontend + backend with just three endpoints:

GET    /users
POST   /users
DELETE /users/:id

You'll learn more by building those three endpoints than by reading ten API tutorials.

An LLM Is Not Your Backend — Here's What I Learned

Agrima Gupta — Wed, 16 Sep 2026 04:53:23 +0000

When I first started working with AI, I used to think of an LLM as something like a super-smart backend. You give it some input, it understands it, processes it, and gives you an answer. So naturally, I started thinking, "Why do I need so much backend logic? Can't I just tell the LLM what my application does and let it handle everything?"

Turns out, no.
And understanding why completely changed the way I think about building AI applications.

So, What Even Is an LLM?
LLM stands for Large Language Model. In simple terms, an LLM is a system trained on huge amounts of text that learns patterns in language and uses those patterns to generate text.

Imagine you've spent your entire life reading books, articles, conversations, documentation, stories, emails, questions, answers, and code. After seeing enough examples, you become really good at understanding how language works and predicting what kind of sentence would make sense next. If someone says, "The sun rises in the..." your brain immediately expects the word "east." If someone says, "Can you pass me the..." you might expect "salt" or "water."

An LLM does something conceptually similar, except it does this using mathematical representations and neural networks at a massive scale.This is also why LLMs can do so many different things. They can explain concepts, write code, summarize documents, translate languages, generate stories, analyze text, and have conversations. It can feel like you're talking to something that understands everything. But underneath all of that, the model is still working with patterns it learned during training and generating tokens based on those patterns.

Is an LLM Just Autocomplete?
In a way, yes. But modern LLMs are obviously much more complicated than the autocomplete on your phone.Your keyboard might see "I'll see you" and predict that "tomorrow" could come next. That's a very simple example of predicting what comes next.

An LLM takes this basic idea to a completely different scale. Instead of looking at just a few words, it can process much larger contexts and has learned incredibly complicated patterns across language and code.That's why you can give it a paragraph of context and ask it to summarize it, give it a programming problem and ask for an implementation, or give it a messy explanation and ask it to turn that into structured information.

The important thing to understand is that the model doesn't work exactly like a human brain. It processes language mathematically and predicts what should come next based on the context it has received.

How Does an LLM Learn?
This is probably the most important part to understand.

Imagine teaching a child a language. You don't simply give them a dictionary and ask them to memorize every word. They hear people speaking, read things, see patterns, make mistakes, receive feedback, and gradually become better at understanding and producing language.Training an LLM is obviously much more complicated than this, but the basic intuition is somewhat similar.

The model is exposed to enormous amounts of training data. It processes pieces of text and repeatedly tries to predict what comes next. When its prediction is different from the actual data, the model's parameters are adjusted. This process happens again and again across huge amounts of data.

Over time, the model becomes extremely good at recognizing patterns in language.

This doesn't mean it stores every sentence it has seen like a giant database. Instead, the training process changes the model's internal parameters so that it becomes better at representing and generating language.

Here's a Simple Example,
Imagine I say, "I went to the restaurant and ordered..." Your brain might expect words like "food", "pizza", "dinner", or "burger."

An LLM does something conceptually similar, but mathematically. It calculates probabilities for possible next tokens based on the context. For example, the probabilities might conceptually look something like 32% for "pizza", 21% for "food", 15% for "dinner", and so on. These numbers are only an illustration, not actual probabilities from a specific model. The important idea is that the model is constantly predicting what should come next based on the context it has.

Then Why Does It Feel Like It's Thinking?
This is where things get really interesting.

If I ask an LLM, "Explain recursion like I'm five," I get a completely different kind of response than if I ask, "Write a Java solution for this problem."

If I ask it to rewrite an email professionally, it changes its tone. If I give it a long document, it can summarize the important parts. If I give it a programming problem, it can reason through possible approaches.

It can feel like there is an actual person sitting behind the screen thinking through my question. Modern models can perform surprisingly sophisticated reasoning and problem-solving tasks. But we shouldn't confuse that capability with an LLM being a complete software system.

The model generates an output.
Your application still needs to decide what happens after that output.

And that's where the title of this article comes in.

An LLM Is Not Your Backend

Let's imagine you're building an online food delivery application with an AI assistant.

A user says, "Order me a pizza."

You send that message to an LLM, and the LLM replies, "Sure! Your pizza has been ordered."

Sounds great.
But wait.
Did it actually order anything?

No.
The LLM generated a sentence. That's it.

It didn't check which restaurants are open. It didn't check whether the pizza is available. It didn't verify your address. It didn't process your payment. It didn't create an order in the database. It didn't send the order to the restaurant.

Those are backend responsibilities.

This distinction became very clear to me when I started thinking about AI applications as actual software products instead of just chatbots.

LLM vs Backend
The LLM is great at understanding natural language, extracting intent, generating responses, summarizing information, working with context, and deciding which tool might be useful.

The backend is responsible for things like authentication, authorization, database operations, business rules, transactions, validation, payments, APIs, security, and other deterministic operations.

These aren't competing responsibilities.
They're different responsibilities.

The LLM provides flexibility and intelligence around human language, while the backend provides control and reliability.

I Built an AI Voice Sales Agent — Here’s the Architecture Behind It

Agrima Gupta — Tue, 15 Sep 2026 08:55:51 +0000

I Built an AI Voice Sales Agent — Here’s the Architecture Behind It

What if a dealer could simply call a number, tell an AI what they need, and place an order through a normal conversation?

No app.
No searching through products.
No filling out forms.

Just talk.

That was the idea behind a project I've been working on: an AI Voice Sales Agent for dealers.

For example:

"I need 50 boxes of Product X and 20 of Product Y."

The AI should understand the request, check whether the products are available, figure out the dealer's pricing, apply any applicable schemes, confirm the order, and eventually push it into the company's ERP.

This isn't a finished enterprise product yet. I'm still building and figuring things out, but I wanted to document how I'm approaching the architecture and some of the decisions I've made along the way.

The Architecture

The basic flow looks something like this:

Dealer
↓
Phone Call
↓
Twilio
↓
OpenAI Realtime API
↓
LangGraph
↓
Business Tools
↓
FastAPI Backend
↓
PostgreSQL / Redis
↓
ERP

The interesting part isn't just getting an LLM to talk.

The AI actually needs to do things.

It should be able to:

Understand what the dealer wants
Search for products
Check inventory
Get dealer-specific pricing
Check applicable schemes
Remember useful customer context
Create draft orders
Eventually sync with an ERP
Handle failures without making things up

Let's break down how I'm thinking about each part.

The Voice Layer

The first challenge is simple:

How does the dealer actually talk to the system?

I'm using Twilio as the telephony layer.

The basic flow is:

Dealer calls
↓
Twilio receives the call
↓
Audio goes to the AI system
↓
AI processes the conversation
↓
Response is generated
↓
Dealer hears the response

Initially, I thought of voice as simply:

Speech → Text → LLM → Text → Speech

But once you start thinking about an actual conversation, latency becomes a huge deal.

Imagine saying something to an AI and waiting 4–5 seconds for every response.

Technically, it works.

As a conversation?

Not great.

That's why I'm looking at real-time voice capabilities rather than treating the system like a normal chatbot with a microphone attached to it.

The AI Layer

For the conversational intelligence, I'm using the OpenAI Realtime API.

But here's something I realized pretty quickly:

The LLM shouldn't be responsible for everything.

For example, if a dealer says:

"Give me 50 of the blue ones."

The AI needs to understand what "blue ones" refers to.

That requires conversation context.

The system might have something like:

Dealer:
ABC Distributors

Current conversation:
Product: Product X
Variant: Blue
Requested quantity: 50

Dealer preferences:
Preferred warehouse: Pune
Preferred language: English

So the AI understands the conversation instead of treating every sentence as an isolated question.

LangGraph — Making the AI Actually Do Things

This is probably one of the parts I'm most interested in.

I don't want the LLM to directly interact with my database and randomly decide what to do.

Instead, I'm giving the agent specific tools.

For example:

search_product()
check_inventory()
get_dealer_price()
get_scheme()
get_customer_history()
create_draft_order()

So a conversation could look something like:

Dealer:
"I need 50 units of Product X."

AI:
"Let me check the availability."

↓

check_inventory("Product X")

↓

Inventory:
72 units available

↓

AI:
"We have 72 units available. Would you like me to create the order for 50?"

↓

Dealer:
"Yes."

↓

create_draft_order(...)

This is where LangGraph becomes useful.

Instead of having one massive prompt trying to handle the entire business workflow, the agent can move through different states and use specific tools.

Conceptually:

START
↓
Understand Request
↓
Identify Product
↓
Check Inventory
↓
Check Dealer Pricing
↓
Apply Scheme
↓
Confirm Order
↓
Create Draft Order
↓
END

This also makes debugging much easier.

If something goes wrong, I can ask:

Which step failed?

Instead of:

Why did the AI randomly do that?

PostgreSQL — Where the Real Data Lives

One thing I definitely don't want is for the AI to become the source of truth.

The LLM can understand things.

It can reason.

It can communicate.

But it shouldn't be the database.

The system needs structured data for things like:

Dealers
Dealer contacts
Dealer addresses
Products
Product variants
SKUs
Inventory
Orders
Pricing
Schemes
Customer preferences

For example:

Dealer
├── Contacts
├── Addresses
├── Credit Limit
├── Language Preference
└── Preferred Warehouse

Product
├── Product Variant
├── SKU
├── Pricing
└── Inventory

I'm using PostgreSQL for this persistent data.

I'm also using UUIDs for primary keys and keeping things like timestamps, foreign keys, indexes, and soft-delete support in the domain design.

I'm still refining the schema, but getting this foundation right is important because adding AI on top of a messy data model isn't going to magically fix it.

Redis — The Fast Stuff

Not everything needs to be stored permanently in PostgreSQL.

A voice conversation can have a lot of temporary state.

For example:

Current session
Conversation state
Temporary context
Caching
Rate limits

That's where Redis comes in.

The mental model I'm using is basically:

PostgreSQL
= Persistent business data

Redis
= Fast temporary state + caching

Inventory Is Where Things Get Real

Let's say a dealer says:

"I need 100 units."

The AI can't just say:

"Sure, I've placed the order."

It needs to check what's actually available.

Something like:

Dealer Request
↓
Identify SKU
↓
Inventory Service
↓
Available Quantity
↓
AI Response

If the system only has 60 units, the AI should say:

"We currently have 60 units available. Would you like me to create the order for 60?"

This is a principle I'm trying to stick to throughout the project:

The AI should reason about business data, not invent business data.

Dealer-Specific Pricing

This is another place where a normal chatbot approach isn't enough.

In B2B, everyone doesn't necessarily get the same price.

Different dealers might have:

Different price lists
Different discounts
Different schemes
Different credit limits
Different warehouses
Different purchasing histories

So the flow could look like:

Base Product Price
↓
Dealer-specific Price
↓
Applicable Scheme
↓
Discount
↓
Final Price

But here's an important architectural decision:

The LLM shouldn't calculate the final business-critical price itself.

The backend should do that.

The AI can explain the result to the dealer.

The actual calculation should come from deterministic business logic.

Customer Memory

This is probably one of the coolest parts of the idea.

A useful sales agent shouldn't feel like it has amnesia after every phone call.

Suppose a dealer usually orders a particular product or prefers a particular warehouse.

The system could remember useful information such as:

Preferred warehouse
Preferred products
Typical order quantity
Preferred language
Previous orders
Communication preferences

Then a future conversation could be much smoother.

Instead of asking:

"Which warehouse do you want?"

every single time, the system could already know the dealer's preferred warehouse and simply confirm it when needed.

But there's an important distinction here.

Not everything the dealer says should automatically become permanent memory.

Memory needs rules.

Some information is temporary conversation context.

Some information is actual customer data.

And some information probably shouldn't be stored at all.

That's something I want to handle carefully as the project develops.

ERP Integration

Eventually, the AI needs to connect with the systems that the business already uses.

That's where ERP integration comes in.

The architecture I'm aiming for is:

AI Agent
↓
Backend
↓
Business Logic
↓
ERP APIs
↓
Orders / Inventory / Customers

I don't want the AI agent directly modifying ERP data.

Instead:

AI
↓
Tool
↓
Backend Validation
↓
ERP

That gives us a much safer boundary between the unpredictable nature of AI and the deterministic nature of enterprise systems.

Why I'm NOT Giving the LLM Direct Database Access

This is probably one of the biggest things I've learned while designing this.

It can be tempting to just give an LLM database access and say:

"Do whatever you need."

But for a system dealing with real orders, pricing and customer information, that's a very bad idea.

I'd rather have:

❌ LLM → Database

✅ LLM → Tool → Backend → Database

For example:

LLM
↓
get_inventory("SKU123")
↓
Backend validates request
↓
Database query
↓
Structured result
↓
LLM

Now I have a proper place for:

Authentication
Authorization
Validation
Logging
Security
Error handling
Auditing

And most importantly, I know exactly what the AI is allowed to do.

The Tech Stack

Frontend: Next.js

Styling: Tailwind CSS + shadcn/ui

Backend: FastAPI

Database: PostgreSQL

Cache / State: Redis

ORM: SQLAlchemy

Migrations: Alembic

Voice: Twilio

Real-time AI: OpenAI Realtime API

Agent Orchestration: LangGraph

Vector Search: pgvector

Version Control: Git + GitHub

Monitoring: Sentry + OpenTelemetry

I'm trying to avoid choosing technologies just because they're popular.

I want every piece of the stack to have a reason for being there.

What I'm Still Figuring Out

The project is still a work in progress, so there are a lot of things I'm actively figuring out.

Voice latency

A voice agent has to feel like a conversation.

Even a technically correct answer feels bad if it takes too long.

Hallucinations

The agent absolutely cannot randomly invent:

Product availability
Prices
Discounts
Order status
Credit information

Those things need to come from actual systems.

Conversation recovery

What happens when the dealer says:

"No, not that one. The other blue one."

The agent needs enough context to understand what they're referring to.

Tool failures

What if the inventory service is down?

The AI shouldn't pretend that everything worked.

It needs to understand that the tool failed and communicate that properly.

Security

Once you're dealing with actual business transactions, security becomes a major part of the architecture.

Things like:

Authentication
Authorization
PII protection
Call verification
Audit logs
Tool permissions

can't just be an afterthought.

The Biggest Thing I've Learned

The biggest lesson from this project so far is:

Building an AI application isn't the same as putting an LLM inside an application.

The LLM is only one part of the system.

A useful AI product needs:

AI
+
Business Logic
+
Data
+
Tools
+
State
+
Security
+
Observability
+
Reliable Infrastructure

The model provides the intelligence.

But the architecture around it provides the reliability.

And I think that's an important distinction, especially when moving from AI demos to actual products.

What's Next?

Right now, I'm focusing on building the foundation properly before trying to make everything "smart."

The next things on my list are:

Building the core backend APIs
Implementing the voice pipeline
Connecting the agent to business tools
Building the order workflow
Adding customer memory
Connecting inventory
Designing ERP synchronization
Adding observability
Testing real-world conversations

The end goal is pretty simple:

A dealer should be able to pick up a phone and complete a business transaction through a natural conversation.

Something like:

Call
↓
Talk
↓
Confirm
↓
Order

That's the experience I'm trying to build.

Final Thoughts

This project has also changed the way I think about software engineering.

Earlier, I mostly thought about applications as:

Frontend
+
Backend
+
Database

Now I'm asking a lot more questions:

What should the AI be allowed to decide?

What should the backend decide?

Where does the actual source of truth live?

What happens when the AI is wrong?

What happens when a tool fails?

How do we recover from a misunderstood request?

How do we make the whole thing observable?

And honestly, I'm still figuring out many of these answers.

That's probably my favorite part of building this.

I'm not trying to pretend I have the perfect architecture figured out.

I'm building it, breaking things, learning, and improving it as I go.

Build → Break → Learn → Improve.

If you're also building AI agents, voice applications, or AI-powered SaaS products, I'd love to hear what you're working on and what problems you've run into.

Let's learn from each other. 🚀

DEV Community: Agrima Gupta

RAG vs Fine-Tuning: Which One Should You Use for Your AI App?

How Do LLMs Predict the Next Word? Understanding Token Prediction

What Actually Happens When You Tap Your Phone to Pay?

How Can One Fake Email Compromise an Entire Company?

From Localhost to the Cloud: Understanding AWS for Beginners

How Can AI Answer Questions About Your PDFs? Meet RAG

How Does a Neural Network Actually Learn?

Let's Start With a Simple Example

The Model Starts With Weights

First, It Makes a Prediction

Then It Measures How Wrong It Was

Now the Model Has to Fix Itself

And Then It Does It Again... and Again...

Where Do Epochs Come In?

So What Is the Model Actually Learning?

The Whole Idea in One Picture

How Caching Saves Your Website From Thousands of Requests

How Does Netflix Load So Fast? The Secret Is Caching.

So, What Exactly Is Caching?

Let's Take a Simple Example

Cache Hit vs Cache Miss

Your Browser Is Already Using Caching

Then There Are CDNs

What About Backend Caching?

A Simple Backend Example

But Here's the Problem With Caching

Cache Invalidation Is Where Things Get Interesting

Why Not Cache Everything?

What Makes Good Data for Caching?

How Much Faster Can Caching Be?

Caching Exists at Multiple Levels

The Mental Model I Use for Caching

Final Takeaway

How API Calls Actually Work: From Button Click to Server Response

The Big Picture

1. The Button Click

2. The Browser Sends an HTTP Request

3. The Backend Receives It

4. What About the Database?

5. The Response Comes Back

6. What Does await Actually Do?

7. What If the API Fails?

The Complete Flow

One More Real-World Example

Final Takeaway

An LLM Is Not Your Backend — Here's What I Learned

I Built an AI Voice Sales Agent — Here’s the Architecture Behind It

6. What Does `await` Actually Do?