DEV Community: Karam Khoury

Give Your .NET REST API an AI Mouth: Adding MCP So Claude and Gemini Can Actually Use It

Karam Khoury — Wed, 02 Sep 2026 10:18:11 +0000

A production engineer's guide to wrapping an existing ASP.NET Core API with the Model Context Protocol — without tearing out your JWT stack.

Last quarter a product manager dropped a Slack message that a lot of us are getting now: "Can I just ask Claude to pull the open invoices from our system?"

We already had the API. Fully built, JWT-secured, battle-tested in production. The problem was never the data — it was that an LLM has no idea our /api/invoices?status=open endpoint exists, and even if it did, it can't read our OpenAPI spec and authenticate itself.

The Model Context Protocol (MCP) is the missing adapter. This is how you bolt it onto an API you already own, in an afternoon, and what to do about authentication before security reviews it.

The Core Concept: MCP Is an Adapter, Not a Rewrite

MCP is an open protocol that lets AI clients (Claude Desktop, Gemini, Cursor, and others) discover and call your capabilities as "tools." You do not rewrite your API. You stand up a thin MCP server that exposes selected endpoints as tools and forwards the calls.

   AI Chat (Claude / Gemini)
            │   MCP protocol (JSON-RPC)
            ▼
   ┌──────────────────────┐
   │   MCP Server (.NET)  │  ← [McpServerTool] methods
   │   - GetOpenInvoices  │
   │   - CreateTicket     │
   └─────────┬────────────┘
             │   HttpClient + Bearer/API key
             ▼
   ┌──────────────────────┐
   │  Existing REST API   │  ← unchanged, still JWT-secured
   └──────────────────────┘

The MCP server is a translator: it speaks JSON-RPC to the model and plain HTTP to your existing API. Your business logic never moves.

Step 1: Stand Up the MCP Server

Use the official C# SDK (maintained together with Microsoft). Add it to a new minimal ASP.NET Core project so you can host a remote MCP server over Streamable HTTP:

dotnet add package ModelContextProtocol.AspNetCore

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddMcpServer()
    .WithHttpTransport()          // Streamable HTTP for remote clients
    .WithToolsFromAssembly();     // discover [McpServerTool] methods

// Typed client to your EXISTING API
builder.Services.AddHttpClient("BackendApi", static client =>
{
    client.BaseAddress = new Uri("https://api.internal.t1tech.com/");
});

WebApplication app = builder.Build();
app.MapMcp();                     // exposes the /mcp endpoint
app.Run();

That is the entire host. MapMcp() wires up discovery, so any compliant AI client can enumerate your tools.

Step 2: Turn an Endpoint Into a Tool

A tool is just a method. The attributes and XML-style descriptions are not decoration — the model reads them to decide when and how to call you. Be explicit; vague descriptions cause hallucinated arguments.

[McpServerToolType]
public sealed class InvoiceTools
{
    private readonly IHttpClientFactory _httpClientFactory;

    public InvoiceTools(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [McpServerTool]
    [Description("Returns open (unpaid) invoices for a given customer ID.")]
    public async Task<string> GetOpenInvoices(
        [Description("The numeric customer identifier.")] int customerId,
        CancellationToken cancellationToken)
    {
        HttpClient client = _httpClientFactory.CreateClient("BackendApi");

        HttpResponseMessage response = await client.GetAsync(
            $"api/invoices?customerId={customerId}&status=open",
            cancellationToken);

        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync(cancellationToken);
    }
}

Notice there is no token in that call yet. That is the entire fight, and the next two sections are where production engineering actually happens.

Step 3: The JWT Question — Whose Identity Is Calling?

Your API trusts a JWT. The naive instinct is to bake a service account token into the MCP server. Do not. That collapses every user into one identity and hands the LLM god-mode over your data.

The correct model: the MCP server is an OAuth 2.1 Resource Server. The AI client authenticates the human, receives a token, and passes it through. The MCP Authorization spec standardizes this with Protected Resource Metadata (RFC 9728), so the client can discover where to log in.

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(static options =>
    {
        options.Authority = "https://login.t1tech.com/";
        options.Audience = "mcp-invoice-server";
    });

builder.Services.AddAuthorization();

// ...after Build()
app.UseAuthentication();
app.UseAuthorization();
app.MapMcp().RequireAuthorization();

Then forward the caller's identity instead of a hardcoded secret. Grab the incoming token from HttpContext and attach it downstream:

public InvoiceTools(
    IHttpClientFactory httpClientFactory,
    IHttpContextAccessor httpContextAccessor)
{
    _httpClientFactory = httpClientFactory;
    _httpContextAccessor = httpContextAccessor;
}

private async Task<HttpClient> CreateAuthorizedClientAsync(CancellationToken ct)
{
    HttpClient client = _httpClientFactory.CreateClient("BackendApi");

    string? token = await _httpContextAccessor.HttpContext!
        .GetTokenAsync("access_token");

    if (!string.IsNullOrEmpty(token))
    {
        client.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", token);
    }

    return client;
}

Now the existing API sees the real user's scopes and roles. Your authorization rules keep working, untouched. The LLM cannot read an invoice the human behind it could not read.

Step 4: Do You Need an API Key Instead? Pick By Client Type

JWT/OAuth is right for interactive chat where a human is present. But not every MCP consumer is a person clicking "Authorize." Choose the scheme by who connects:

Remote HTTP server, human in a chat client → OAuth 2.1 with JWT pass-through. This is the spec's blessed path. Full user identity, scoped access, revocable.
Local stdio server or machine-to-machine automation → API key. When there is no interactive login (a scheduled agent, a local dev tool), issue a scoped API key and read it from configuration, never from source.

// API key path — for non-interactive / stdio clients
string apiKey = builder.Configuration["Backend:ApiKey"]
    ?? throw new InvalidOperationException("Missing Backend:ApiKey.");

client.DefaultRequestHeaders.Add("X-Api-Key", apiKey);

My recommendation for a team shipping this: default to OAuth 2.1 JWT pass-through for anything remote, and reserve API keys for headless integrations where you can mint narrowly scoped, per-integration keys and rotate them. Treat a static API key like a password — short TTL, per-client, logged, revocable. Never a single shared secret with full API surface.

The Flow: What Actually Happens When Claude Uses Your Tool

Code is abstract until you watch a real request move through it. Here is the end-to-end round trip when a user types "Show me the open invoices for customer 4821" into Claude.

But first — the question everyone asks: where does Claude get that JWT? It is not magic and Claude does not "have your token." The MCP client obtains it through a standard OAuth 2.1 handshake the first time it connects, and this is worth seeing on its own.

[0a] Claude → MCP Server:  first call, no token
     ← 401 Unauthorized
       WWW-Authenticate: Bearer resource_metadata="https://mcp.t1tech.com/.well-known/..."

[0b] Claude reads Protected Resource Metadata (RFC 9728)
     → learns which Authorization Server (your IdP) issues tokens

[0c] Claude runs OAuth 2.1 Authorization Code + PKCE:
     → opens a browser window
     → USER logs in at login.t1tech.com and clicks "Allow"
     → IdP redirects back with an auth code
     → Claude exchanges code → access_token (JWT) + refresh_token

[0d] Claude securely stores the token and reuses it.
     Refresh happens silently; the login prompt does NOT repeat each message.

The critical point: the human authenticates directly with your identity provider, not with Claude. Claude never sees a password. It receives a scoped, expiring JWT through the same OAuth flow your web frontend would use — and your MCP server, as the Resource Server, advertises where that login lives via the 401 challenge in Step 0a.

On the .NET side, RequireAuthorization() already returns the 401. The one extra thing you owe the client is the discovery pointer in Step 0b — register the MCP server as a protected resource so the SDK emits the resource_metadata challenge and serves the metadata document:

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMcp(static options =>
    {
        // Advertises this server as an OAuth 2.1 Resource Server
        options.ResourceMetadata = new ProtectedResourceMetadata
        {
            AuthorizationServers = { new Uri("https://login.t1tech.com/") }
        };
    });

That single registration is what turns "Claude somehow has a token" into a discoverable, spec-compliant login the client can drive on its own.

Only after that handshake does the everyday request loop below run:

[1] USER  →  Claude Chat
    "Show me the open invoices for customer 4821."

[2] Claude → MCP Server:  discovery (once, on connect)
    "What tools do you have?"
    ← [{ name: "GetOpenInvoices",
         description: "Returns open (unpaid) invoices for a customer ID.",
         params: { customerId: int } }]

[3] Claude reasons:
    intent = list open invoices  →  tool = GetOpenInvoices
    extracts argument  →  customerId = 4821

[4] Claude → MCP Server:  tools/call (JSON-RPC)
    Authorization: Bearer <the signed-in user's JWT>
    { "name": "GetOpenInvoices", "arguments": { "customerId": 4821 } }

[5] MCP Server validates the JWT, then forwards downstream:
    GET /api/invoices?customerId=4821&status=open
    Authorization: Bearer <same JWT — user identity preserved>

[6] Existing REST API applies the user's scopes → returns JSON

[7] MCP Server → Claude:  tool result (raw JSON)
    [{ "id": 5567, "amount": 1200.00, "due": "2026-09-15" }, ...]

[8] Claude → USER:
    "Customer 4821 has 2 open invoices totaling $2,050 —
     one due Sep 15 ($1,200) and one due Oct 2 ($850)."

Two things are worth pausing on.

Step 2 happens once, not per message. The client caches your tool catalog on connect. This is why the [Description] text is load-bearing — the model chooses tools purely from it, long before your code ever runs.

Step 4 to Step 6 is the whole security story. The JWT the human logged in with is the same JWT that reaches your API. Claude never sees a service credential, and it can never retrieve an invoice the signed-in user isn't authorized to see. The model orchestrates; your API still decides.

If you want to see this concretely, the tool result at Step 7 is exactly the string your GetOpenInvoices method returned — Claude does the natural-language summarization in Step 8. You return data; the model handles the prose.

Practical Impact

The payoff is not "AI hype." It is that a capability you already built becomes usable by a new class of client with near-zero duplication.

Your team writes one thin tool method per endpoint you want to expose — not a second API. Because identity flows through, your security posture is unchanged: the same JWT, the same scopes, the same audit trail. And because tools are just decorated C# methods, they unit-test like any other service, and new endpoints become new tools in minutes.

The long-term maintainability win is that MCP is a stable seam. When you swap Claude for Gemini, or add a third client, nothing changes on your side. You built the adapter once.

Actionable Takeaways

Wrap, don't rewrite. Stand up a separate MCP server that forwards to your existing API over HttpClient. Business logic stays put.
Write ruthless tool descriptions. The model chooses tools from your [Description] text. Vague text produces bad calls.
Pass the user's identity through — never hardcode a service token. Make the MCP server an OAuth 2.1 Resource Server and forward the caller's JWT so existing authorization still applies.
Choose auth by client type. OAuth 2.1/JWT for interactive remote clients; scoped, rotatable API keys only for headless stdio or M2M integrations.
Ship the smallest surface first. Expose read-only tools before write tools, and let least-privilege scopes gate everything the LLM can reach.

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.