DEV Community: Karam Khoury

MCP vs RAG: Two AI Buzzwords, Explained Without the Buzzwords

Karam Khoury — Thu, 06 Aug 2026 12:33:37 +0000

A few weeks ago, a junior engineer on my team asked me: "Should we use RAG or MCP for this feature?"

He said it like the two were competing options. Like picking between React and Vue.

They're not. One is about giving an AI knowledge. The other is about giving an AI hands. Once you see that difference, the buzzwords stop being scary.

The Core Concept, in One Line Each

RAG (Retrieval-Augmented Generation): Before the AI answers you, it goes and reads relevant documents first, then writes its answer based on what it just read.

MCP (Model Context Protocol): A standard way for an AI to connect to and use outside tools — like your calendar, your database, or your file system — instead of just talking about them.

Here's the simplest way to picture it:

RAG:  Question -> Search your documents -> Read the best matches -> Answer
MCP:  Question -> Call a real tool (email, calendar, database) -> Get a real result -> Answer

RAG makes the AI smarter about what it knows.
MCP makes the AI capable of doing something.

Where They're Similar

Both exist to fix the same core problem: an AI, by itself, only knows what it was trained on, up to a certain date. It can't see your company's internal wiki. It can't see today's stock price. It can't see the email that just landed in your inbox.

Both RAG and MCP are ways of feeding an AI fresh, outside information at the moment you ask your question, instead of relying only on what it memorized during training.

That's the whole family resemblance. After that, they split in very different directions.

Where They're Different

RAG is about reading. MCP is about acting.

	RAG	MCP
What it does	Finds and reads relevant text	Connects to and operates a tool
Typical use	"Answer using our documents"	"Book this meeting" or "Update this record"
Output	Better, more accurate answers	Real actions with real side effects
Example source	A PDF, a knowledge base, a set of notes	A calendar app, an email inbox, a database

Think of RAG as a very fast research assistant. You ask a question, they run to the library, grab the three most relevant pages, and hand them to you before you even finish your coffee.

Think of MCP as a universal remote control. It doesn't know anything by itself — but it can press the right buttons on whichever device you point it at: your calendar, your CRM, your ticketing system.

Where To Use Each

Use RAG when the problem is "the AI doesn't know this."

A customer support bot that needs to answer questions using your product manuals.
A legal assistant that needs to reference your actual contracts, not generic legal knowledge.
An internal chatbot that answers HR questions using your company's real policy documents.

Use MCP when the problem is "the AI needs to do this."

An assistant that checks your real calendar and books a meeting for you.
A support agent that actually creates a ticket in your helpdesk system, not just describes one.
A coding assistant that reads your real files and runs your real tests, instead of guessing.

Use both when you need an AI that is both well-informed and useful. A great example: a customer support AI that uses RAG to pull the correct refund policy from your documents, then uses MCP to actually process the refund in your billing system.

A Real-Life Example

Imagine you run an online store and you build an AI assistant for customer support.

A customer asks: "What's your return policy for items bought during the sale, and can you start my return?"

RAG kicks in first. It searches your actual return policy documents, finds the section about sale items (which usually has different rules than regular items), and pulls the exact, correct answer instead of a generic guess.
MCP kicks in next. It connects to your order management system, finds the customer's real order, and actually starts the return process.

Without RAG, the AI might confidently give the wrong policy. Without MCP, the AI could only tell the customer how to start a return, not actually start it. Together, the customer gets a correct answer and a completed action, in one conversation.

Practical Impact for Your Team

Getting this distinction right changes how you scope a project.

If a stakeholder says "make the AI smarter about our documents," that's a RAG problem — you're building a search-and-retrieve pipeline over your content.

If they say "make the AI actually do things in our systems," that's an MCP problem — you're building integrations and giving the AI safe, well-defined tools to call.

Confusing the two leads to wasted sprints: teams building elaborate document search when what the business actually wanted was for the AI to update a record, or vice versa.

Actionable Takeaways

RAG = knowledge. Use it when the AI needs facts it wasn't trained on.
MCP = capability. Use it when the AI needs to perform a real action in a real system.
They're not rivals. Most serious AI products end up using both together.
Scope your project by the verb. "Answer using X" → RAG. "Do X" → MCP.
Start small. Pick one document set for RAG, or one tool for MCP, prove it works, then expand.

Once you strip away the acronyms, both ideas are things you already understand: look it up before you answer, and use the right tool for the job.

Concurrency vs Parallelism: A Simple Guide

Karam Khoury — Tue, 04 Aug 2026 06:44:36 +0000

Concurrency: juggling tasks

Think of concurrency like a chef in a busy kitchen. The chef doesn't cook all dishes at the exact same time — they chop some vegetables, stir a pot, check the oven, and go back to chopping. They make progress on multiple tasks by switching between them quickly.

In computing, concurrency means a system can handle multiple tasks overlapping in time, but not necessarily running at the same instant.

Tasks take turns (like a single CPU core switching between processes).
Useful when tasks involve waiting (downloading files, handling user input).
Common in applications like web servers that manage many users at once.

Parallelism: doing tasks side by side

Now imagine two chefs in the same kitchen. One chops vegetables while the other grills meat — both working at the same time.

That's parallelism: tasks actually running simultaneously, using multiple resources (like multiple CPU cores).

Tasks run truly at the same time.
Requires hardware support (multi-core processors, GPUs).
Used for heavy computation (video encoding, scientific simulations).

Real-world examples

Concurrency: a chat app handling thousands of messages — it switches between users so fast it seems instant.
Parallelism: a weather-forecast model running calculations across multiple CPUs to predict storms faster.

When to use each

Use concurrency when tasks involve waiting (I/O, network requests).
Use parallelism when you need brute-force speed (data processing, rendering).

Takeaway

Concurrency = managing multiple tasks efficiently (even on a single core).
Parallelism = executing multiple tasks at the same time (needs multiple cores).

Both are essential in modern software, and understanding them helps you write faster, more responsive programs.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

AWS Introduction for Beginner Software Engineers

Karam Khoury — Tue, 04 Aug 2026 06:39:39 +0000

As a software engineer starting with AWS, you might feel overwhelmed by all the services. Let me break down the key components with real-world examples to help you get started.

1. DNS & How AWS Route 53 Works

Problem: Users can't remember IP addresses like 54.210.167.101 for your app.

Solution: AWS Route 53 (DNS service) maps yourdomain.com to your servers.

Real example: Your startup has servers in Ohio and Frankfurt. Route 53 automatically sends European users to Frankfurt and routes US traffic to Ohio — faster load times for everyone.

2. Networking: VPC & Subnets

VPC: Your private cloud network (like an office building).
Public subnet: For web servers (needs internet access).
Private subnet: For databases (blocked from direct internet access).
Internet Gateway: Connects public subnets to the internet.
NAT Gateway: Lets private subnets reach the internet (one-way).

Real example: In your e-commerce app, the web server runs in a public subnet while the database sits in a private subnet.

3. Storing & Delivering Static Files (S3 + CloudFront)

Amazon S3: Stores images, videos, and logs.
CloudFront (CDN): Caches content globally for faster loading.

Real example: Your blog hosts images in S3; CloudFront caches them in 450+ locations, so a reader in Tokyo gets images from Japan instead of Virginia — cutting load time by ~50%.

Pro tip: Enable S3 Versioning to recover accidentally deleted files.

4. Running Backend Services

AWS Lambda (Serverless) — best for event-driven tasks. Example: a photo app resizes images automatically on upload.

EC2 (Virtual Servers) — best for full control (custom OS, legacy apps). Example: hosting a Java monolith with specific dependencies.

ECS/EKS (Containers) — best for microservices (Docker/Kubernetes). Example: a food-delivery app with separate services for orders, payments, and tracking.

5. Databases: Picking the Right One

Amazon RDS (SQL): Structured data with relationships — e.g. user accounts + orders.
DynamoDB (NoSQL): High-speed, scalable lookups — e.g. a ride-sharing app tracking real-time driver locations.
Aurora (High-Performance SQL): Low-latency apps — e.g. stock-trading platforms.

6. Adding AI/ML to Your App

Amazon Bedrock (pre-trained AI): e.g. a customer-support chatbot trained on your FAQ docs.
SageMaker (custom ML models): e.g. a recommendation engine ("users who bought X also liked Y").

7. Security Essentials

VPC: Controls how your networking works — what can connect to what, what reaches the internet, and what stays private.
NACLs (Network ACLs): A firewall for an entire subnet.
Security Groups: A firewall for each specific instance or service.
IAM (Identity & Access Management): Controls who can access what.

Golden rule — least privilege: a Lambda function should only access the one DynamoDB table it needs; backup processes get read-only access; only DevOps can reach production databases.

8. Monitoring & Debugging

CloudWatch: Tracks performance metrics and logs (EC2 CPU, Lambda errors). Example: alert when database CPU hits 90%.
CloudTrail: Audit logs ("who changed IAM policies?", "who deleted an S3 bucket?") — critical for compliance.

Putting it all together

Imagine building "Twitter Lite":

Route 53 routes users to the nearest server.
CloudFront + S3 deliver profile pictures fast.
EC2 or Lambda runs the backend API.
DynamoDB stores tweets for instant loading.
CloudWatch alerts you if something breaks.

Next steps for beginners

Hands-on: try the AWS Free Tier (12 months free).
First project: deploy a static website on S3 + CloudFront.
Deep dive: learn Lambda + DynamoDB.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

Oops, I Committed a Secret: A Calm Guide to Scrubbing Git History

Karam Khoury — Fri, 24 Jul 2026 12:00:25 +0000

You just finished a great feature. You're in the flow.

git add .
git commit -m "Fixed the bug!"
git push

Then you see it, staring back from the GitHub UI: your live API key. 💀

We've all been there. Here's the calm, correct order of operations — from "quick save" for a mistake you caught instantly, to the deep clean for a secret that's been buried in history for months.

Step 0: Rotate the secret first (yes, before anything else)

This is the step people skip, and it's the only one that's non-negotiable. The moment a secret hits a remote, assume it's compromised. Bots scrape public GitHub for credentials within seconds.

So before you touch history:

Revoke / rotate the leaked key, token, or password at its source (AWS, Stripe, your DB, wherever).
Then clean the repo.

Cleaning history without rotating is like changing the locks after posting the old key online. Rotate first, always.

Case 1: You caught it before pushing (the quick save)

If the secret is only in your last, un-pushed commit, this is trivial:

# Stop tracking the file and ignore it going forward
git rm --cached .env
echo ".env" >> .gitignore

# Fold the fix into the last commit
git commit --amend --no-edit

Done. Nothing left the building. (Still rotate the key if it was ever real.)

Case 2: It's deep in history, or already pushed (the deep clean)

Once the secret is several commits back — or on the remote — you need to rewrite history. The modern, recommended tool is git filter-repo (Git's own docs now steer you here instead of the old filter-branch).

# Install (Python)
pip install git-filter-repo

# Option A: remove a whole file from ALL history
git filter-repo --path config/secrets.yml --invert-paths

# Option B: redact a specific string everywhere it appears
echo 'AKIAIOSFODNN7EXAMPLE==>REDACTED' > replacements.txt
git filter-repo --replace-text replacements.txt

Prefer BFG Repo-Cleaner if you like a faster, simpler tool for the common cases:

bfg --delete-files id_rsa
bfg --replace-text passwords.txt

# Expire the old refs and garbage-collect
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Then: force-push and warn your team

History rewriting changes commit hashes, so you must overwrite the remote:

git push --force

⚠️ This rewrites shared history. Tell every collaborator to re-clone or hard-reset — if someone merges an old local branch, the secret comes right back. And remember: on GitHub, the old commit can still be reachable via its hash / cached views for a while, which is exactly why Step 0 (rotation) is what actually protects you.

Prevention: never live on the edge again

.gitignore first. Add .env, *.pem, secrets.* before the first commit.
Environment variables / a secret manager (Azure Key Vault, AWS Secrets Manager, Doppler) — secrets never touch the repo.
A pre-commit scanner so a secret is blocked before it's committed:

# gitleaks catches secrets in staged changes
brew install gitleaks
gitleaks protect --staged

Wire that into a pre-commit hook and the "cold sweat" moment mostly disappears.

TL;DR

Rotate the secret (non-negotiable, do it first).
Un-pushed? git commit --amend.
In history? git filter-repo or BFG, then git push --force.
Tell your team to re-clone.
Add a pre-commit scanner so it never happens again.

How do you handle secrets in your workflow — pre-commit hooks, or living life on the edge? 👇

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

System Design: The 6 Core Load Balancing Algorithms, Explained

Karam Khoury — Fri, 24 Jul 2026 11:58:19 +0000

Stop guessing how your traffic scales — understand the routing mechanics. Here's how the six core algorithms actually dictate traffic distribution, and when to reach for each.

1. Round Robin

Distributes requests sequentially across the server pool.

Example: Dealing a deck of cards — Server A gets request 1, Server B gets 2, Server C gets 3, then the cycle repeats. Best for identical, stateless servers.

2. Weighted Round Robin

Sequential routing that accounts for unequal hardware.

Example: Server A has 64 GB RAM, Server B has 32 GB. Assign weight 2 to A and 1 to B, and A receives exactly twice as many requests.

3. Least Connections

Routes traffic to the server with the fewest active, open sessions.

Example: Joining the supermarket checkout with the fewest people. Ideal for long-lived connections — WebSockets, heavy database queries.

4. IP Hash

Uses a hash of the client's IP to guarantee the same client hits the same server every time.

Example: A user at 192.168.1.50 is always routed to Server C. Mandatory for legacy stateful apps that store session data in-memory rather than a distributed cache.

5. Least Response Time

A hybrid: lowest number of active connections combined with the lowest average response time.

Example: Joining the line that has both the fewest people and the fastest cashier. Essential when server performance degrades unpredictably.

6. Adaptive (Resource-Based)

Routes based on real-time hardware telemetry from an agent on each server.

Example: The load balancer queries CPU, memory, and I/O wait in real time, and avoids any server spiking above 80% utilization.

Takeaway

Choose your algorithm based on your infrastructure and state management — not trends. Build systems that scale predictably.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure), building secure, scalable fintech systems. More at karamkhoury.me.