DEV Community: Nilesh Vishwakarma

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?