DEV Community: Chethan Ramaswamy

RAG Explained: A Beginner's Guide to Retrieval-Augmented Generation

Chethan Ramaswamy — Sat, 26 Sep 2026 06:31:04 +0000

If you've started learning Generative AI, you've probably come across terms like:

LLM. Embeddings. Vector Search. RAG.

At first, these terms can sound complicated.

But the basic idea behind RAG is actually quite simple.

Let's understand it with a real-world example. 👇

🤔 Imagine You Have 10,000 Company Documents

Imagine your company has thousands of documents:

HR policies
Travel policies
Product documentation
Technical guides
Customer FAQs
Security guidelines

Now an employee asks:

"How much can I claim for a hotel during business travel?"

Would you expect a general AI model to know your company's specific policy?

Probably not.

The information is inside your company's documents.

This is where RAG becomes useful.

💡 So, What Is RAG?

RAG stands for Retrieval-Augmented Generation.

Think of RAG like this:

Find the right information first, then ask the AI to answer using that information.

That's the basic idea.

A simplified flow looks like this:

User asks a question
        ↓
Find relevant information
        ↓
Give that information to the AI
        ↓
AI generates an answer

Let's see how this works.

🏨 A Simple Real-World Example

Suppose your company's travel policy says:

Employees can claim hotel expenses up to ₹5,000 per night when traveling for business.

An employee asks:

"What is the hotel reimbursement limit?"

A RAG application can:

Search the company's travel policy.
Find the relevant information.
Provide that information to the AI.
Generate an answer.

The AI can then respond:

"According to the travel policy, employees can claim hotel expenses up to ₹5,000 per night."

Notice what happened?

The AI didn't need to already know your company's travel policy.

The application retrieved the relevant information first.

That's the basic idea behind RAG.

🔍 How Does RAG Actually Work?

Let's break it down into a few simple steps.

Don't worry — we'll keep the technical jargon to a minimum.

A basic RAG application can be understood in two stages:

Prepare the knowledge
Answer the user's question

Let's look at both.

📚 Stage 1: Prepare the Knowledge

Before users can ask questions, we need to prepare the documents so that relevant information can be found quickly.

📄 Step 1: Collect Your Documents

Your knowledge could come from many places:

📄 PDF files
📝 Word documents
🌐 Websites
🗄️ Databases
☁️ Cloud storage
📚 Knowledge bases

For example:

Company Knowledge
       │
       ├── HR Policy.pdf
       ├── Travel Policy.pdf
       ├── Security Policy.pdf
       └── Product Manual.pdf

These documents become the knowledge source for our AI application.

✂️ Step 2: Break Large Documents into Smaller Pieces

Imagine you have a 100-page travel policy.

We don't want to send all 100 pages to the AI every time someone asks a question.

Instead, we divide the document into smaller pieces called chunks.

Travel Policy
      │
      ├── Chunk 1
      ├── Chunk 2
      ├── Chunk 3
      ├── Chunk 4
      └── ...

Why?

Because when someone asks a question, we usually need only the small section related to that question.

For example:

Question:

"What is the hotel reimbursement limit?"

The system might retrieve:

Chunk 27:

"Employees can claim hotel expenses
up to ₹5,000 per night..."

That's much more useful than sending the entire document to the AI.

💡 Think of it this way

Imagine giving a student a 500-page textbook and asking:

"Find the paragraph about hotel reimbursement."

It would take time to search through the entire book.

Instead, if we already know the relevant page, we can go directly there.

Chunking helps us create those smaller searchable pieces of information.

🧠 Step 3: Create Embeddings

Here's our first technical concept:

Embeddings.

Embeddings are numerical representations of text that help systems measure semantic similarity.

Embeddings help a system find information based on semantic similarity, rather than only matching exact words.

For example:

User asks:

"How much can I claim for a hotel?"

The document says:

"Hotel accommodation expenses are limited to ₹5,000 per night."

The words aren't exactly the same.

But the meaning is related.

Embeddings help the system identify this semantic similarity.

You can think of it like this:

Text
 ↓
Embedding Model
 ↓
Numerical Vector
 ↓
Compare with other vectors
 ↓
Find semantically similar content

You don't need to understand the mathematics behind embeddings to start learning RAG.

The important thing to remember is:

Embeddings help a system find information based on semantic similarity, rather than only matching exact words.

🗂️ Step 4: Store the Information

Now we need somewhere to store our document chunks and their embeddings.

This is where vector databases and vector search systems come in.

Some popular options include:

Azure AI Search
PostgreSQL + pgvector
Pinecone
Qdrant
Weaviate

Think of this as a smart search system for your documents.

Conceptually:

Document Chunk
      +
Embedding
      +
Metadata
      ↓
Vector Search

Metadata can contain information such as:

Document: TravelPolicy.pdf
Department: Finance
Year: 2026
DocumentType: Policy

This additional information can help the application filter and organize the data.

🔎 Stage 2: Answer the User's Question

Now our knowledge has been prepared.

Let's see what happens when a user asks a question.

🔎 Step 5: The User Asks a Question

The employee asks:

"What is the hotel reimbursement limit?"

The application converts the question into an embedding and uses it to search the knowledge base.

The search might return several results:

Result 1:
Employees can claim hotel expenses
up to ₹5,000 per night.

Result 2:
Business travel expenses must be
submitted within 30 days.

Result 3:
International travel requires
manager approval.

The application identifies the information that is most relevant to the question.

🤖 Step 6: Give the Information to the AI

Now we have two important pieces:

Question:

What is the hotel reimbursement limit?

Relevant information:

Employees can claim hotel expenses up to ₹5,000 per night.

The application provides the question and retrieved context to the LLM.

Conceptually:

User Question
      +
Retrieved Context
      ↓
Prompt
      ↓
LLM
      ↓
Generated Answer

The LLM can then generate:

"Employees can claim hotel expenses up to ₹5,000 per night."

And that's the Generation part of Retrieval-Augmented Generation.

🧩 The Complete RAG Flow

Now let's separate the process into two simple flows.

Preparing the knowledge

Documents
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector Search Index

Answering a question

User Question
      ↓
Question Embedding
      ↓
Search the Knowledge Base
      ↓
Relevant Chunks
      ↓
Question + Retrieved Context
      ↓
LLM
      ↓
Final Answer

This is the heart of a RAG application.

Retrieve relevant information → provide it as context → generate an answer.

🔍 Is RAG Just Search?

Not exactly.

Traditional search might work like this:

Question
   ↓
Search
   ↓
List of Documents

You then need to open the documents and find the answer yourself.

RAG goes one step further:

Question
   ↓
Search Relevant Information
   ↓
Provide Context to AI
   ↓
Generate Answer

So you can think of RAG as:

Search + AI

Traditional search helps you find information.

A RAG application helps an AI system retrieve relevant information and generate an answer using that information.

🆚 RAG vs Fine-Tuning

This is another question beginners often have:

"Why not fine-tune the model instead?"

RAG and fine-tuning solve different problems.

RAG	Fine-Tuning
Retrieves external information at query time	Further trains the model
Useful when knowledge changes frequently	Useful for specialized behavior or tasks
Documents can be updated independently	Requires a training process
Commonly used for knowledge-based applications	Commonly used for specialized model behavior

A simple way to remember it:

RAG → Give the AI relevant information.

Fine-tuning → Adapt the AI for a specific behavior or task.

For example, if your company's HR policy changes next month, you can update the knowledge source used by a RAG application without retraining the language model.

🌎 Where Can We Use RAG?

RAG isn't limited to company policies.

It can be used in many real-world applications.

👨‍💻 Developer Assistant

A developer asks:

"How does our authentication service work?"

The RAG application searches the company's technical documentation and provides relevant context to the LLM.

🏢 HR Assistant

An employee asks:

"How many vacation days can I carry forward?"

The application searches HR policies and generates an answer based on the retrieved information.

🛠️ Customer Support

A customer asks:

"How do I reset my device?"

The application can search product documentation and provide step-by-step guidance.

📚 Enterprise Knowledge Assistant

An employee asks:

"What is the process for raising a purchase request?"

The application searches company procedures and generates a response.

The common pattern is:

Company Knowledge
       ↓
      RAG
       ↓
      LLM
       ↓
  AI Assistant

⚠️ Does RAG Make AI 100% Accurate?

No.

This is important to understand.

RAG can provide the AI with relevant information, but it does not guarantee a perfect answer.

For example, if the retrieval system finds the wrong information, the LLM may generate an incorrect response based on that context.

There can also be problems if:

The source document contains incorrect information.
Important information was not retrieved.
The retrieved context is incomplete.
The prompt doesn't clearly guide the model.
The model misunderstands the retrieved context.

That's why production RAG systems need good:

Document processing
Search and retrieval
Security
Prompt design
Evaluation
Monitoring

So don't think of RAG as a magic solution.

Instead, think of it as a way to ground an AI application with relevant external information.

☁️ What Does RAG Look Like with .NET and Azure?

If you're a .NET developer, a simple enterprise RAG architecture could look like this:

                 User
                   ↓
              .NET Web API
                   ↓
             Azure AI Search
                   ↓
             Relevant Chunks
                   ↓
             Prompt + Context
                   ↓
             Azure OpenAI
                   ↓
              AI Response

Your .NET application can orchestrate the process:

Receive the user's question.
Search for relevant information.
Retrieve the relevant chunks.
Build the prompt with the retrieved context.
Send the request to the AI model.
Return the response.

This makes RAG particularly interesting for developers working with .NET and Azure.

🎯 The 5 Things You Need to Remember

If you're completely new to RAG, remember these five concepts:

Documents

Where your knowledge lives.
Chunks

Smaller pieces of your documents.
Embeddings

Numerical representations that help systems measure semantic similarity.
Retrieval

Finding information relevant to the user's question.
Generation

The LLM uses the retrieved information to generate the answer.

Put them together:

Documents
    ↓
Chunks
    ↓
Embeddings
    ↓
Search
    ↓
Relevant Context
    ↓
LLM
    ↓
Answer

That's Retrieval-Augmented Generation.

💬 Your Turn

Have you tried building a RAG application?

What would you like to build with RAG?

👨‍💻 Developer assistant
📄 Document chatbot
🏢 Enterprise knowledge assistant
🛠️ Customer support assistant
🤖 Something else

Share your idea in the comments. 👇

📌 Key Takeaway

If you remember just one sentence from this article, remember this:

A RAG application retrieves relevant information from a knowledge source and provides it to an LLM so it can generate a more informed response.

And that's the foundation of many modern Generative AI applications.

Designing a Scalable Notification System using .NET, Azure Service Bus, MediatR, and SignalR

Chethan Ramaswamy — Tue, 31 Mar 2026 19:35:49 +0000

Designing a Scalable Notification System using .NET, Azure Service Bus, MediatR, and SignalR

Why I'm Writing This

“Send a notification when something happens.”

It sounds simple.

But in a real application, notifications can quickly become more complicated than expected.

You may need to support:

Real-time UI notifications
Email and SMS
Multiple consumers
Retries and failure handling
High traffic
Future integrations
Loose coupling between business logic and notification processing

The challenge is not simply how to send a notification.

The real question is:

How do we design notifications so they don't become tightly coupled to the core business flow?

This article walks through one approach using .NET, MediatR, Azure Service Bus, SignalR, and the Outbox Pattern.

The Problem with the "Simple" Approach

A common implementation starts with something like:

API
  ↓
Save to Database
  ↓
Send Email
  ↓
Send Notification

It works.

At least initially.

But as the application grows, problems start appearing.

Every feature begins calling notification logic directly:

OrderService → NotificationService
PaymentService → NotificationService
UserService → NotificationService

Then new requirements arrive:

Add SMS
Add push notifications
Add in-app notifications
Add analytics
Add audit events

The notification service gradually becomes tightly coupled to multiple parts of the application.

Another problem is failure handling.

What happens if the email provider is temporarily unavailable?

Should the order creation fail?

Usually, the answer is no.

The business operation and notification delivery have different reliability requirements.

A Better Approach: Event-Driven Notifications

The basic idea is:

Business Action
      ↓
Domain/Application Event
      ↓
Outbox
      ↓
Message Broker
      ↓
Notification Consumers
      ↓
Email / UI / SMS / Push / etc.

The business operation completes without waiting for every notification channel to finish.

This creates a much cleaner boundary between:

"Something happened"

and

"What should we do because it happened?"

High-Level Architecture

The production-oriented architecture looks like this:

                         ┌──────────────────┐
                         │      Client      │
                         └────────┬─────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │   .NET Web API   │
                         └────────┬─────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │     MediatR      │
                         │ Command Handler  │
                         └────────┬─────────┘
                                  │
                                  ▼
                     ┌──────────────────────────┐
                     │    Database Transaction  │
                     │                          │
                     │  ┌────────┐ ┌─────────┐ │
                     │  │ Order  │ │ Outbox  │ │
                     │  └────────┘ └─────────┘ │
                     └────────────┬─────────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │ Outbox Processor │
                         └────────┬─────────┘
                                  │
                                  ▼
                     ┌────────────────────────┐
                     │  Azure Service Bus     │
                     │        Topic           │
                     └────────────┬───────────┘
                                  │
                   ┌──────────────┼──────────────┐
                   │              │              │
                   ▼              ▼              ▼
             ┌──────────┐   ┌───────────┐  ┌──────────┐
             │  Email   │   │  SignalR  │  │  Audit   │
             │ Consumer │   │  Consumer │  │ Consumer │
             └──────────┘   └─────┬─────┘  └──────────┘
                                  │
                                  ▼
                     ┌────────────────────────┐
                     │ Azure SignalR Service  │
                     └────────────┬───────────┘
                                  │
                                  ▼
                           ┌─────────────┐
                           │   Clients   │
                           │Browser/Mobile│
                           └─────────────┘

The important principle is that each component has a specific responsibility.

The Outbox is part of the primary architecture, not an afterthought.

Where MediatR Fits

MediatR sits primarily inside the application layer.

Instead of having a controller directly coordinate business operations:

Controller
    ↓
Service
    ↓
Database

we can use a request/handler model:

Controller
    ↓
MediatR
    ↓
Command Handler
    ↓
Business Logic
    ↓
Database

For example:

public record CreateOrderCommand(
    int CustomerId,
    decimal Amount
) : IRequest<int>;

The handler processes the command:

public class CreateOrderHandler
    : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(
        CreateOrderCommand request,
        CancellationToken cancellationToken)
    {
        // Validate business rules
        // Create order
        // Save order

        return orderId;
    }
}

MediatR also provides a clean place for application-level cross-cutting concerns such as:

Validation
Logging
Performance measurement
Authorization
Transaction behavior

The important point is:

MediatR is not the message broker.

It helps with in-process application decoupling.

Azure Service Bus handles distributed messaging between processes or services.

That distinction becomes important as the system grows.

Why Azure Service Bus?

After the business operation is committed, an event such as OrderCreated needs to be delivered to downstream consumers.

With the Outbox Pattern, the event is first persisted as part of the same database transaction and is then published asynchronously.

For example:

{
  "eventType": "OrderCreated",
  "orderId": 12345,
  "customerId": 1001
}

The resulting flow becomes:

Order Service
     ↓
Outbox
     ↓
Outbox Processor
     ↓
Azure Service Bus
     ↓
Notification Consumers

Azure Service Bus provides the messaging infrastructure between the producer and consumers.

Instead of:

Order Service
     ↓
Notification Service

we have:

Order Service
     ↓
Outbox
     ↓
Azure Service Bus
     ↓
Notification Consumers

This provides several benefits.

1. Loose Coupling

The producer doesn't need to know which consumers exist.

Today:

OrderCreated
    ↓
Email

Tomorrow:

OrderCreated
    ↓
Email
SMS
Analytics
Audit
Push Notification

The order-processing logic doesn't need to change simply because another consumer was added.

2. Retry and Failure Handling

Azure Service Bus provides messaging and delivery mechanisms, while retry behavior is typically implemented through the Service Bus client and consumer/application logic.

Transient failures can therefore be handled without making the original business transaction depend on downstream notification delivery.

Messages that repeatedly fail processing can also be moved to a dead-letter queue for investigation or later recovery.

The exact retry strategy should be designed at the consumer level based on the type of failure.

For example:

Message
   ↓
Consumer
   ↓
Processing succeeds?
   ├── Yes → Complete message
   │
   └── No
       ↓
   Retry / Redelivery
       ↓
   Repeated failure?
       └── Dead-letter

3. Independent Scaling

The notification consumers can scale independently from the API.

For example:

API instances
     ↓
Outbox Processor
     ↓
Service Bus
     ↓
Notification Workers

If notification volume increases significantly, the consumer side can be scaled independently.

4. Future Integrations

The same event can potentially be consumed by additional systems without modifying the original producer.

This is particularly useful in larger enterprise environments.

Topics and Subscriptions

For multiple consumers, an Azure Service Bus Topic with multiple Subscriptions is a natural fit.

For example:

                  OrderCreated Event
                         │
                         ▼
                ┌─────────────────┐
                │ Azure Service   │
                │ Bus Topic       │
                └────────┬────────┘
                         │
             ┌───────────┼───────────┐
             │           │           │
             ▼           ▼           ▼
        Email Sub    SignalR Sub   Audit Sub
             │           │           │
             ▼           ▼           ▼
          Email       SignalR       Audit

Each subscription can receive its own copy of the message.

This keeps consumers independent.

It also means that one consumer can fail or be delayed without preventing another subscription from processing its own copy of the event.

SignalR for Real-Time Notifications

For browser-based real-time notifications, polling can introduce unnecessary latency and traffic.

SignalR allows the server to push messages to connected clients.

For example:

OrderCreated Event
        ↓
SignalR Consumer
        ↓
SignalR Hub
        ↓
Azure SignalR Service
        ↓
Connected Client

The client can receive something like:

"Order #12345 has been created successfully."

This works particularly well for:

Dashboards
Order tracking
Monitoring systems
Alerts
Chat-like applications
In-app notifications

A SignalR connection can also be associated with a user or group, allowing notifications to be targeted appropriately.

SignalR at Scale

A single SignalR server is straightforward.

The challenge appears when the application is deployed across multiple instances.

For example:

                       ┌──────────────────────┐
                       │   Azure SignalR      │
                       │      Service         │
                       └──────────┬───────────┘
                                  │
                    ┌─────────────┼─────────────┐
                    │             │             │
                    ▼             ▼             ▼
               API Instance   API Instance   API Instance

For Azure-hosted applications, Azure SignalR Service can provide the scale-out layer for SignalR connections.

This allows application instances to remain focused on application processing while Azure SignalR Service manages persistent client connections.

The exact deployment model depends on application scale, hosting model, and operational requirements.

End-to-End Flow

Let's put everything together.

Step 1 — User performs an action

The user creates an order.

Client → POST /orders

Step 2 — API receives the request

The controller sends a command through MediatR.

Controller
    ↓
CreateOrderCommand
    ↓
MediatR

Step 3 — Command handler processes the business operation

The handler validates the request and creates the order.

The order and the corresponding outbox event are persisted in the same database transaction.

Database Transaction
       │
       ├── Order
       │
       └── Outbox Event

This is important because it prevents the application from successfully committing the order while completely losing the event because of a separate publish operation.

Step 4 — Outbox processor publishes the event

A background process reads unpublished events from the outbox and publishes them to Azure Service Bus.

Database
   ↓
Outbox Processor
   ↓
Azure Service Bus Topic

The business transaction does not wait for the downstream consumers to finish.

Step 5 — Consumers process the event

Different consumers can react independently.

                 OrderCreated
                      ↓
              Azure Service Bus
                 /     |      \
                /      |       \
               ▼       ▼        ▼
            Email   SignalR    Audit

Step 6 — Real-time update reaches the client

The SignalR consumer sends an update to the appropriate connected client.

Service Bus
     ↓
SignalR Consumer
     ↓
SignalR Hub
     ↓
Azure SignalR Service
     ↓
Browser / Mobile

The key principle is:

Order creation should not depend on notification delivery succeeding.

One Important Production Consideration: The Outbox Pattern

There is a subtle issue with a simpler implementation.

Consider this sequence:

1. Save Order
2. Publish OrderCreated

What happens if step 1 succeeds but step 2 fails?

The order exists in the database, but the event was never published.

This is a classic dual-write problem.

For production systems where reliable event publishing is important, an Outbox Pattern can help.

Instead of:

Save Order
     ↓
Publish Event

we persist both the business data and the outgoing event in the same database transaction:

Database Transaction
       │
       ├── Order
       │
       └── Outbox Event

A background worker then reads the outbox and publishes events to Service Bus:

Database
   ↓
Outbox Processor
   ↓
Azure Service Bus
   ↓
Consumers

This separates the critical business transaction from downstream message delivery while preserving the event that needs to be published.

Handling Duplicate Messages

Messaging systems should generally be designed with the assumption that a message can potentially be delivered more than once.

Azure Service Bus commonly uses at-least-once delivery semantics with Peek-Lock processing, so consumers should be designed to handle duplicate delivery safely.

That means consumers should ideally be idempotent.

For example:

Message ID: 8f23...

The consumer can maintain a record of processed message IDs.

If the same message arrives again:

Message
   ↓
Already processed?
   ├── Yes → Ignore / safely return
   └── No  → Process

This becomes especially important when processing operations such as:

Sending emails
Updating notification state
Creating records
Calling external APIs

Azure Service Bus also provides duplicate detection capabilities, but duplicate detection should not be treated as a replacement for idempotent consumer design.

Trade-Offs

This architecture is not free.

You are introducing additional infrastructure:

Azure Service Bus
Outbox storage
Background consumers
SignalR / Azure SignalR Service
Monitoring
Retry handling
Dead-letter handling
Distributed tracing

There is also eventual consistency.

For example:

Order Created
      ↓
Outbox Event
      ↓
Event Published
      ↓
Consumer Processes Event
      ↓
Notification Appears

The notification might appear milliseconds or seconds after the business operation.

But that trade-off can be worthwhile when the system needs:

Scalability
Resilience
Independent consumers
Extensibility
Loose coupling

The architecture should still be evaluated against the actual requirements.

A small application with one notification channel may not need all of these components.

Where This Architecture Works Well

This pattern can be useful in systems such as:

E-commerce

OrderPlaced
    ↓
Email
Inventory
Payment
Shipping
Customer Notification

Banking

TransactionCompleted
    ↓
SMS
Email
Mobile Push
Audit
Fraud Monitoring

Monitoring Platforms

AlertRaised
    ↓
Dashboard
Email
SMS
Incident Management

Enterprise Applications

Any system where a business event may need to trigger multiple independent downstream actions can benefit from this approach.

Key Design Principles

The technology is important, but the architectural principles matter more.

MediatR

Use it for in-process application decoupling.

Azure Service Bus

Use it for asynchronous communication between distributed components.

Azure Service Bus Topics and Subscriptions

Use them when multiple independent consumers need to react to the same event.

SignalR

Use it for real-time communication with connected clients.

Azure SignalR Service

Consider it when SignalR needs to scale across multiple application instances in Azure.

Outbox Pattern

Use it when you need stronger guarantees between database state and event publishing.

Idempotent Consumers

Design consumers so duplicate messages don't create unintended side effects.

Dead-Letter Handling

Treat repeatedly failed messages as operational data that needs monitoring, investigation, and potentially controlled replay.

Final Thoughts

Notifications are easy to implement when a system is small.

They become much more interesting when the application needs to scale, support multiple channels, handle failures, and evolve over time.

A useful separation is:

Business Logic
      ↓
Database Transaction
      ↓
Outbox Event
      ↓
Message Broker
      ↓
Independent Consumers
      ↓
Notification Channels

With this approach, the core business operation doesn't need to know whether the notification is delivered through email, SignalR, SMS, push notifications, or a future integration.

The result is an architecture that is more decoupled, scalable, resilient, and easier to evolve.

And perhaps the most important lesson:

Don't let notification delivery become part of your critical business transaction unless it truly needs to be.

If you've implemented a similar architecture, I'd be interested in hearing how you handled retries, ordering, duplicate messages, dead-letter queues, and the outbox problem.

dotnet #azure #systemdesign #microservices #softwarearchitecture #azureservicebus #signalr #mediatr #eventdrivenarchitecture