DEV Community: Nilesh Vishwakarma

Why MCP Matters: Understanding Model Context Protocol and Building Your First MCP Server in .NET

Nilesh Vishwakarma — Mon, 19 Oct 2026 19:20:33 +0000

AI models can understand our questions, but connecting them to real applications is a different challenge. Here's where MCP fits in.

AI assistants are useful when we want to explain a concept, summarize something, or work through a problem. But the moment we ask about data inside our own applications, things get more complicated.

Imagine asking an AI assistant: “What is the current status of order 102?”

The model understands the question. What it doesn't have is access to our order system. Somewhere, we need an integration that knows how to retrieve the answer.

We could build that integration ourselves, using an API and a bit of custom code. That works well for one application. The challenge grows when several AI tools need to work with the same systems. This is the problem Model Context Protocol (MCP) is intended to address.

So, what is MCP?

MCP is an open protocol that provides a standard way for AI applications to communicate with external tools and data sources.

It doesn't turn a database into an AI system. It doesn't replace an API. And it doesn't decide what the model should say.

Instead, MCP defines how an application can discover available capabilities, call them, and receive their results.

An MCP server can expose three common kinds of capabilities:

Tools are operations a client can invoke, like looking up an order or searching an issue tracker.
Resources provide data a client can read, such as documentation or configuration.
Prompts provide reusable templates for particular interactions.

For a first project, tools are the easiest place to start.

Figure 1. MCP server capabilities at a glance. The examples are illustrative.

Why not just use a REST API?

You absolutely can. In fact, many useful MCP servers call existing REST APIs internally.

The difference is who is consuming the interface and how they discover it. An ordinary API usually expects a developer to know its endpoints, authentication rules, and request formats. MCP provides a common way for compatible AI applications to discover the tools explicitly exposed by an MCP server and their input schemas.

Think of an order service. It might already expose GET /orders/{id}. We don't need to rewrite it. We can place an MCP server in front of the existing service and expose a tool such as GetOrderStatus.

The application still owns its business rules and security checks. MCP only provides another interface to selected operations.

That is why comparing MCP and REST as if one must replace the other misses the point. They often work together.

Figure 2. Conceptual comparison: applications can reuse one MCP server rather than implementing separate adapters. MCP clients remain within their host applications.

What happens when an AI application uses MCP?

There are three parts worth understanding:

The host is the AI application the user interacts with.
An MCP client runs as part of that host and communicates with an MCP server.
The MCP server exposes tools or other capabilities, and can call services behind the scenes.

A typical request can follow this flow:

Figure 3. Conceptual request flow. Host decisions and permissions depend on the application; arrows show relevant interactions, not every protocol message.

This is a conceptual flow, not a complete protocol sequence. The host may choose to invoke a tool depending on the user's request, available permissions, and its configuration. The MCP server returns data; the host uses it to prepare an answer.

The MCP server itself does not need an AI model.

Let's build a small MCP server in .NET

Rather than starting with a database, let's expose a tiny order-status tool using fixed demo data. Once that works, the same structure can call a real service.

This example uses the .NET 10 SDK and the official MCP C# SDK.

Create a console project and install the packages:

dotnet new console -n OrdersMcp -f net10.0
cd OrdersMcp

dotnet add package ModelContextProtocol
dotnet add package Microsoft.Extensions.Hosting

Replace Program.cs with:

using System.ComponentModel;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;

var builder = Host.CreateApplicationBuilder(args);

// Standard output is used for MCP messages.
builder.Logging.AddConsole(options =>
    options.LogToStandardErrorThreshold = LogLevel.Trace);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class OrderTools
{
    [McpServerTool]
    [Description("Gets the status of an order in the demo data.")]
    public static string GetOrderStatus(int orderId) =>
        orderId switch
        {
            101 => "Processing",
            102 => "Shipped",
            _ => "Order not found in demo data"
        };
}

A few lines do most of the work:

AddMcpServer() registers the MCP server. WithStdioServerTransport() allows a local MCP client to communicate with the process through standard input and output. WithToolsFromAssembly() discovers our annotated tool.

The two attributes on OrderTools and GetOrderStatus tell the SDK which method should be exposed. The method accepts an order ID and returns a string. The values are hard-coded for learning purposes; this is not connected to a real order database.

Build the project:

dotnet build -c Release

How can we test it?

The MCP Inspector is a testing tool that can connect to MCP servers, list available tools, and invoke them directly. You don't need to connect an AI model just to check whether the server works.

Install a supported Node.js version (the current Inspector v2 documentation specifies Node.js 22.19 or later), then run:

npx @modelcontextprotocol/inspector dotnet /absolute/path/to/OrdersMcp/bin/Release/net10.0/OrdersMcp.dll

Replace the path with your compiled DLL's location. Open the local address printed by Inspector, connect, and look for GetOrderStatus under the available tools.

Try 102 as the order ID. The demo tool should return Shipped.

That's the important milestone: a separate client can discover and call a tool written in C# through MCP.

To use it in an AI assistant, you then configure an MCP-compatible host to launch or connect to your server. The exact configuration file and approval behavior vary between hosts.

What changes in a real application?

Very little about the basic idea. Instead of returning a value from a switch expression, the tool could call an existing order service.

For example, the responsibilities might look like this:

The MCP tool accepts an order ID and invokes the application service.
The service checks permissions, applies business rules, and queries the system of record.
The tool returns a limited, useful result to the client.

One mistake to avoid is putting all business logic directly into MCP tool methods. If you already have well-designed services, reuse them. That keeps your application usable by web clients, background jobs, and other integrations without depending on MCP.

Security matters too. A tool that only reads an order status is very different from one that cancels orders or issues refunds. Validate inputs, enforce authorization in the underlying application, restrict exposed operations, and consider explicit user approval for sensitive actions. Connecting an AI application should not bypass any existing security boundary.

When should you use MCP, and when shouldn't you?

MCP is a good fit when multiple compatible AI applications need access to the same tools, or when you want a consistent way to expose carefully selected operations from an existing system.

It may be unnecessary when you're writing a regular backend service, building a conventional web or mobile API, or adding one simple function to an AI application you fully control. Direct function calling or an ordinary API might be easier to build and maintain in those cases.

And MCP is not a performance feature. A call still has to reach the underlying service, which has its own latency, failures, permissions, and dependencies. The protocol standardizes the integration boundary; it doesn't remove the engineering work behind it.

Final thoughts

The most useful way to look at MCP is as a bridge between AI applications and capabilities we already have.

You don't need to replace your APIs or redesign your system to try it. Start with one small, read-only tool. Confirm that a client can discover it and call it. Then, if there's a real use case, connect that tool to an existing application service.

Once you understand that flow, MCP becomes much less mysterious. It is not the intelligence behind the assistant. It is one of the ways the assistant can interact with the systems that hold the information it needs.

References

[Boost]

Nilesh Vishwakarma — Fri, 09 Oct 2026 05:54:04 +0000

Nilesh Vishwakarma

Oct 8

Microfrontends + Microservices: How the Architecture Works, Why It Matters, and How Each Part Deploys on Its Own

#microfrontends #microservices #architecture #webdev

11 min read

Microfrontends + Microservices: How the Architecture Works, Why It Matters, and How Each Part Deploys on Its Own

Nilesh Vishwakarma — Thu, 08 Oct 2026 19:57:30 +0000

The whole system on one page. Keep it open; we'll walk through every box.

Picture a typical web shop. One team owns the product catalog, another owns orders, a third owns user profiles. In the beginning, everyone works in one frontend and one backend. It's simple, and that's fine.

Then the company grows. Ten developers become fifty. Every release needs everyone to agree. A small bug on the profile page blocks the orders team from shipping. A routine library upgrade turns into a three-week, all-hands project.

This is the problem microfrontends and microservices solve: each team builds, tests and deploys its own part of the product, on its own schedule, while users still see one seamless application.

In this article we'll look at an architecture that does exactly that: how it works, why each piece exists, and above all how deployment works. The headline is this: when one part of the UI changes, you deploy only that part, and the main application doesn't need to be touched at all.

A complete, runnable example is on GitHub: github.com/it-nilesh/slice-platform-starter (React + Module Federation on the frontend, .NET 10 microservices on the backend, NGINX in front).

it-nilesh / slice-platform-starter

Production-shaped scaffolding for microfrontends + .NET 10 microservices behind an NGINX gateway: runtime Module Federation, a slice CLI, and independent CI/CD per slice.

MicroFrontend PoC

A small, production-shaped proof of concept for microfrontends + microservices behind a single NGINX gateway, packaged as a framework:

Manifest-driven dynamic remotes: adding a microfrontend never requires rebuilding or redeploying the shell.
Vertical slices (one API + one MFE + one pipeline per team), generated and managed by the ./slice CLI.
Independent CI/CD per slice: test, scan, sign and push only what changed; release each slice with its own tags.
Frontend: React 19 + Vite 8 + Module Federation (@module-federation/vite + @module-federation/runtime), TypeScript
Backend: .NET 10 Minimal APIs, one service per business capability
Gateway: NGINX, the only public entry point

Architecture

The diagram above shows the moving parts. In text form:

                          Browser  (http://localhost:8080)
                                 │
                 ┌───────────────▼────────────────┐
                 │        gateway (NGINX)         │  allowlist (deny by default), rate limiting
                 │  /config/mfe-manifest.json     │  security headers + CSP, request-id, JSON logs
                 └──┬──────────────┬───────────┬──┘
       /  (host)    │  /mfe/<name>/│           │ /api/<name>/

…

View on GitHub

When do you need this architecture?

Let's answer the most important question first, because the honest answer is: most applications don't.

Microfrontends and microservices solve an organizational problem, not a technical one. They're worth it when:

Several teams work on the same product, and each owns a clear business area (catalog, orders, payments, profile…).
Teams need to release independently, several times a week, without coordinating a "big release day" with everyone else.
One area's problems must not block or break the others.
Parts of the product change at very different speeds. A checkout page might change daily while the profile page changes once a quarter.

They're probably not worth it when:

You're one or two teams. A well-structured modular monolith (one application with clean internal boundaries) is simpler, faster to build and easier to debug.
The product is small or early-stage, and boundaries between areas are still changing.
You don't yet have basic automation: CI pipelines, containers, monitoring. This architecture multiplies the number of things to deploy, so manual processes don't scale.

The costs are real: more moving parts, network calls that can fail, versions that drift apart, and debugging across several services. Choose this architecture when the cost of teams waiting for each other is higher than the cost of that extra complexity.

The big idea, explained with a shopping mall

Before any technical detail, let's build a mental model. Think of the application as a shopping mall:

The mall building is the shell (also called the host). It has the entrance, the hallways and the signs. It doesn't sell anything itself.
Each shop is a microfrontend: the Catalog shop, the Orders shop, the Profile shop. Each is run by a different owner, who redecorates and restocks it whenever they like.
Each shop's back office and stockroom is a microservice. The Orders shop has its own stockroom (the Orders API) that only it manages.
The security desk at the entrance is the gateway. Every visitor passes through it, and it knows which hallway leads where.
The directory board at the entrance is the manifest. It lists which shops are open today and where to find them.

Now the key insight, and the reason this architecture exists:

When a shop redecorates, the mall building isn't touched.
When a new shop opens, nobody rebuilds the building. Someone adds a line to the directory board.
When a shop closes for repairs, the rest of the mall stays open.

That's exactly how deployment works in this architecture. Keep this picture in mind; everything else follows from it.

Seven terms you need

Microfrontend (MFE): a small, independently deployed UI application that owns one part of the product, such as the Orders page.

Shell (host): the outer application. It draws the header and navigation, and loads the right microfrontend for each page. It contains no business features itself.

Microservice: a small, independently deployed backend that owns one business capability and its data, such as the Orders API.

Gateway: the single entry point for all traffic. Every browser request goes to it, and it forwards each one to the right container.

Manifest: a small configuration file listing which microfrontends exist, where to download them and which page they belong to. The shell reads it at runtime.

Module Federation: the browser technology that lets the shell load a microfrontend's code at runtime, even though the shell was never built with it.

Vertical slice: one business feature end to end (its microfrontend, its microservice and its own pipeline), owned by one team. The example has three: Catalog, Orders and Profile.

The architecture, piece by piece

The gateway: one front door

Every request from the browser goes to a single address: the gateway (NGINX in the example). It routes by a simple naming convention:

/ goes to the shell
/mfe/orders/ goes to the Orders microfrontend
/api/orders/ goes to the Orders API

Why it matters:

One address for everything means the browser never talks to several servers, so there's no cross-origin (CORS) configuration to maintain, and strict browser security rules are easy to apply.
Security in one place: security headers, rate limiting and request size limits are applied once, for every team.
Safe by default: only services on an allowlist are reachable. A new internal service can't become public by accident.

The shell: a frame that knows nothing about its content

The shell draws the frame (header, navigation, error handling) and loads microfrontends into it. The crucial design decision: the shell's code contains no list of microfrontends. It reads them from the manifest every time the app starts:

{
  "schemaVersion": 1,
  "remotes": [
    { "name": "catalog", "entry": "/mfe/catalog/remoteEntry.js", "route": "/catalog", "nav": { "label": "Catalog" } },
    { "name": "orders",  "entry": "/mfe/orders/remoteEntry.js",  "route": "/orders",  "nav": { "label": "Orders" } }
  ]
}

From this file alone, the shell knows which pages exist, which menu items to show and where to download each microfrontend.

Why it matters: many microfrontend tutorials hard-code the list of microfrontends into the shell's build. Then every new microfrontend forces a shell rebuild and redeploy, which quietly brings back the very coupling we were trying to remove. Reading the list at runtime is what makes independent deployment real.

Because the manifest decides which code runs in the browser, the shell also validates every entry. A microfrontend may only be loaded from the same website, under its own folder, so a bad or malicious entry can't point the app at someone else's script.

The microfrontends: independent apps that share a page

Each microfrontend is a normal React application with its own folder, its own build, its own container and its own pipeline. It exposes one component (its page) for the shell to load.

A few rules keep them truly independent:

They never import each other's code. If Catalog imported from Orders, they could no longer be deployed separately.
They communicate through a small, shared contract. When you add a product to the cart in Catalog, it announces a "cart changed" event. The shell (cart badge) and Orders (cart list) listen for it. Nobody knows who else is listening.
Shared libraries are loaded once. React is marked as shared, so the page loads a single copy instead of one per microfrontend.
Each one can run on its own, without the shell, so a team can develop and test its page in isolation.

The Catalog page is one application; the header with the cart badge is another (the shell). The user can't tell.

The microservices: each team owns its backend and its data

Each microfrontend talks to its own API: Catalog to the Catalog API, Orders to the Orders API. Each service owns its data, and no other service touches its database.

When services need each other, they talk directly over the private network, not through the browser. For example, when you place an order, the Orders API asks the Catalog API for the real prices.

Why it matters: this follows a rule every system should follow: the browser sends intent, the server decides facts. The browser says which products and how many; the prices come from the service that owns them. Anything the browser sends can be changed by the user, so nothing important is trusted from it.

All services also share a small common building block for health checks, logging and error responses, so every team gets the same production basics without rebuilding them.

How it works: follow one click

Let's follow what happens when a user opens https://shop.example/orders:

The browser asks the gateway for the page. The gateway forwards it to the shell, which returns a small HTML page and its JavaScript.
The shell reads the manifest. It learns that "Orders lives at /mfe/orders/remoteEntry.js and belongs on /orders", and builds the navigation menu.
The shell loads the Orders microfrontend. It downloads Orders' entry file only now, because the user is on the Orders page. Pages nobody visits are never downloaded.
The Orders microfrontend calls its API. It requests /api/orders, which the gateway forwards to the Orders API.
When the user places an order, the Orders API asks the Catalog API for the real prices, over the private network.

Notice what didn't happen: the shell never needed to know anything about Orders in advance. It learned everything from the manifest, at runtime. That's the property that makes independent deployment possible.

Designed for failure

In a system with many independent parts, something is always being deployed, restarting or briefly down. The architecture makes sure one broken part never takes down the whole page:

Each microfrontend is isolated. If Catalog fails to load, only the Catalog area shows "unavailable". The header, the navigation and every other page keep working.
Loading has a timeout, so a slow server never means an endless spinner.
"Try again" recovers without reloading the whole page once the service is back.
The gateway returns a clear "service unavailable" for a slice that's down, instead of a confusing error.

The Catalog container is stopped. Only its area shows an error; navigation and the other pages still work.

Deployment: ship only what changed

This is where the architecture pays off. Let's start with the headline.

Changing a microfrontend? Deploy only that microfrontend

Say the Orders team redesigns the order history table. Here's the entire deployment:

The Orders team merges its change.
Only the Orders pipeline runs. It builds, tests and publishes a new mfe-orders image.
Only the mfe-orders container is replaced.
Users get the new Orders page on their next page load.

What wasn't touched:

The shell: not rebuilt, not redeployed, not restarted.
Catalog and Profile: not rebuilt, not redeployed.
The gateway: not changed.
The manifest: not changed. Orders still lives at the same address.

No other team had to be asked, wait, or re-test anything.

Why the shell never needs updating

Three design choices make this work:

1. The shell loads microfrontends at runtime, not at build time. The shell's build contains no microfrontend code at all. It downloads each one in the browser, from the address in the manifest. A new Orders version is simply what that address returns now.

2. A stable entry file plus versioned content files. Each microfrontend has one small entry file with a fixed name, remoteEntry.js. The browser is told to always check it for updates. That file points to the real code, whose file names include a unique version fingerprint (like App-3f9a1c.js), so those can be cached forever. After a deploy, the entry file points to new fingerprinted files, and every browser picks them up on its next load.

3. A contract instead of shared code. The shell and the microfrontends agree only on a small, stable contract: "expose a page component", "announce cart changes with this event". As long as a new version keeps that contract, the shell doesn't care what changed inside.

Every kind of change, and what it costs to ship

Change a microfrontend's UI: deploy that one microfrontend. Shell untouched.
Change a microservice: deploy that one service. Shell and microfrontends untouched.
Add a brand-new microfrontend: deploy its containers, then add one entry to the manifest and one line to the gateway's allowlist. Shell untouched: it discovers the new page on the next load.
Turn off a broken microfrontend: set "enabled": false in the manifest. It disappears from the app on the next page load, with no deployment at all.
Change the shell itself (for example the header design): deploy the shell. This is the only case that touches it, and it's rare, because the shell contains no business features.

A fourth microfrontend, "Inventory", added by deploying it and adding one manifest entry. The shell was never rebuilt or restarted.

Independent pipelines

Independent deployment only works if the pipelines are independent too. Each slice has its own CI/CD pipeline that runs only when that slice's files change:

A change in the Orders microfrontend builds and publishes only the Orders microfrontend image.
A change in the Orders API builds and publishes only the Orders API image.
A release tag like orders-v1.4.0 releases only the Orders slice.

Every pipeline produces versioned, immutable images (for example mfe-orders:sha-4e7fae5 or mfe-orders:1.4.0). "Immutable" means a tag always refers to exactly the same code, which makes every deployment predictable and every rollback trivial.

Where it runs

The deployment unit is always one container. That fits any modern platform:

A single server with Docker Compose: replace one service at a time (docker compose up -d --no-deps mfe-orders) while everything else keeps running.
Kubernetes: each container becomes its own Deployment and Service, and the manifest and allowlist become configuration (ConfigMaps), so changing them never requires a new image.
GitOps (Argo CD or Flux): a separate repository records which version runs in each environment. Deploying or promoting a slice becomes a small, reviewed pull request that changes one version number.

Deploying safely

A few habits keep independent deployments safe:

Deploy the API before the UI, and keep API changes backward compatible (add fields, don't remove them). For a short time, old and new versions run side by side, so each must work with the other.
Treat the shared contract like a public API: only ever add to it.
Roll back by redeploying the previous version tag. Because tags are immutable, you know exactly what you're getting back.
Use the kill switch when you need a broken page gone now: hide it in the manifest, then fix it calmly.

Why this matters

Put together, this architecture changes how a growing organization works:

Teams move at their own speed. The Orders team can ship five times today without asking anyone.
Releases get smaller and safer. Deploying one small piece is less risky than deploying everything, and easier to roll back.
Failures stay contained, both at runtime (one broken page) and at deploy time (one bad release).
New features don't require touching the core. Adding a whole new area of the product is a deployment plus a configuration change.
Ownership is clear. Each team owns its slice end to end, from the database to the screen to the pipeline.

The price is more moving parts. That's exactly why it pays off for many teams working on one product, and why a single small team is usually better served by a modular monolith.

Wrapping up

The whole architecture comes down to one idea, the shopping mall: the shell is the building, not a shop. It provides the entrance, the hallways and the directory board, but it knows nothing about what each shop sells. Because of that:

A shop can redecorate (deploy a new microfrontend version) without touching the building.
A new shop can open by adding a line to the directory board (the manifest).
A shop can close for repairs (fail, or be switched off) while the rest of the mall stays open.

If your teams keep waiting on each other to release, this is the architecture to reach for.

The complete, runnable example is on GitHub: github.com/it-nilesh/slice-platform-starter. Clone it, run docker compose up -d --build, open the app, then change one microfrontend and redeploy just that one. Watching the shell stay untouched is the best way to make the idea click.

If this helped you understand microfrontends, leave a reaction and follow for more architecture deep dives. Questions or a different approach? Drop them in the comments.

Rust Is Becoming the Engine Behind Python’s Modern Tooling

Nilesh Vishwakarma — Mon, 05 Oct 2026 18:36:51 +0000

Why Ruff, uv, Pydantic, Polars, and a growing class of Python tools are choosing Rust — and why the shift matters.

Figure 1 — Conceptual illustration: Python remains the developer-facing layer while Rust increasingly powers performance-sensitive tooling underneath.

The most interesting Rust adoption story may not be happening inside Rust applications.

It may be happening inside Python.

A Python developer today might run:

uv sync
ruff check .
ruff format .
ty check

They might validate API data with Pydantic, process analytical workloads with Polars, or tokenize text using Hugging Face Tokenizers or OpenAI's tiktoken.

From the developer's point of view, this is still a Python workflow.

Underneath it, however, something has changed.

Rust is increasingly doing the heavy lifting.

Ruff is written in Rust. uv is written in Rust. ty is written in Rust. Pydantic moved its core validation engine to Rust. Polars built its core query engine in Rust. Hugging Face Tokenizers uses Rust. OpenAI's tiktoken contains Rust code exposed to Python.

This is not evidence that Rust is replacing Python.

It points to something more useful:

Python is remaining the interface developers want, while Rust is becoming part of the infrastructure underneath it.

That distinction explains why this trend matters.

The Python toolchain is changing

A traditional Python development environment might have combined tools such as:

pip
virtualenv
pip-tools

flake8
isort
Black

mypy

That model still works, and those tools remain important.

But a newer stack can look very different:

                Python project
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
       uv           Ruff          ty
 packages/projects  lint/format  type checking
        │            │            │
        └────────────┼────────────┘
                     │
                    Rust

Ruff combines linting, automatic fixes, import sorting-related functionality, and formatting in one native tool. uv covers package installation, dependency resolution, project management, virtual environments, lock files, tools, scripts, and Python installations. ty brings a Rust implementation into Python type checking and language-server work.

The interesting story is not that all of these tools are written in the same language.

It is that the workloads they perform have similar characteristics: parsing, graph traversal, semantic analysis, caching, dependency resolution, and repeated processing of large codebases.

Those are areas where implementation architecture can materially affect the developer experience.

Ruff showed what a Rust-first Python tool could feel like

Ruff was one of the projects that made many Python developers notice this shift.

A linter looks simple from the outside:

ruff check .

Internally, however, it needs to discover files, parse Python syntax, construct internal representations, evaluate rules, produce diagnostics, and sometimes rewrite source code.

Historically, a repository could run several tools independently:

Python files
    │
    ├──► Flake8
    ├──► isort
    ├──► pyupgrade
    ├──► autoflake
    └──► Black

Ruff approaches much of that work through one implementation.

Python source
      │
      ▼
 ┌───────────┐
 │   Ruff    │
 │           │
 │ Parsing   │
 │ Linting   │
 │ Fixes     │
 │ Formatting│
 └───────────┘
      │
      ▼
Checked source

Astral publishes benchmarks showing large performance advantages for Ruff in the workloads it measures. Those numbers are useful, but they should be read as project benchmarks, not as a guarantee that every repository will see the same improvement.

More importantly, Ruff illustrates a broader engineering lesson.

Rust alone is not the architecture.

The performance story also involves consolidation, shared parsing infrastructure, caching, data structures, and implementation choices.

A badly designed Rust tool can still be slow. A well-designed Python tool can still be fast enough.

The language matters, but it is only one part of the system.

Ruff also has tradeoffs. Its behavior is not identical to every tool it can replace, and it does not reproduce every extension model from older ecosystems such as Flake8's plugin system.

So migration should follow project requirements, not benchmark headlines.

uv moves Rust into the center of Python package management

Package management makes the trend even more visible.

A conventional workflow might involve several separate concepts:

Python installation
       │
       ├── venv / virtualenv
       ├── pip
       ├── pip-tools
       ├── pipx
       └── project-specific tooling

With uv, the workflow can become:

uv init
uv add fastapi
uv run main.py

Or, for pip-style workflows:

uv venv
uv pip install fastapi

The important detail is that uv pip is not simply a thin wrapper that invokes pip underneath. uv implements its own package-management machinery while providing a familiar interface for many pip-style operations.

That means a Rust program is now handling work such as:

             uv
              │
   ┌──────────┼──────────┐
   │          │          │
   ▼          ▼          ▼
Dependency  Python     Virtual
resolution  versions   environments
   │          │          │
   └──────────┼──────────┘
              ▼
            Project

Again, the attraction is not simply that Rust can execute native code.

uv also consolidates responsibilities that Python developers previously handled through several tools.

That can simplify workflows, but it does not mean uv is an exact behavioral clone of pip. Astral documents compatibility differences, which matter for projects depending on unusual packaging behavior or established enterprise build systems.

A faster tool is valuable only if it is also compatible with the workflow you need.

Pydantic shows the deeper architectural shift

Ruff and uv are standalone tools.

Pydantic demonstrates something more significant for application developers.

Python code still looks like this:

from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int

Nothing about that API looks like Rust.

That is exactly the point.

Pydantic V2 moved core validation and serialization work into pydantic-core, implemented in Rust and exposed to Python.

The conceptual architecture looks like this:

Figure 2 — Conceptual architecture: Python provides the developer experience while Rust handles selected native workloads through a boundary such as PyO3.

The developer keeps the Python interface:

Python classes
type annotations
framework integration
IDE support
the wider Python ecosystem

But the implementation of selected performance-sensitive operations lives in Rust.

This is a much more interesting model than simply "rewriting Python in Rust."

It lets a project change the engine without changing the driver's seat.

Polars applies the same idea to data processing

Polars makes the pattern even clearer.

A Python developer can write:

result = (
    pl.scan_parquet("orders.parquet")
    .filter(pl.col("amount") > 100)
    .group_by("country")
    .agg(pl.col("amount").sum())
    .collect()
)

The interface is Python, but the query engine is implemented in Rust.

Polars also has an architecture that differs meaningfully from pandas. Its lazy API can build a query plan, optimize it, and then execute the resulting work using its engine.

Conceptually:

Python expression
       │
       ▼
Logical query
       │
       ▼
Query optimizer
       │
       ▼
Execution plan
       │
       ▼
Rust engine
       │
       ▼
Data / CPU cores

That distinction matters because it prevents an oversimplified conclusion.

Polars is not merely "pandas rewritten in Rust."

The implementation language changed, but so did important parts of the execution model.

Rust contributes to the design. It does not explain the entire design.

AI developers may already be using Rust without noticing

The same pattern appears in AI infrastructure.

Hugging Face Tokenizers uses a Rust implementation underneath its Python interface. OpenAI's tiktoken also includes Rust code exposed to Python.

From Python, usage remains ordinary:

import tiktoken

encoding = tiktoken.get_encoding("o200k_base")
tokens = encoding.encode("Rust underneath Python")

The Rust boundary is almost invisible.

That invisibility is important.

A successful native layer should not force every Python user to become a systems programmer.

If the package is distributed correctly, the user imports a Python module and works with a Python API. The implementation language becomes an internal engineering decision.

PyO3 and maturin made the hybrid model practical

Python has depended on native code for decades.

NumPy, SciPy, cryptographic libraries, database drivers, ML frameworks, and CPython itself have long depended on C, C++, Fortran, or other compiled languages.

So the new idea is not "Python can call native code."

The newer story is that the Rust-to-Python development path has become much more practical.

PyO3 provides Rust bindings for Python and allows Rust functions and types to be exposed as Python modules.

Conceptually:

Python code
    │
    ▼
   PyO3
    │
    ▼
Rust implementation

Then maturin helps build and package Rust-backed Python projects into Python wheels.

That gives maintainers a workflow resembling:

Rust source
    │
    ▼
   PyO3
    │
    ▼
 maturin
    │
    ▼
Python wheel
    │
    ▼
pip / uv install

When a compatible prebuilt wheel exists, the end user often does not need Rust installed at all.

That changes the economics of using Rust inside Python libraries.

The Rust-powered Python ecosystem is broader than one vendor

The trend is easy to associate with Astral because Ruff, uv, and ty are highly visible.

But the broader ecosystem shows that the pattern is not limited to one company or one product category.

Figure 3 — Selected examples of Rust-powered developer tools, performance libraries, and Python/Rust integration infrastructure. This is illustrative, not exhaustive.

A useful way to group the projects is:

Area	Examples	Rust's role
Developer tooling	Ruff, uv, ty	Native CLI, parsing, resolution, analysis
Validation	Pydantic Core	Validation and serialization engine
Data processing	Polars	Query and execution engine
Serialization	orjson	Native JSON implementation
NLP / AI	Tokenizers, tiktoken	Tokenization and text processing
Integration	PyO3	Python/Rust bindings
Packaging	maturin	Building and distributing Rust-backed Python packages

This is not every Rust-backed project in Python, and it should not be presented as a complete inventory.

The important point is the pattern across categories.

Why Rust keeps appearing

There are many fast languages, and C already underpins enormous parts of Python.

Why Rust?

Several characteristics line up well with tooling and infrastructure workloads.

Native execution

Rust compiles to native code.

For workloads dominated by parsing, serialization, graph resolution, static analysis, or query execution, avoiding interpreter overhead can be valuable.

But native code does not automatically mean fast software.

Algorithms, memory access patterns, caching, I/O, data structures, allocation behavior, and architecture can matter as much as the language.

Memory safety without a garbage-collected runtime

Compilers, linters, type checkers, and query engines often create large graphs and trees in memory.

Rust provides low-level control together with compile-time memory-safety guarantees, without requiring a garbage-collected runtime.

That can be attractive for systems that need predictable control over large internal representations.

The tradeoff is complexity. Rust's ownership and lifetime model asks more from the programmer than Python does.

Concurrency and parallelism

Some workloads can be divided across CPU cores.

Rust provides strong tooling for concurrent systems while catching many unsafe memory-access patterns at compile time.

That does not make every algorithm parallel, but it can provide a strong foundation when parallelism fits the workload.

Standalone distribution

Rust-based CLI tools can be distributed as native executables or packaged through wheels for supported platforms.

For end users, that can make startup and installation feel simple even though the implementation underneath is native code.

The wrong conclusion: "rewrite everything in Rust"

This is where language discussions often become unhelpful.

Imagine an API request that spends its time like this:

Request
   │
   ▼
Python logic       2 ms
   │
   ▼
Database query    80 ms
   │
   ▼
External API     200 ms
   │
   ▼
Response

Suppose you rewrite the 2 ms of Python logic and reduce it to 0.5 ms.

The total request barely changes.

The correct question is not:

Can Rust run this function faster?

The useful question is:

Is this code actually the bottleneck that matters?

Rust makes the most sense where the workload justifies the additional implementation complexity.

That is why its adoption is so visible in areas such as:

Parsing
Static analysis
Dependency resolution
Validation
Serialization
Tokenization
Query optimization
Data processing

Those are workloads where CPU cost, memory layout, latency, and repeated execution can become visible to users.

For ordinary application code dominated by network calls, databases, or external services, a rewrite may offer little practical benefit.

Measure first.

Change second.

Python and Rust are becoming complementary

The most useful lesson is not "Rust versus Python."

It is that a system does not need to use one language everywhere.

A practical architecture can look like this:

┌─────────────────────────────────┐
│             Python              │
│                                 │
│  Application logic              │
│  APIs                           │
│  Automation                     │
│  Data workflows                 │
│  Developer-facing interfaces    │
└────────────────┬────────────────┘
                 │
                 │ Native boundary
                 │
┌────────────────▼────────────────┐
│              Rust               │
│                                 │
│  Parsing                        │
│  Validation                     │
│  Dependency resolution          │
│  Static analysis                │
│  Query execution                │
│  Tokenization                   │
│  Performance-sensitive engines  │
└─────────────────────────────────┘

Python stays where its readability, ecosystem, flexibility, and developer experience are valuable.

Rust is introduced where native execution, memory control, or systems-level implementation characteristics provide a measurable benefit.

The boundary between them is what makes the combination powerful.

Should a Python developer learn Rust?

Not simply because Rust is fashionable.

You do not need Rust to use Ruff.

You do not need Rust to use uv.

You do not need Rust to write Pydantic models or use Polars from Python.

That is one of the strengths of the architecture.

But Rust becomes increasingly relevant if you build:

developer tools,
parsers or compilers,
static analyzers,
database or query engines,
serialization libraries,
performance-sensitive Python extensions,
infrastructure that spends substantial CPU time in repeatable native workloads.

Then Rust gives you another option:

Keep the Python interface. Replace only the part that actually needs a different implementation model.

That is much more sensible than rewriting an entire application because one component is slow.

Rust is not replacing Python. It is disappearing underneath it.

That may be the most important part of this trend.

A developer runs:

ruff check .
uv sync
ty check

Another writes:

from pydantic import BaseModel

Another writes:

import polars as pl

Another writes:

import tiktoken

They are still Python developers.

They may not think about Rust at all.

And that may be the strongest sign that the model works.

Rust does not need Python developers to stop writing Python.

It only needs to be useful in the layers where Python benefits from a different implementation model underneath.

That is what Ruff, uv, Pydantic Core, Polars, Tokenizers, PyO3, maturin, and similar projects demonstrate.

So the interesting future is probably not Python or Rust.

It is increasingly Python on top, Rust where it matters underneath.

And for modern Python tooling, that combination may be more important than choosing a winner.

References

Primary or official project documentation used to verify the technical claims in this article:

Ruff documentation: https://docs.astral.sh/ruff/
Ruff formatter: https://docs.astral.sh/ruff/formatter/
Ruff FAQ: https://docs.astral.sh/ruff/faq/
uv documentation: https://docs.astral.sh/uv/
uv pip interface: https://docs.astral.sh/uv/pip/
uv pip compatibility: https://docs.astral.sh/uv/pip/compatibility/
ty documentation: https://docs.astral.sh/ty/
Pydantic V2 architecture/background: https://pydantic.dev/articles/pydantic-v2
Polars user guide: https://docs.pola.rs/user-guide/
Hugging Face Tokenizers: https://huggingface.co/docs/tokenizers/
OpenAI tiktoken repository: https://github.com/openai/tiktoken
PyO3 guide: https://pyo3.rs/
maturin documentation: https://www.maturin.rs/

MCP vs A2A: How AI Agents Connect to Tools — and to Each Other

Nilesh Vishwakarma — Sun, 04 Oct 2026 13:29:24 +0000

The short version: MCP connects an AI app to tools and data. A2A connects one AI agent to another AI agent. They solve different problems, and many systems use both.

Why agents need more than a language model

A chatbot only has to produce text. An agent has to get things done.

To do that, it may need to search a knowledge base, read a file, query a database, create a ticket, or hand part of the job to another agent. A language model cannot do any of that by itself. Something has to connect it to the outside world.

We already have APIs for connecting software, and they are not going away. The trouble is that every API is different. If each AI app writes its own custom integration for GitHub, for the database, and for the ticketing system, the work gets repeated again and again.

MCP and A2A are two open standards that reduce that repeated work. Each one covers a different connection:

MCP  →  AI app    ↔  tools, data, and context
A2A  →  AI agent  ↔  another AI agent

What is MCP?

The Model Context Protocol (MCP) is an open standard that connects AI applications to the systems where data and tools live.

A helpful way to picture it is a USB port. Before USB, every device needed its own cable and its own driver. MCP gives tools one standard plug, so a tool built once can work with any AI app that speaks MCP.

How MCP works. Conceptual diagram; implementations can vary.

There are three parts to know:

Host: the app the user works in, such as an IDE, a desktop AI app, or your own agent.
Client: the piece inside the host that speaks MCP. One host can connect to many servers.
Server: the piece that offers capabilities to the AI app.

An MCP server can offer three kinds of things:

Tools are actions the model can run, such as search_issues or create_ticket.
Resources are content the app can read, such as a file, a document, or a database record.
Prompts are reusable templates, such as "Review this pull request for security problems."

A quick example

A user asks: "Summarize our release status and create an issue for any blocking database problem."

The app reads the project roadmap through an MCP resource.
The model spots a blocking problem.
The app calls the create_issue tool.
The MCP server talks to the real project-management API.
The result goes back to the user.

Notice step 4. The MCP server still calls a normal API behind the scenes. MCP does not replace APIs. It sits in front of them and presents them in a form that AI apps can discover and use.

What is A2A?

Now picture a company with several specialist agents: a support agent, a billing agent, and a travel agent.

A customer writes: "Refund my ticket and find me a replacement flight."

The support agent knows the customer and the refund policy. The travel agent owns rebooking. So the support agent needs to hand over part of the job.

That is different from calling a tool. The other agent does its own reasoning, has its own tools, may ask a question back, and may need minutes or hours to finish.

The Agent2Agent (A2A) Protocol is an open standard for exactly this. If MCP is a USB port, A2A is closer to how colleagues work together: you find out who does what, hand over a job, check on progress, and get the finished work back.

Google started A2A in 2025 and donated it to the Linux Foundation. Version 1.0, the first stable release, shipped in March 2026. Since August 2026 it has been hosted by the Agentic AI Foundation, the Linux Foundation body that also hosts MCP.

How A2A works. Conceptual diagram; implementations can vary.

A2A has four building blocks:

Agent Card: a small JSON file where an agent describes itself, including its name, skills, address, and security requirements. Think of it as a business card that other agents can read.
Message: one turn of conversation between agents. It can carry text, files, or structured data.
Task: a unit of work with its own ID and status. It can be working, waiting for input, completed, or failed, so the client can follow long jobs.
Artifact: the finished output of a task, such as a report, an image, or structured data.

One point matters here. The remote agent keeps its inner workings private. Other agents see what it can do, not how it does it.

MCP vs A2A at a glance

MCP and A2A solve different interoperability problems.

	MCP	A2A
Connects	AI app ↔ tools and data	Agent ↔ agent
Main building blocks	Tools, resources, prompts	Agent Card, messages, tasks, artifacts
Other side is	An MCP server	An independent agent
Typical request	"Search GitHub issues"	"Ask the security agent to investigate this incident"
Long-running work	Possible	Built in through tasks
Replaces REST APIs?	No	No

Neither one is "better." They describe different relationships.

Using both together

Most real systems with more than one agent end up using both.

A user asks a support agent: "Find out why our customer's deployment failed, check whether it affects their SLA, and draft a reply."

A2A handles agent-to-agent collaboration. MCP handles access to tools and context.

The support agent uses MCP to read logs, tickets, and customer data.
It sees that the incident may affect the customer's contract.
It hands that question to a contract agent through A2A.
The contract agent uses its own MCP server to look up the contract.
The contract agent returns its findings as an artifact.
The support agent combines everything and drafts the reply.

The support agent never needs to learn the contract system's API. The contract agent never has to expose its internal tools. Each side has one clear job.

Which one do you need?

Your AI app needs tools or data. Use MCP.
Your agent needs help from another independent agent. Use A2A.
Your agents work together and also need tools. Use both.
You have one simple integration that already works. Use neither. A plain REST API or function call is fine.

That last point is easy to forget. If your app calls a single weather API, adding a protocol only adds complexity. Use MCP or A2A when they save you integration work, not because they are new.

A simple test: ask what sits on the other side. If it mainly offers tools or data, MCP fits. If it is an independent agent that accepts work, A2A fits.

Two things a protocol will not fix

Security. A standard way to call delete_file does not make it safe to call. You still need authentication, permissions, input validation, audit logs, and human approval for risky actions. The MCP team says plainly that tool annotations are hints and not enforcement. A tool that describes itself as read-only may not be.

Quality. MCP standardizes how a tool is called. It cannot promise the tool works correctly. A2A standardizes how agents talk. It cannot promise the other agent is right. An agent that speaks your protocol is not automatically an agent you should trust.

One 2026 change worth knowing

If you read older MCP tutorials, watch out for one thing. The MCP specification released on July 28, 2026 made the protocol stateless.

Older versions began every connection with an initialize handshake and tracked it with a session ID. Both are gone. Every request now carries everything it needs, so any server instance behind a load balancer can answer it.

Your application can still keep state. It just no longer lives inside the protocol session. Many articles from 2025 describe the old behavior, so check which version your SDK supports.

Wrapping up

MCP is how an AI app reaches tools, data, and prompts.
A2A is how one agent hands work to another agent.
They complement each other, and both sit on top of the APIs you already have.
Sometimes the right answer is neither.

Pick the protocol that matches the relationship between your components, not the one getting the most attention this month.

This article reflects the MCP 2026-07-28 specification and A2A 1.0, as of October 2026. Both projects are still evolving, so check the version your tools support.

Sources

Why HTTP/3 Exists: The Limits of HTTP/2 and the Rise of QUIC

Nilesh Vishwakarma — Mon, 28 Sep 2026 19:21:07 +0000

HTTP/2 already gave us multiplexing, binary framing, and better use of a single TCP connection.

So why did we need HTTP/3?

The answer is not really HTTP itself.

The answer is TCP.

HTTP/3 keeps familiar HTTP semantics, but it changes the transport underneath by using QUIC over UDP.

That change affects packet loss, stream independence, connection setup, and network migration.

A simple way to remember the evolution is:

HTTP/1.1 → more connections

HTTP/2 → more streams over one TCP connection

HTTP/3 → more streams over QUIC

HTTP and QUIC Are Not the Same Thing

HTTP defines what the message means.

For example:

GET /products
Host: example.com

HTTP also defines:

methods such as GET, POST, and DELETE
status codes such as 200, 404, and 500
headers
caching rules
request and response behavior

A simple mental model:

HTTP = what the message means
TCP / QUIC = how the message travels

Conceptually:

HTTP/1.1
   ↓
TCP
   ↓
IP

HTTP/2
   ↓
TCP
   ↓
IP

HTTP/3 changes the transport:

HTTP/3
   ↓
QUIC
   ↓
UDP
   ↓
IP

HTTP/3 still uses normal HTTP ideas such as GET, POST, status codes, headers, and caching. The main change is how the data moves across the network.

HTTP/1.1: More Connections for More Work

HTTP/1.1 has been used for a long time and is still important today.

A request might look like this:

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html

Modern websites need more than one file.

A page may need:

HTML
CSS
JavaScript
images
fonts
API responses

The browser wants to download many of these quickly.

A simple analogy

Imagine a supermarket with one checkout line.

If one person has a very large cart, everyone behind that person has to wait.

HTTP/1.1 can reuse connections, and it also defined pipelining, but pipelined responses still have to come back in order.

Request A ───────────────►
Request B ───────────────►
Request C ───────────────►

Response A ◄──────── slow
Response B ◄──────── waiting
Response C ◄──────── waiting

Even if response C is ready, it cannot simply jump ahead of response A in that pipelined sequence.

This waiting problem is one example of head-of-line blocking.

Because of this and other practical limits, browsers have historically used multiple TCP connections to get more concurrency.

HTTP/1.1: use more connections so more work can happen at the same time.

HTTP/2: Many Streams on One TCP Connection

HTTP/2 changed how HTTP data is represented and sent.

Instead of relying mainly on several separate TCP connections, HTTP/2 can place many logical streams inside one TCP connection.

TCP connection
│
├── Stream 1 → HTML
├── Stream 3 → CSS
├── Stream 5 → JavaScript
├── Stream 7 → Image
└── Stream 9 → API response

Think of HTTP/1.1 as using several roads.

HTTP/2 is more like using one large highway with several lanes.

Several requests can move at the same time without opening a new TCP connection for every piece of work.

HTTP/2 also uses binary frames such as:

HEADERS
DATA
SETTINGS
WINDOW_UPDATE
RST_STREAM

These frames belong to different streams and can be mixed together on the same connection.

That was a major improvement.

But one important problem remained.

All those HTTP/2 streams still share one TCP connection.

The TCP Problem in HTTP/2

TCP gives applications reliable and ordered data.

That is useful.

But ordered delivery also means missing data may need to be recovered before later bytes are passed to the application.

Imagine this:

Packet 1  ✓
Packet 2  ✗ lost
Packet 3  ✓
Packet 4  ✓

TCP may need to recover the missing part before later ordered data can be delivered to HTTP/2.

Now remember that several HTTP/2 streams share the same TCP connection:

Stream A ─┐
Stream B ─┼──► TCP
Stream C ─┘

If TCP has to wait for missing data, several HTTP/2 streams can be delayed.

Train analogy

Imagine HTTP/2 streams as passengers sitting in different train compartments.

The passengers are separate, but they are all on the same train.

If the train stops because the track is blocked, every compartment stops too.

That is why HTTP/2 multiplexing does not completely remove TCP-level head-of-line blocking.

HTTP/3: Change the Transport

HTTP/3 keeps the idea of multiple streams, but moves them from TCP to QUIC.

HTTP/3
   ↓
QUIC
   ↓
UDP
   ↓
IP

QUIC is a transport protocol built on UDP.

That does not mean HTTP/3 simply sends unreliable UDP packets and hopes for the best.

QUIC adds transport features HTTP needs, including:

reliable delivery
congestion control
flow control
loss recovery
encryption
multiple streams
connection migration

So this explanation is too simple:

HTTP/3 = HTTP over UDP

A better explanation is:

HTTP/3 runs over QUIC, and QUIC uses UDP as its foundation.

Why QUIC Streams Matter

QUIC allows several streams inside one connection.

QUIC connection

├── Stream A → HTML
├── Stream B → CSS
├── Stream C → JavaScript
└── Stream D → Image

Now imagine Stream B loses some data:

Stream A ─── ✓ ─── ✓ ─── ✓ ───►

Stream B ─── ✓ ─── X ──────────►
                  lost

Stream C ─── ✓ ─── ✓ ─── ✓ ───►

Stream B may need to wait for its missing data.

But Stream A and Stream C do not automatically have to stop and wait for Stream B.

That is one of the most important differences between HTTP/2 over TCP and HTTP/3 over QUIC.

Does HTTP/3 remove all head-of-line blocking?

No.

If data is missing inside one QUIC stream, later data in that same stream may still need to wait.

The important improvement is that one blocked stream does not inherently block unrelated streams in the same way TCP's ordered delivery can affect HTTP/2 streams.

HTTP/2 vs HTTP/3: The Simple Version

HTTP/2:

Stream A ─┐
Stream B ─┼──► One TCP connection
Stream C ─┘

Packet loss in TCP
        ↓
Several streams may wait

HTTP/3:

Stream A ───► QUIC Stream A
Stream B ───► QUIC Stream B
Stream C ───► QUIC Stream C

Loss in Stream B
        ↓
Stream B waits

A and C can still make progress

This is a conceptual explanation. Real packet handling is more complex.

QUIC Also Integrates Security

HTTP/2 normally uses TLS over TCP for secure web traffic.

A simplified view is:

HTTP/2
   ↓
TLS
   ↓
TCP

QUIC was designed together with TLS 1.3.

Conceptually:

HTTP/3
   ↓
QUIC + TLS 1.3
   ↓
UDP

This can reduce some connection setup delay, depending on the network and whether the connection is new or resumed.

It does not mean HTTP/3 is always faster.

What Is 0-RTT?

QUIC can support 0-RTT data in some resumed connections.

Very simply:

First visit:
Client ── handshake ── Server

Later visit:
Client ── early data ──► Server

This can save time in some situations.

But 0-RTT data has replay risks, so applications have to be careful about which operations are allowed to use it.

0-RTT can help some repeat connections start sooner, but it is not used for everything.

Connection Migration: Useful on Mobile Networks

Imagine you are using your phone at home on Wi-Fi.

Then you walk outside and your phone switches to mobile data.

Your network path may change.

QUIC supports connection migration using Connection IDs and path validation.

Wi-Fi
  ↓
QUIC connection
  ↓
Server

Then:

Mobile network
  ↓
Same logical QUIC connection can continue
  ↓
Server

The real process includes security checks and path validation, but the basic idea is simple:

QUIC is designed to handle some network changes without always throwing away the whole connection.

HTTP/1.1 vs HTTP/2 vs HTTP/3

Area	HTTP/1.1	HTTP/2	HTTP/3
Main transport	TCP	TCP	QUIC over UDP
Multiplexing	No HTTP/2-style multiplexing	Yes	Yes
Typical concurrency	Multiple TCP connections	Multiple streams on one TCP connection	Multiple streams on one QUIC connection
Field compression	No HPACK/QPACK	HPACK	QPACK
Secure web traffic	TLS over TCP	TLS over TCP	TLS integrated with QUIC
Connection migration	No QUIC-like native feature	No QUIC-like native feature	Supported by QUIC
Main strength	Compatibility	Mature multiplexing	Better stream independence
Main tradeoff	Limited per-connection concurrency	TCP-level blocking can still matter	More deployment and implementation complexity

Is HTTP/3 Always Faster?

No.

HTTP/3 can have advantages when:

latency is high
packet loss happens
many resources are transferred at once
users move between networks
connection setup time matters

But on a fast and stable network with an already-open HTTP/2 connection, the difference may be small.

Performance also depends on:

browser implementation
server implementation
CDN
congestion control
packet loss
round-trip time
bandwidth
resource size
connection reuse

So it is better to say:

HTTP/3 can perform better in some network conditions, but it is not automatically faster everywhere.

HTTP/3 Has Tradeoffs Too

HTTP/3 solves some problems, but it also adds new ones.

UDP may be blocked

Some networks, firewalls, or middleboxes may block or interfere with UDP.

That means a client may need to fall back to HTTP/2 or HTTP/1.1.

Try HTTP/3
    │
    ├── works → use HTTP/3
    │
    └── fails → use TCP-based HTTP

QUIC is not simple

QUIC still has to handle:

reliability
loss detection
congestion control
flow control
streams
encryption
connection management
path validation

The complexity did not disappear.

It moved into QUIC.

Infrastructure needs support

Servers, CDNs, load balancers, firewalls, and monitoring tools may need proper QUIC support.

So moving to HTTP/3 is not only a browser change.

It can also be an infrastructure decision.

Which Version Is Better?

There is no universal winner.

A better question is:

Which version fits the situation?

HTTP/1.1

Useful when:

compatibility matters most
older systems are involved
traffic is simple
infrastructure is intentionally basic

HTTP/2

Useful when:

HTTP/2 support is already mature
you want multiplexing
your TCP-based infrastructure already works well
adding QUIC would add unnecessary complexity

HTTP/3

Useful when:

users are often on mobile networks
latency is important
packet loss is common
many resources are transferred at once
users may switch between Wi-Fi and mobile data
the infrastructure already supports QUIC well

The version number alone should not decide the choice.

The Evolution in One Diagram

HTTP/1.1
More connections for concurrency

        ↓

HTTP/2
More streams on one TCP connection

        ↓

HTTP/3
More streams on a transport designed
to keep them more independent

Or, using a road analogy:

HTTP/1.1: use more roads
HTTP/2: use one highway with many lanes
HTTP/3: redesign the transport so those lanes are less dependent on each other

TL;DR

HTTP/1.1
More connections

HTTP/2
More streams over TCP

HTTP/3
More streams over QUIC

HTTP/3 is not automatically faster everywhere.

Its main advantage is that QUIC is designed around independent streams, integrated security, connection migration, and a transport model that handles some forms of packet loss better than HTTP/2 over TCP.

That makes HTTP/3 especially useful when latency, packet loss, and mobile connectivity matter.

Final Thoughts

HTTP/3 is not interesting simply because it uses UDP.

The real change is QUIC.

HTTP/1.1 commonly used more connections to get more concurrency.

HTTP/2 put many streams on one TCP connection.

HTTP/3 moved those streams onto a transport designed with stream independence, security, loss recovery, and network changes in mind.

That does not make HTTP/3 magically faster everywhere.

But it gives the web a transport model that can behave better when latency, packet loss, and changing networks matter.

If you remember only one thing, remember this:

HTTP/1.1 opened more connections. HTTP/2 added more streams. HTTP/3 changed the transport underneath those streams.

References

This article is based mainly on the following IETF standards:

If you found this useful, feel free to share your experience with HTTP/2, HTTP/3, or QUIC in the comments.

Introducing Injectlynx: Attribute-Free Compile-Time Dependency Injection for .NET

Nilesh Vishwakarma — Sun, 02 Aug 2026 12:27:35 +0000

Dependency Injection (DI) is one of the foundations of modern .NET development. Whether you're building ASP.NET Core APIs, Minimal APIs, Worker Services, or libraries, you're probably using Microsoft.Extensions.DependencyInjection.

It works well, but as applications grow, one challenge becomes obvious: service registration.

Most teams end up choosing one of two approaches.

The first is manual registration:

services.AddScoped<IOrderService, OrderService>();
services.AddScoped<IPaymentGateway, StripePaymentGateway>();
services.AddTransient<IRequestHandler<GetOrderQuery>, GetOrderQueryHandler>();

This is explicit and easy to understand, but maintaining hundreds of registrations quickly becomes repetitive and error-prone.

The second option is runtime assembly scanning:

services.Scan(scan => ...);

Assembly scanning removes much of the boilerplate, but it relies on runtime discovery and reflection. That can make applications harder to reason about, especially when working with trimming, Native AOT, or large modular solutions.

I wanted something that combined the best parts of both approaches:

No repetitive manual registrations
No attributes on every service class
No runtime assembly scanning
No custom DI container
Full compatibility with Microsoft Dependency Injection

That idea became Injectlynx.

What is Injectlynx?

Injectlynx is an attribute-free, convention-based compile-time dependency injection toolkit for .NET.

Instead of discovering services at runtime, Injectlynx uses a Roslyn Incremental Source Generator to generate normal IServiceCollection registrations during compilation.

The generated code is exactly what you would write by hand.

There is:

✅ No runtime reflection for service discovery
✅ No assembly scanning
✅ No custom DI container
✅ No attributes on every service
✅ No startup performance penalty for service discovery

You continue using the standard Microsoft DI container.

Install it with:

dotnet add package Injectlynx

The Problem with Traditional Registration

Imagine a project with hundreds of services.

You eventually end up with code like this:

services.AddScoped<IOrderService, OrderService>();
services.AddScoped<ICustomerService, CustomerService>();
services.AddScoped<IInvoiceService, InvoiceService>();
services.AddScoped<IProductService, ProductService>();
services.AddScoped<IEmailService, EmailService>();
// ...

Besides being repetitive, this list needs constant maintenance.

Rename a service.

Move a namespace.

Add a new implementation.

It's easy to forget updating the registration.

The Injectlynx Way

Instead of registering every service manually, define your conventions once.

using Injectlynx;

namespace Shop.Application;

public static class ApplicationServiceConventions
{
    public static void Configure(IServiceConventionBuilder services)
    {
        services
            .FromNamespace("Shop.Application.Services")
            .WhereNameEndsWith("Service")
            .AsMatchingInterface()
            .WithScopedLifetime();
    }
}

That's it.

Now create a normal service.

public interface IOrderService
{
    OrderSummary GetOrder(Guid id);
}

public sealed class OrderService : IOrderService
{
    public OrderSummary GetOrder(Guid id)
    {
        return new(id, "Created");
    }
}

During compilation, Injectlynx generates:

services.AddScoped<IOrderService, OrderService>();

No attributes.

No reflection.

No runtime scanning.

Keep Your Service Classes Clean

Many compile-time DI libraries require decorating every implementation.

For example:

[Scoped]
public sealed class OrderService
{
}

Injectlynx deliberately avoids that.

Your business classes stay focused on business logic instead of dependency injection metadata.

Works with Microsoft Dependency Injection

Injectlynx doesn't replace the built-in container.

The generated output is simply standard Microsoft DI code.

Startup remains familiar:

builder.Services.AddInjectlynxServices();

Or, in larger solutions:

builder.Services
    .AddApplicationServices()
    .AddInfrastructureServices();

The registration methods are generated automatically during build.

More Than Just Service Registration

Injectlynx also supports scenarios commonly found in enterprise applications.

Convention-based registration

Open generic registration

Repository<TEntity> : IRepository<TEntity>

Generated automatically as:

services.AddScoped(typeof(IRepository<>), typeof(Repository<>));

Multiple modules

Each project can expose its own generated registration method.

builder.Services
    .AddApplicationServices()
    .AddInfrastructureServices()
    .AddDomainServices();

Property and method injection

Constructor injection should always be the default.

However, property and method injection are available when working with legacy code, framework-created instances, optional dependencies, or initialization scenarios.

Build-time diagnostics

Injectlynx validates registrations during compilation and can detect issues before the application starts.

Examples include:

Missing interfaces
Duplicate registrations
Invalid conventions
Constructor issues
Lifetime mismatches
Circular dependencies

Native AOT Friendly

Modern .NET applications increasingly use trimming and Native AOT.

Because Injectlynx generates registration code during compilation instead of discovering services at runtime, applications remain predictable and easier to validate in AOT-friendly scenarios.

This makes it a good choice for:

ASP.NET Core APIs
Minimal APIs
Worker Services
Cloud-native applications
Native AOT projects
Large modular solutions

Why I Built Injectlynx

After working on large .NET projects, I noticed the same problems appearing repeatedly.

Manual registration became difficult to maintain.

Runtime scanning was convenient but less predictable for modern deployment models.

Attribute-based compile-time solutions scattered dependency injection metadata across hundreds of files.

I wanted a solution that kept service classes clean while giving the compiler enough information to generate registrations automatically.

Injectlynx is the result of that idea.

When Should You Use It?

Injectlynx is a good fit when:

Your project follows consistent naming conventions.
You want compile-time generated registrations.
You don't want attributes on every service.
You use the Microsoft DI container.
You are building modular applications.
You care about trimming or Native AOT.
You want build-time validation instead of runtime surprises.

For very small projects with only a handful of services, manual registration is still perfectly reasonable.

If your application loads unknown plugin assemblies dynamically at runtime, runtime scanning may still be the better approach for that specific scenario.

Final Thoughts

Dependency injection registration shouldn't become a maintenance task.

Injectlynx keeps service classes clean, removes repetitive registration code, generates standard Microsoft DI registrations during compilation, and provides build-time validation without changing the way you build .NET applications.

The goal isn't to replace Microsoft's DI container—it's to make using it simpler, cleaner, and more predictable.

If you're building modern .NET applications and want compile-time registration without runtime scanning or service attributes, give Injectlynx a try.

GitHub: https://github.com/it-nilesh/Injectlynx

NuGet: https://www.nuget.org/packages/Injectlynx

If you find the project useful, I'd love to hear your feedback, feature ideas, or contributions. Every suggestion helps improve the developer experience for the .NET community.

Build a Clean ASP.NET Core API with Signalynx and CQRS

Nilesh Vishwakarma — Fri, 31 Jul 2026 17:38:02 +0000

ASP.NET Core controllers often begin with only a few lines of code.

As an application grows, however, controllers can slowly become responsible for validation, business rules, database operations, logging, error handling, and coordinating multiple services.

The result is often a controller that is difficult to understand, test, and maintain.

The Mediator pattern helps solve this problem by moving application logic away from controllers.

Instead of directly calling services and repositories, the controller sends a strongly typed message. A dedicated handler receives that message and performs the requested operation.

In this tutorial, we will build two common ASP.NET Core API operations using Signalynx:

A POST endpoint implemented as a command
A GET endpoint implemented as a query

This article focuses only on the in-process mediator functionality of Signalynx.

What is the Mediator pattern?

The Mediator pattern introduces a dispatcher between the code requesting an operation and the code responsible for performing it.

Without a mediator, a controller may directly depend on several components:

OrdersController
   ├── OrderService
   ├── ValidationService
   ├── LoggingService
   └── OrderRepository

With a mediator, the controller sends a message:

HTTP Request
     ↓
ASP.NET Core Controller
     ↓
Signalynx
     ↓
Command or Query Handler
     ↓
Application and Database Logic

The controller remains responsible for HTTP concerns, while the handler owns the application use case.

Why use a mediator in ASP.NET Core?

A mediator can improve an ASP.NET Core application in several ways.

Thin controllers

Controllers receive HTTP input, dispatch a message, and convert the result into an HTTP response.

The application logic remains outside the API layer.

Clear use cases

Each command or query represents a specific application operation, such as:

Create an order
Retrieve an order
Update a customer
Cancel a payment
Generate an invoice

The message name communicates the intention of the operation.

Better testability

Handlers can be tested independently without starting the complete ASP.NET Core application.

Lower coupling

The controller does not need to know which repository, service, or infrastructure component performs the operation.

Reusable pipeline logic

Cross-cutting concerns can be implemented through mediator pipeline behaviors:

Validation
Logging
Authorization
Metrics
Transactions
Auditing
Exception handling

This prevents the same logic from being repeated across controllers and handlers.

What is Signalynx?

Signalynx is a strongly typed mediator and dispatcher for modern .NET applications.

For in-process application dispatch, it supports:

Commands
Queries
Request-response messages
Notifications
Domain events
Pipeline behaviors
Dependency injection
Validation and logging integrations
Source-generated registration for NativeAOT scenarios

Signalynx uses asynchronous, strongly typed contracts for messages and handlers.

You can use only the mediator functionality in a simple ASP.NET Core API and add other packages as the application grows.

Create the ASP.NET Core project

Create a new Web API project:

dotnet new webapi -n SignalynxOrdersApi
cd SignalynxOrdersApi

Install the Signalynx dependency-injection package:

dotnet add package Signalynx.DependencyInjection

This package includes the core runtime required for mediator dispatch.

Register Signalynx

using Signalynx.DependencyInjection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services.AddSignalynx(options =>
{
    options.RegisterServicesFromAssembly(
        typeof(Program).Assembly);
});

var app = builder.Build();

app.MapControllers();

app.Run();

Signalynx discovers and registers handlers from the selected assembly during application startup.

Organize the project by feature

A feature-based structure keeps each message close to its handler:

Features/
└── Orders/
    ├── CreateOrder/
    │   ├── CreateOrderCommand.cs
    │   └── CreateOrderCommandHandler.cs
    └── GetOrder/
        ├── GetOrderQuery.cs
        ├── GetOrderQueryHandler.cs
        └── OrderResponse.cs

Controllers/
└── OrdersController.cs

This is also known as a vertical-slice structure.

Instead of placing every command, handler, service, and model into separate global folders, files are grouped by the business operation they implement.

Create an order with a command

A POST request normally changes application state.

In a mediator-based application, this operation can be represented as a command.

Define the command

Create Features/Orders/CreateOrder/CreateOrderCommand.cs:

using Signalynx.Abstractions;

namespace SignalynxOrdersApi.Features.Orders.CreateOrder;

public sealed record CreateOrderCommand(
    Guid CustomerId,
    decimal Amount)
    : ICommand<Guid>;

The command contains the data required to create an order.

ICommand<Guid> means that the command returns the ID of the newly created order.

Create the command handler

Create CreateOrderCommandHandler.cs:

using Signalynx.Abstractions;

namespace SignalynxOrdersApi.Features.Orders.CreateOrder;

public sealed class CreateOrderCommandHandler
    : ICommandHandler<CreateOrderCommand, Guid>
{
    public ValueTask<Guid> HandleAsync(
        CreateOrderCommand command,
        CancellationToken cancellationToken = default)
    {
        var orderId = Guid.NewGuid();

        // Replace this with your database or domain logic.
        // For example:
        //
        // var order = new Order(
        //     orderId,
        //     command.CustomerId,
        //     command.Amount);
        //
        // dbContext.Orders.Add(order);
        // await dbContext.SaveChangesAsync(cancellationToken);

        return ValueTask.FromResult(orderId);
    }
}

The handler owns the application logic for creating an order.

In a real project, it could receive an EF Core DbContext, repository, domain service, or another dependency through constructor injection.

For example:

public sealed class CreateOrderCommandHandler(
    OrdersDbContext dbContext)
    : ICommandHandler<CreateOrderCommand, Guid>
{
    public async ValueTask<Guid> HandleAsync(
        CreateOrderCommand command,
        CancellationToken cancellationToken = default)
    {
        var order = new Order
        {
            Id = Guid.NewGuid(),
            CustomerId = command.CustomerId,
            Amount = command.Amount,
            Status = "Created"
        };

        dbContext.Orders.Add(order);

        await dbContext.SaveChangesAsync(
            cancellationToken);

        return order.Id;
    }
}

Retrieve an order with a query

A GET request reads data without intentionally changing application state.

This makes it a good match for a query.

Define the response

Create Features/Orders/GetOrder/OrderResponse.cs:

namespace SignalynxOrdersApi.Features.Orders.GetOrder;

public sealed record OrderResponse(
    Guid Id,
    Guid CustomerId,
    decimal Amount,
    string Status);

Define the query

Create GetOrderQuery.cs:

using Signalynx.Abstractions;

namespace SignalynxOrdersApi.Features.Orders.GetOrder;

public sealed record GetOrderQuery(Guid OrderId)
    : IQuery<OrderResponse?>;

The query contains the order ID.

The nullable OrderResponse? result indicates that the requested order might not exist.

Create the query handler

Create GetOrderQueryHandler.cs:

using Signalynx.Abstractions;

namespace SignalynxOrdersApi.Features.Orders.GetOrder;

public sealed class GetOrderQueryHandler
    : IQueryHandler<GetOrderQuery, OrderResponse?>
{
    public ValueTask<OrderResponse?> HandleAsync(
        GetOrderQuery query,
        CancellationToken cancellationToken = default)
    {
        // Replace this with an EF Core, Dapper,
        // or repository database query.

        OrderResponse? order = new(
            query.OrderId,
            Guid.NewGuid(),
            2499.00m,
            "Created");

        return ValueTask.FromResult(order);
    }
}

In a production application, the handler could query a database using EF Core:

public sealed class GetOrderQueryHandler(
    OrdersDbContext dbContext)
    : IQueryHandler<GetOrderQuery, OrderResponse?>
{
    public async ValueTask<OrderResponse?> HandleAsync(
        GetOrderQuery query,
        CancellationToken cancellationToken = default)
    {
        return await dbContext.Orders
            .Where(order => order.Id == query.OrderId)
            .Select(order => new OrderResponse(
                order.Id,
                order.CustomerId,
                order.Amount,
                order.Status))
            .FirstOrDefaultAsync(cancellationToken);
    }
}

The database query remains inside the query handler rather than the API controller.

Create the request model

Create a request model for the POST endpoint:

namespace SignalynxOrdersApi.Features.Orders.CreateOrder;

public sealed record CreateOrderRequest(
    Guid CustomerId,
    decimal Amount);

The request model represents the HTTP contract.

The command represents the application operation.

Keeping these contracts separate allows the API contract to evolve independently from the application layer when necessary.

Dispatch commands and queries from the controller

Create Controllers/OrdersController.cs:

using Microsoft.AspNetCore.Mvc;
using Signalynx;
using SignalynxOrdersApi.Features.Orders.CreateOrder;
using SignalynxOrdersApi.Features.Orders.GetOrder;

namespace SignalynxOrdersApi.Controllers;

[ApiController]
[Route("api/orders")]
public sealed class OrdersController(
    ISignalynx signalynx)
    : ControllerBase
{
    [HttpGet("{id:guid}")]
    public async Task<IActionResult> GetOrder(
        Guid id,
        CancellationToken cancellationToken)
    {
        var query = new GetOrderQuery(id);

        var order = await signalynx
            .QueryAsync<GetOrderQuery, OrderResponse?>(
                query,
                cancellationToken);

        return order is null
            ? NotFound()
            : Ok(order);
    }

    [HttpPost]
    public async Task<IActionResult> CreateOrder(
        CreateOrderRequest request,
        CancellationToken cancellationToken)
    {
        var command = new CreateOrderCommand(
            request.CustomerId,
            request.Amount);

        var orderId = await signalynx
            .DispatchAsync<CreateOrderCommand, Guid>(
                command,
                cancellationToken);

        return CreatedAtAction(
            nameof(GetOrder),
            new { id = orderId },
            new { id = orderId });
    }
}

The controller remains small.

It does not contain order-creation logic or data-access logic. It only:

Reads HTTP input.
Creates a command or query.
Sends it through Signalynx.
Converts the result into an HTTP response.

Its only application-level dependency is ISignalynx.

Test the API

Run the application:

dotnet run

Create an order:

POST /api/orders
Content-Type: application/json

{
  "customerId": "4d8c5790-724f-4b42-bdda-bfa7f4932773",
  "amount": 2499.00
}

A successful response may look like this:

{
  "id": "0c9af8bd-478f-4480-a989-3cdb0aafee51"
}

Retrieve the order:

GET /api/orders/0c9af8bd-478f-4480-a989-3cdb0aafee51

Example response:

{
  "id": "0c9af8bd-478f-4480-a989-3cdb0aafee51",
  "customerId": "4d8c5790-724f-4b42-bdda-bfa7f4932773",
  "amount": 2499.00,
  "status": "Created"
}

The sample handlers currently return demonstration data. Connect them to your database to persist and retrieve real orders.

Add validation and logging with pipeline behaviors

One major advantage of a mediator is the ability to apply common logic around multiple application operations.

A mediator pipeline can be visualized like this:

Controller
   ↓
Logging Behavior
   ↓
Validation Behavior
   ↓
Command or Query Handler
   ↓
Response

Pipeline behaviors can be used for:

Request validation
Structured logging
Authorization
Performance measurement
Database transactions
Exception handling
Auditing

Behaviors can be registered centrally:

builder.Services.AddSignalynx(options =>
{
    options.RegisterServicesFromAssembly(
        typeof(Program).Assembly);

    options.AddOpenBehavior(
        typeof(ValidationBehavior<,>));

    options.AddOpenBehavior(
        typeof(LoggingBehavior<,>));
});

This keeps individual handlers focused on application and business logic.

Only add behaviors that provide clear value to your application.

Commands, queries, requests, and events

Signalynx provides explicit message contracts for different application interactions.

Requirement	Recommended type	Example
Change application state	Command	Create or cancel an order
Read application data	Query	Retrieve an order by ID
General one-to-one operation	Request	Calculate a value
Notify multiple local handlers	Notification or domain event	Order created

Using explicit message types makes the purpose of each operation visible in the code.

Command

Use a command when an operation changes application state:

public sealed record CancelOrderCommand(Guid OrderId)
    : ICommand;

Query

Use a query when an operation retrieves data:

public sealed record SearchOrdersQuery(string SearchTerm)
    : IQuery<IReadOnlyList<OrderResponse>>;

Request

Use a request for a general one-to-one operation that does not clearly fit command or query semantics:

public sealed record CalculateShippingRequest(
    string PostalCode,
    decimal Weight)
    : IRequest<decimal>;

Notification or domain event

Use a notification or domain event when multiple local handlers should react independently:

public sealed record OrderCreatedEvent(Guid OrderId)
    : IDomainEvent;

Possible handlers could include:

OrderCreatedEvent
   ├── Send confirmation email
   ├── Update analytics
   ├── Write audit record
   └── Reserve inventory

Mediator pattern versus direct service calls

A mediator is useful when an application contains multiple use cases and repeated cross-cutting concerns.

However, direct service calls may still be sufficient for a very small application.

Adding a command and handler for every trivial operation can create unnecessary files when there is no meaningful architectural separation to gain.

A mediator becomes more valuable when:

Controllers are growing too large.
Business logic is spread across API endpoints.
Multiple endpoints repeat validation or logging.
Application use cases need independent tests.
The project follows Clean Architecture.
The project follows vertical-slice architecture.
Commands and queries need clear ownership.
Cross-cutting behaviors must be applied consistently.

The goal is not to add more layers.

The goal is to give each use case a clear boundary.

Testing a handler

Because the business operation lives in a handler, it can be tested without creating an ASP.NET Core test server.

For example:

public sealed class CreateOrderCommandHandlerTests
{
    [Fact]
    public async Task HandleAsync_ReturnsOrderId()
    {
        var handler = new CreateOrderCommandHandler();

        var command = new CreateOrderCommand(
            Guid.NewGuid(),
            2499.00m);

        var orderId = await handler.HandleAsync(command);

        Assert.NotEqual(Guid.Empty, orderId);
    }
}

When the handler uses a database or another dependency, provide a test implementation through its constructor.

This keeps the test focused on one application operation.

Why I built Signalynx

I built Signalynx to provide a modern, strongly typed mediator experience for .NET applications while keeping in-process dispatch independent from optional infrastructure.

For a simple ASP.NET Core API, you can use only the mediator functionality.

As the application grows, you can add packages for:

Validation
Logging
Source generation
Domain events
Durable messaging
Inbox and outbox patterns
Message-broker integrations

This allows teams to begin with a clean in-process architecture without forcing every application to immediately adopt distributed messaging infrastructure.

Final thoughts

The Mediator pattern can make ASP.NET Core APIs easier to maintain by separating HTTP endpoints from application use cases.

With Signalynx:

A POST endpoint can dispatch a strongly typed command.
A GET endpoint can execute a strongly typed query.
Each use case can have its own handler.
Controllers remain focused on HTTP concerns.
Validation and logging can be added through reusable pipelines.
Handlers can be tested independently.
Application code becomes easier to extend.

Install Signalynx using:

dotnet add package Signalynx.DependencyInjection

Explore the project:

Signalynx is open source. If it helps your project, consider starring the GitHub repository and sharing your feedback.

How do you currently keep your ASP.NET Core controllers thin?

Signalynx for .NET: Mediator, CQRS, Outbox, Inbox, and Durable Messaging Explained

Nilesh Vishwakarma — Fri, 31 Jul 2026 17:29:28 +0000

Modern .NET applications often begin with a straightforward architecture:

Controller
  → Service
  → Database
  → Response

This works well while the application is small.

As the project grows, however, business logic starts spreading across controllers, application services, background workers, event handlers, databases, and message brokers.

Eventually, teams begin asking questions such as:

How do we keep business logic out of controllers?
How should commands and queries be organized?
How can several modules respond to the same event?
What happens when asynchronous processing fails?
How do we prevent duplicate message processing?
How can we introduce durable messaging without redesigning the entire application?

I created Signalynx to provide a structured answer to these problems.

Signalynx is an open-source, strongly typed mediator, CQRS dispatcher, and durable messaging toolkit for .NET 8, .NET 9, and .NET 10.

It supports:

Commands, queries, and request-response messages
Notifications and domain events
Pipeline behaviors
Bulk processing
Durable message processing
Retries and scheduling
Inbox and outbox patterns
Dead-letter handling and replay
SQL Server and PostgreSQL persistence
RabbitMQ, Kafka, Azure Service Bus, and Amazon SQS
NativeAOT-friendly source generation
OpenTelemetry-compatible diagnostics

Project links:

The problem with direct service dependencies

Consider an order endpoint that creates an order, sends a confirmation email, and reserves inventory:

public async Task<IActionResult> CreateOrder(
    CreateOrderRequest request)
{
    var order = await _orderService.CreateAsync(request);

    await _emailService.SendConfirmationAsync(order);
    await _inventoryService.ReserveItemsAsync(order);

    return Ok(order);
}

This code looks reasonable at first.

But the controller is now responsible for:

Creating the order
Triggering email delivery
Reserving inventory
Deciding execution order
Coordinating dependencies
Handling failures

As more operations are added, the endpoint becomes tightly coupled to multiple services.

With a mediator-based design, the endpoint describes what should happen without coordinating every implementation detail:

var orderId = await signalynx.DispatchAsync<
    CreateOrderCommand,
    Guid>(
        command,
        cancellationToken);

The command handler contains the business operation.

Validation, logging, authorization, transactions, metrics, and other cross-cutting concerns can be handled through pipeline behaviors.

The endpoint becomes an entry point rather than a container for business logic.

Strongly typed commands and queries

Signalynx uses explicit contracts for different kinds of application operations.

Commands

Commands normally represent operations that change application state:

public sealed record CreateOrderCommand(
    Guid CustomerId,
    decimal Amount)
    : ICommand<Guid>;

The handler declares both the command it accepts and the result it returns:

public sealed class CreateOrderHandler
    : ICommandHandler<CreateOrderCommand, Guid>
{
    public ValueTask<Guid> HandleAsync(
        CreateOrderCommand command,
        CancellationToken cancellationToken = default)
    {
        var orderId = Guid.NewGuid();

        // Save the order.

        return ValueTask.FromResult(orderId);
    }
}

Queries

Queries represent read operations:

public sealed record GetOrderQuery(Guid OrderId)
    : IQuery<OrderDto>;

Separating commands and queries makes the purpose of each operation easier to understand.

Instead of tracing generic methods such as ExecuteAsync, ProcessAsync, or HandleAsync across several services, developers can identify the application flow from the message contract itself.

Pipeline behaviors

Production applications usually need cross-cutting functionality such as:

Validation
Logging
Authorization
Metrics
Transactions
Auditing
Exception handling

Without a pipeline, this logic is often repeated inside controllers and handlers.

Signalynx allows these concerns to be registered as pipeline behaviors:

builder.Services.AddSignalynx(options =>
{
    options.RegisterServicesFromAssembly(
        typeof(Program).Assembly);

    options.AddOpenBehavior(
        typeof(ValidationBehavior<,>));

    options.AddOpenBehavior(
        typeof(LoggingBehavior<,>));
});

The handler can then remain focused on the business operation.

This also makes architectural changes easier. For example, changing the logging or validation strategy does not require modifying every command handler.

Domain events and multiple handlers

Some business operations need to notify several parts of an application.

After an order is confirmed, the application may need to:

Reduce inventory
Send a confirmation notification
Add an audit entry
Update reporting data
Trigger analytics

The order handler should not need direct dependencies on all of these modules.

Instead, it can publish an event:

await signalynx.PublishEventAsync(
    new OrderConfirmed(orderId),
    cancellationToken);

Multiple handlers can respond to the event independently.

For example:

OrderConfirmed
  ├── Inventory handler
  ├── Notification handler
  ├── Analytics handler
  └── Audit handler

This is especially useful in modular monoliths, where business modules share one deployment but should remain logically independent.

Signalynx supports sequential and parallel publishing.

Sequential execution is generally easier to reason about because ordering and failure behavior are predictable. Parallel execution can be useful when handlers are independent and thread-safe.

Local events are not durable

In-process events are useful, but they have an important limitation.

Suppose an application publishes an event and then shuts down before every handler completes. The unfinished work may be lost.

That may be acceptable for optional local operations. It is usually not acceptable for critical processes such as:

Payment processing
Order fulfillment
Security-event processing
Customer notifications
Financial reconciliation
Integration with another service

When work must survive process restarts or temporary infrastructure failures, it needs durable messaging.

Signalynx Messaging adds:

Durable message envelopes
Hosted processing workers
Retries
Delayed scheduling
Inbox and outbox contracts
Dead-letter handling
Message replay

A message can be enqueued for asynchronous processing:

await messageBus.EnqueueAsync(
    new OrderSubmitted(orderId),
    destination: "orders",
    cancellationToken: cancellationToken);

It can also be scheduled for later:

await messageBus.ScheduleAsync(
    new OrderSubmitted(orderId),
    DateTimeOffset.UtcNow.AddMinutes(5),
    destination: "orders",
    cancellationToken: cancellationToken);

If processing repeatedly fails, the message can be moved to a dead-letter store for investigation and later replay.

Why the transactional outbox matters

Distributed applications often need to perform two operations:

Save business data in a database.
Publish an integration message.

For example:

Save Order
Publish OrderCreated

What happens when the database transaction succeeds but the message broker is unavailable?

The order exists, but the OrderCreated message is never delivered.

The system is now inconsistent.

The transactional outbox pattern addresses this problem by storing the business change and the outgoing message in the same database transaction:

Database transaction
  ├── Insert Order
  └── Insert Outbox Message

A background worker later reads the outbox record and publishes it to the broker:

Outbox
  → Background publisher
  → Message broker
  → Consumer

If the broker is temporarily unavailable, the message remains in the outbox and can be retried.

Signalynx provides contracts and storage adapters for implementing this pattern.

However, the application must still ensure that the business write and outbox insert participate in the same database transaction.

A library can provide the infrastructure, but it cannot automatically make every business operation transactional.

Why the inbox matters

Most message brokers use at-least-once delivery.

This means the same message may be delivered more than once.

For example, a consumer might successfully process a message but fail before acknowledging it. The broker may then deliver it again.

Without duplicate protection, the application could:

Charge a customer twice
Send the same email several times
Reserve inventory twice
Create duplicate records

The inbox pattern records processed message identifiers:

Incoming Message
  → Check Inbox
      → Already processed: skip
      → New message: process and record

Signalynx provides inbox contracts and durable store adapters to support this workflow.

Even with an inbox, business handlers should still be designed with idempotency in mind, especially when they call external systems.

Start locally and add infrastructure later

One of the main design goals of Signalynx is modularity.

Applications do not need to install durable messaging infrastructure just to use the mediator.

You can begin with the core runtime:

dotnet add package Signalynx.Core

For Microsoft dependency injection:

dotnet add package Signalynx.DependencyInjection

Additional capabilities can be installed only when required:

dotnet add package Signalynx.Validation
dotnet add package Signalynx.Logging
dotnet add package Signalynx.SourceGeneration
dotnet add package Signalynx.Messaging

This allows an application to evolve gradually:

Controller
  → Command
  → Handler

Later, as requirements grow:

API
  → Command or Query
  → Pipeline
  → Handler
  → Domain Event
  → Outbox
  → Message Broker
  → Consumer
  → Inbox
  → Business Operation

The application does not need to adopt databases, durable stores, or message brokers before those capabilities are necessary.

Modular monoliths and microservices

Signalynx can be used in both modular monoliths and microservice architectures.

Modular monolith

A modular monolith might contain modules such as:

Application
├── Orders
├── Payments
├── Inventory
├── Customers
└── Notifications

Commands and queries can organize direct operations inside each module.

Notifications and domain events can communicate changes between modules without creating direct dependencies everywhere.

Microservices

Inside a microservice, the mediator organizes local application logic.

When communication crosses process boundaries, the durable messaging layer can handle:

Persistence
Retries
Scheduling
Broker delivery
Duplicate detection
Dead letters
Replay

Signalynx includes transport integrations for:

RabbitMQ
Apache Kafka
Azure Service Bus
Amazon SQS

Durable store integrations are available for:

SQL Server
PostgreSQL

The result is a related programming model for both local dispatch and asynchronous communication.

NativeAOT and source generation

Runtime assembly scanning is convenient, but it can create problems for trimming and NativeAOT applications.

Signalynx supports source-generated handler registration.

The source generator can create:

Dependency-injection registrations
Handler metadata
A static handler map

This avoids runtime assembly scanning on the NativeAOT path.

Traditional applications can continue using runtime discovery, while trimmed or NativeAOT applications can use generated registration.

Performance considerations

Signalynx is designed to keep mediator overhead low.

Its performance-oriented design includes:

Typed handler calls
Startup-time handler discovery
Immutable handler metadata
ValueTask-based asynchronous contracts
Cached dispatch delegates
Fast paths when no pipeline behaviors are registered
No LINQ in core dispatch loops
Optional source-generated registration

The repository includes BenchmarkDotNet benchmarks covering mediator and messaging operations.

However, isolated mediator benchmarks should not be treated as complete application benchmarks.

Real-world performance also depends on:

Database access
Network latency
Message size
Serialization
Broker configuration
Durability settings
Batching
Database indexes
Business-handler logic

Teams should benchmark their actual workload rather than choosing an architecture solely from isolated dispatch numbers.

Observability

A messaging system should not become a black box.

Signalynx exposes activities and metrics for mediator dispatch and durable messaging, including:

Dispatch duration and failures
Publish duration and failures
Messages enqueued
Messages sent
Messages handled
Retry counts
Dead-letter counts
Handler duration

These signals can be connected to OpenTelemetry-compatible monitoring systems.

In production, teams should monitor:

Outbox depth and message age
Retry rate
Dead-letter growth
Handler latency
Consumer lag
Broker availability
Processing failures

This helps detect failed integrations and growing queues before they affect customers.

When should you use Signalynx?

Signalynx becomes useful when:

Controllers contain too much business logic.
Services have many direct dependencies.
The application uses CQRS.
Multiple handlers need to respond to an event.
Validation and logging are repeated throughout the codebase.
Background work must survive application restarts.
Failed operations need controlled retries.
Duplicate messages must be detected.
The system needs inbox or outbox patterns.
The architecture may later introduce a message broker.
NativeAOT support is important.
Dispatch overhead and allocations need to remain low.

The important question is not:

Should every .NET application use a mediator?

A better question is:

Has the application become complex enough that separating requests from their handlers will improve maintainability?

When might it be unnecessary?

Signalynx is not required for every project.

A direct architecture may be better when:

The application is very small.
There are only a few simple operations.
Direct service calls remain clear.
The team does not use CQRS or event-driven patterns.
Another mediator or messaging framework already works well.
Adding another abstraction would create more complexity than value.

A mediator should improve the architecture. It should not become architecture for its own sake.

Installing a messaging package also does not automatically make an application production-ready.

Reliability still depends on:

Transaction design
Handler idempotency
Retry classification
Persistent storage
Broker configuration
Security controls
Monitoring and alerts
Backup and recovery
Load testing
Failure testing

Getting started

Install the dependency-injection integration:

dotnet add package Signalynx.DependencyInjection

Define a command:

public sealed record CreateOrderCommand(
    Guid CustomerId,
    decimal Amount)
    : ICommand<Guid>;

Create its handler:

public sealed class CreateOrderHandler
    : ICommandHandler<CreateOrderCommand, Guid>
{
    public ValueTask<Guid> HandleAsync(
        CreateOrderCommand command,
        CancellationToken cancellationToken = default)
    {
        return ValueTask.FromResult(Guid.NewGuid());
    }
}

builder.Services.AddSignalynx(options =>
{
    options.RegisterServicesFromAssembly(
        typeof(Program).Assembly);
});

Dispatch the command:

var orderId = await signalynx.DispatchAsync<
    CreateOrderCommand,
    Guid>(
        command,
        cancellationToken);

From there, you can introduce pipeline behaviors, domain events, durable messaging, database stores, or broker transports only when your application requires them.

Final thoughts

Signalynx is designed for .NET teams that need more than a basic mediator but do not want durable messaging infrastructure to be mandatory from the beginning.

Its goal is to provide a gradual path from simple in-process dispatch to reliable distributed processing.

You can begin with commands, queries, and handlers.

As the architecture grows, you can add:

Pipeline behaviors
Domain events
Persistent queues
Transactional outbox processing
Inbox deduplication
Retries and scheduling
Dead-letter handling
Message brokers
Production observability

Signalynx is open source under the MIT License.

Feedback, testing, contributions, and real-world usage are welcome.

What reliability or architecture problem has been the hardest part of introducing messaging into your .NET applications?