DEV Community: Nilesh Vishwakarma

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?