DEV Community: Anton Martyniuk

How to Add JWT Authentication to SignalR Hubs in ASP.NET Core

Anton Martyniuk — Fri, 25 Sep 2026 08:11:41 +0000

SignalR makes real-time communication in .NET applications simple.
You can send live data, notifications, and streaming updates to clients with minimal code.

By default, SignalR hubs are accessible to all clients.
Clients can connect, call hub methods, and receive messages without authentication.

In production, you may need to know who is connecting to your hub, what they are allowed to do, and how to reject unauthorized access.

JWT authentication is the standard for securing SignalR hubs in any environment, including browsers.
It works with WebSockets, Server-Sent Events, and Long Polling transports.

In this post, we will explore:

Why SignalR Needs Authentication
Setting Up JWT Authentication for SignalR
How to Stream Events with SignalR for a Given User
Role-Based Authorization on Hub Methods
Connecting from a JavaScript Client
Connecting from a .NET Client
Security Best Practices for SignalR

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-add-jwt-authentication-to-signalr-hubs-in-aspnetcore

Why SignalR Needs Authentication

SignalR uses multiple transport protocols to maintain real-time connections: WebSockets, Server-Sent Events, and Long Polling.

By default, any client can connect to a SignalR hub and call its methods.

This creates several problems in production:

No user identity - You can't tell who is connected or send messages to specific users.
No access control - Anyone can call any hub method, including admin operations.
No audit trail - You can't log which users performed which actions.
Security exposure - Sensitive data could be streamed to unauthorized clients.

Why JWT and not Cookies?

Cookies work well for browser-based apps where users log in through a web form.

But JWT tokens are the better choice when:

Your clients are mobile apps, desktop apps, or SPAs.
You need cross-platform authentication.
Your API and frontend run on different domains.
You're building microservices that need stateless authentication.

There is one important detail about how tokens are handled in SignalR connections.
In standard REST APIs, the client sends the JWT token in the Authorization HTTP header.
But SignalR can't always do this.

When using WebSockets or Server-Sent Events in a browser, the browser API does not allow setting custom headers.
Instead, the token is sent as a query string parameter: ?access_token=<token>.

This means you need extra configuration on the server to read the token from the query string.
We will cover this setup in the next section.

For a deeper dive into authentication and authorization in ASP.NET Core, read my article on Authentication and Authorization Best Practices.

Setting Up JWT Authentication for SignalR

Let's build the backend for the stock price streaming application.

In Modern .NET versions, you no longer need to install the SignalR NuGet package.
SignalR is now included in the ASP.NET Core Web SDK.

Here is how you can configure SignalR in your project:

builder.Services.AddSignalR();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// Map the SignalR hub
app.MapHub<StockPriceHub>("/hubs/stocks");

We need to configure JWT bearer authentication and add the OnMessageReceived event handler that extracts the token from the query string for SignalR connections:

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(authConfig.Key));

    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = authConfig.Issuer,
        ValidAudience = authConfig.Audience,
        IssuerSigningKey = key
    };

    options.Events = new JwtBearerEvents
    {
        OnMessageReceived = context =>
        {
            var accessToken = context.Request.Query["access_token"];

            var path = context.HttpContext.Request.Path;

            if (!string.IsNullOrEmpty(accessToken) &&
                path.StartsWithSegments("/hubs"))
            {
                context.Token = accessToken;
            }

            return Task.CompletedTask;
        }
    };
});

When a browser connects to a SignalR hub via WebSockets or SSE, it can't send the Authorization header.
The JavaScript client sends the token as ?access_token=<token>.

The OnMessageReceived event fires before the JWT middleware validates the token.

Token extraction is limited to paths starting with /hubs.
This avoids reading tokens from query strings on other endpoints.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-add-jwt-authentication-to-signalr-hubs-in-aspnetcore

Getting Started With Event Sourcing in .NET With Marten and PostgreSQL

Anton Martyniuk — Fri, 25 Sep 2026 04:42:41 +0000

Most applications store data by saving the current state to a database.

When a customer adds an item to a shopping cart, you update a row in the database.
The previous state is lost.
You only see the cart's current state, with all history lost.

This works for many applications. But what happens when you need to know the full history of changes?
What if you need to rebuild past states, debug complex business flows, or generate analytics from historical data?

This is where the Event Sourcing pattern is useful.

Event Sourcing stores every change as an immutable event.
Instead of overwriting data, you append new events to a stream.
The current state is derived by replaying these events.

In this post, I will show you how to build an Event Sourcing application in .NET using the Marten library and PostgreSQL.

We will build a Shopping Cart that demonstrates all the core Event Sourcing concepts: events, streams, aggregates, commands, and projections.

In this post, we will explore:

What is Event Sourcing
Overview of the Shopping Cart Application
Setting Up Marten with PostgreSQL
Defining Domain Events
Building the Aggregate
Writing Commands: Appending Events to Streams
Building Read Models with Projections
The Query Side: Reading Projected Data
When to Use Event Sourcing
Summary

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-event-sourcing-in-dotnet-with-marten-and-postgresql

What is Event Sourcing

In traditional CRUD applications, you store the current state of an entity in a database row.

When a customer adds a product to a shopping cart, you insert or update a row in the CartItems table.
When they remove an item, you delete that row.
The database always shows the latest state.

This approach is simple and works well for many use cases. But it has a fundamental limitation: you lose history.

If a customer added 5 items, removed 2, changed quantities 3 times, and then checked out, all you see in the database is the final state.
You cannot answer questions like "What did the cart look like 10 minutes ago?" or "Which items were removed before checkout?"

Event Sourcing takes a different approach. Instead of storing the current state, you store the sequence of events that led to the current state.

For a shopping cart, these events might look like:

CartCreated - Customer started a new cart
ItemAdded - Wireless Mouse, quantity 1
ItemAdded - Mechanical Keyboard, quantity 1
ItemRemoved - Wireless Mouse
ItemAdded - Gaming Mouse, quantity 2
CartCheckedOut - Customer completed the purchase

The current state of the cart is derived by replaying all these events from the beginning. This sequence of events is called an event stream.

Core Concepts

Event Sourcing introduces several core concepts that work together:

Events are immutable facts that describe something that happened in the past.
An event is never deleted or modified.
Once ItemAdded is recorded, it stays in the stream forever.
Events use past tense names: CartCreated, ItemAdded, OrderConfirmed.

Streams are ordered sequences of events that belong to the same entity.
A shopping cart has its own stream. Each stream has a unique identifier, typically a GUID.
All events for cart abc-123 are stored together in correct order as they appear in time.

Aggregates are domain objects that derive their current state by replaying events from a stream.
The ShoppingCart aggregate starts empty and applies each event one by one.
After replaying all events, the aggregate reflects the current state.
Aggregates also enforce business rules before new events are appended.

Projections are read models built from events.
While aggregates give you the state of a single stream, projections can combine data from multiple streams to create optimized views for querying.
For example, a "Product Popularity" projection might track how many times each product was added across all carts.

Event Sourcing is not a replacement for CRUD.
It is a different approach that shines in specific scenarios.
We will explore when to use it at the end of this post.

Now let's build a real application to see these concepts in action.

Overview of the Shopping Cart Application

We will build a Shopping Cart API that demonstrates all the core Event Sourcing concepts.

Here is what our application supports:

Commands (write side):

Create a new cart
Add items to the cart
Remove items from the cart
Change item quantities
Checkout the cart
Confirm the order

Queries (read side):

Get cart details (from an inline projection)
Get product popularity rankings (from an async cross-stream projection)

Domain events:

CartCreated
ItemAdded
ItemRemoved
ItemQuantityChanged
CartCheckedOut
OrderConfirmed

Project Structure

The application follows Vertical Slice Architecture with three projects:

ShoppingCart.Domain contains the pure domain model: event records and the aggregate.

ShoppingCart.Features contains the vertical slices: each feature has its own folder with an endpoint, handler, and optional validator. It also contains the projections. This project uses Marten, Carter, ErrorOr, and FluentValidation.

ShoppingCart.WebApi is the host project that wires everything together: Marten configuration, dependency injection, and the ASP.NET Core pipeline.

This structure is similar to what I use in my Modular Monolith projects, but simplified for a single module.

👉 Read original article on my newsletter: https://antondevtips.com/blog/getting-started-with-event-sourcing-in-dotnet-with-marten-and-postgresql

Humanizer in .NET: Turn Strings, Dates, and Numbers Into Human-Friendly Text

Anton Martyniuk — Tue, 22 Sep 2026 11:11:31 +0000

Software stores data the way machines like it. Users want to read it the way humans like it.

So you write this boilerplate code every day.

You manually split a PascalCase enum into words. You turn 2 into "2nd" with a few if statements.

You format a timestamp as "3 hours ago". You pluralize "item" only when the count is not 1.

It is a few lines here, a helper method there - and it piles up across a codebase.

Humanizer is a small, free .NET library that does all of it for you.

It turns developer-shaped data into human-friendly text with a single method call.

In this post, we will explore:

How to Humanize and transform strings
How to Humanize enums
How to Humanize dates and times
How to Turn numbers into words
How to Work with culture
How to Pluralize and quantify
How to Format byte sizes and large numbers
Bonus: Roman numerals, collections, and fluent dates

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/humanizer-in-dotnet-turn-strings-dates-and-numbers-into-human-friendly-text

How to Humanize and Transform Strings

First, add Humanizer to your project by installing the following NuGet package:

dotnet add package Humanizer

The core of Humanizer is Humanize(), which turns a developer string into a readable sentence.

It splits strings in PascalCase, camelCase, snake_case, kebab-case, all in lower or UPPER case, into words and applies sentence casing:

"PascalCaseInputStringIsTurnedIntoSentence".Humanize();
// => "Pascal case input string is turned into sentence"

"Underscored_input_string_is_turned_into_sentence".Humanize();
// => "Underscored input string is turned into sentence"

Transform changes the casing without splitting words. It takes one or more strategies:

"Sentence casing".Transform(To.TitleCase);    // => "Sentence Casing"
"Sentence casing".Transform(To.LowerCase);    // => "sentence casing"
"Sentence casing".Transform(To.SentenceCase); // => "Sentence casing"

Dehumanize is the reverse of Humanize - it turns a sentence back into a PascalCase identifier:

"Pascal case input string is turned into sentence".Dehumanize();
// => "PascalCaseInputStringIsTurnedIntoSentence"

And Truncate shortens text to a length, adding an ellipsis:

"Long text to truncate".Truncate(10);
// => "Long text…"

These four cover most of the string formatting you write by hand: generating labels, display names, and identifiers from code.

How to Humanize Enums

Enum names are in PascalCase, and your UI needs readable labels.

Normally, you map each enum member to a label by hand:

var label = status switch
{
    ShipmentStatus.OutForDelivery => "Out for delivery",
    ShipmentStatus.InTransit => "In transit",
    // ... a line for every member
};

Calling Humanize() on the enum value does the same thing for free. It splits the name into words, so the switch disappears:

public enum ShipmentStatus
{
    Pending,
    InTransit,
    OutForDelivery,
    Delivered
}

ShipmentStatus.OutForDelivery.Humanize();  // => "Out for delivery"
ShipmentStatus.InTransit.Humanize();       // => "In transit"

When you need a label that does not match the member name, add a [Description] attribute and Humanizer uses it:

public enum ShipmentStatus
{
    [Description("Awaiting pickup")]
    Pending,
    // ...
}

ShipmentStatus.Pending.Humanize();  // => "Awaiting pickup"

You can also go the other way, turning a display string back into the enum value with DehumanizeTo:

"Out for delivery".DehumanizeTo<ShipmentStatus>();
// => ShipmentStatus.OutForDelivery

This alone removes a surprising amount of mapping code from the boundary between your domain and your UI.

👉 Read original article on my newsletter: https://antondevtips.com/blog/humanizer-in-dotnet-turn-strings-dates-and-numbers-into-human-friendly-text

Synchronous vs Asynchronous Communication in Microservices: How to Choose the Right Approach

Anton Martyniuk — Fri, 18 Sep 2026 08:20:21 +0000

Choosing the right communication style between microservices is one of the most important architectural decisions you will make.

Get it wrong, and you end up with a fragile system where one failing service brings everything down.
Get it right, and your services stay independent, scalable, and resilient.

In distributed systems, there are two fundamental ways services talk to each other: synchronous and asynchronous communication.
Each comes with trade-offs in latency, coupling, reliability, and complexity.

Throughout my career, I have designed and built distributed systems using both approaches.
In this post, I will break down how each communication style works, when to use each one, and how real systems often combine both to achieve the best results.

In this post, we will explore:

How Microservices Communicate
Synchronous Communication: HTTP and gRPC
Asynchronous Communication: Message Brokers and Event Streaming
Synchronous vs Asynchronous: Deep Comparison
Hybrid Communication: Mixing Sync and Async in One Flow
How to Choose: Decision Checklist
Summary

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/synchronous-vs-asynchronous-communication-in-microservices

How Microservices Communicate

In a Modular Monolith application, components call each other through in-process method calls.
It's fast, simple, and reliable.

But when you break a Modular Monolith into microservices, those calls become network calls.
And network calls introduce latency, failures, and a whole new set of challenges.

There are two fundamental approaches for microservices communication:

Synchronous communication: the caller sends a request and waits for a response before continuing.
The caller is blocked until the response arrives or a timeout occurs.

Think of it like a phone call - you dial, the other person picks up, you talk, and you wait for an answer before continuing the conversation.

Asynchronous communication: the caller sends a message and moves on without waiting for an immediate response.
The message is processed later by the receiving service at its own pace.

Think of it like sending an email - you send it and continue with your work, without waiting for the recipient to read and reply.

These two styles lead to fundamentally different system behaviors in terms of coupling, resilience, and scalability.

Now let's explore each communication style in detail.

Synchronous Communication: HTTP and gRPC

Synchronous communication is the most intuitive way for services to talk.
Service A calls Service B, waits for the result, and then continues its work.

The two most popular protocols for synchronous communication in .NET are HTTP (REST) and gRPC.

You can also use HotChocolate GraphQL Strawberry Shake for HTTP/REST communication. But this is a pretty niche approach. If you want to learn more about HotChocolate GraphQL, see this article.

HTTP/REST

HTTP-based REST APIs are the most common way microservices communicate synchronously.
They are simple to build, easy to debug, and supported by virtually every language and framework.

Here is a typical example. The Booking Service needs to check room availability from the Property Service before confirming a reservation:

public class PropertyServiceClient
{
    private readonly HttpClient _httpClient;

    public PropertyServiceClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<RoomAvailability?> CheckAvailabilityAsync(
        int propertyId, DateOnly checkIn, DateOnly checkOut)
    {
        var response = await _httpClient.GetAsync(
            $"/api/properties/{propertyId}/availability?checkIn={checkIn}&checkOut={checkOut}");

        response.EnsureSuccessStatusCode();

        return await response.Content.ReadFromJsonAsync<RoomAvailability>();
    }
}

HTTP/REST works well when:

You need a simple request-response interaction
The client needs data immediately to continue
You are building public APIs
You want broad compatibility across languages and platforms

The main downside is temporal coupling - the caller must wait for the receiver to respond.
If the Property Service is slow or down, the Booking Service is stuck.

gRPC

gRPC is a high-performance RPC (Remote Procedure Call) framework built on HTTP/2.
It uses Protocol Buffers (Protobuf) for serialization, which is significantly faster and smaller than JSON.

gRPC shines in service-to-service communication where performance matters.

Let's explore an example: how to check the room availability with gRPC.

First, define the service contract in a .proto file:

syntax = "proto3";

option csharp_namespace = "BookingPlatform.Protos";

service PropertyService {
  rpc CheckAvailability (AvailabilityRequest) returns (AvailabilityResponse);
}

message AvailabilityRequest {
  int32 property_id = 1;
  string check_in = 2;
  string check_out = 3;
}

message AvailabilityResponse {
  bool is_available = 1;
  double price_per_night = 2;
  string currency = 3;
}

Then call it from the Booking Service:

public class PropertyGrpcClient
{
    private readonly PropertyService.PropertyServiceClient _client;

    public PropertyGrpcClient(PropertyService.PropertyServiceClient client)
    {
        _client = client;
    }

    public async Task<AvailabilityResponse> CheckAvailabilityAsync(
        int propertyId, string checkIn, string checkOut)
    {
        var request = new AvailabilityRequest
        {
            PropertyId = propertyId,
            CheckIn = checkIn,
            CheckOut = checkOut
        };

        return await _client.CheckAvailabilityAsync(request);
    }
}

gRPC works well when:

You need low-latency, high-throughput communication between internal services
You have strict performance requirements
You want strongly typed contracts between services
You need streaming capabilities (server streaming, client streaming, or bidirectional)

gRPC is not ideal for browser-to-service communication (though gRPC-Web exists as a workaround) or when you need human-readable payloads for debugging.

Handling Failures in Synchronous Communication

The biggest risk with synchronous communication is cascading failures.
When Service A calls Service B, and Service B calls Service C - if Service C is down, all three services are affected.

To mitigate this, you should implement resilience patterns:

Retries with backoff - retry failed requests with increasing delays between attempts:

builder.Services.AddHttpClient<PropertyServiceClient>(client =>
{
    client.BaseAddress = new Uri("https://property-service:5001");
})
.AddStandardResilienceHandler(options =>
{
    options.Retry.MaxRetryAttempts = 3;
    options.Retry.BackoffType = DelayBackoffType.Exponential;
    options.Retry.Delay = TimeSpan.FromMilliseconds(500);

    options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(10);
    options.CircuitBreaker.FailureRatio = 0.9;
    options.CircuitBreaker.MinimumThroughput = 5;

    options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(2);
});

The AddStandardResilienceHandler from Microsoft.Extensions.Http.Resilience gives you retries, circuit breaker, and timeouts in a single configuration.

Circuit Breaker - stops calling a failing service to give it time to recover.

When a service fails repeatedly, the circuit "opens," and all subsequent requests fail immediately instead of waiting for a timeout.
After a cooldown period, the circuit "half-opens" to test if the service has recovered.

These patterns don't eliminate the problem of synchronous coupling.
They reduce the impact.
If you need true independence between services, you need asynchronous communication.

👉 Read original article on my newsletter: https://antondevtips.com/blog/synchronous-vs-asynchronous-communication-in-microservices

.NET Aspire Integration Testing Best Practices for Distributed Applications

Anton Martyniuk — Thu, 17 Sep 2026 17:55:13 +0000

A while ago, I published an article about ASP.NET Core Integration Testing Best Practices.
WebApplicationFactory, TestContainers, and Respawn simplifies integration testing in .NET Core applications.

But .NET Aspire simplifies the process further for distributed applications.

.NET Aspire replaces both WebApplicationFactory and TestContainers with a single tool: DistributedApplicationTestingBuilder.
You no longer need to set up Docker containers manually or override environment variables.
Aspire handles service discovery, container orchestration, and connection strings for you.

In this post, I will share the best practices I discovered while writing integration tests for a distributed Aspire application with multiple APIs, PostgreSQL, and Redis.

In this post, we will explore:

The System We Will Be Testing
Best Practice 1: Use DistributedApplicationTestingBuilder Instead of WebApplicationFactory
Best Practice 2: Share the App Instance Across Tests with ICollectionFixture
Best Practice 3: Wait for Resources to Be Healthy
Best Practice 4: Wait for Services to Start before Running Tests
Best Practice 5: Cleanup Database Between Tests
Best Practice 6: Test your API Contracts
Best Practice 7: Test Error Responses and Cross-Service Communication

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/dotnet-aspire-integration-testing-best-practices-for-distributed-applications

The System We Will Be Testing

I have built a distributed system with two APIs orchestrated by .NET Aspire:

Products API: manages products, supports CRUD operations and purchasing. Uses PostgreSQL and Redis for caching. Calls the Stocks API to check and update stock levels during purchases.
Stocks API: manages stock inventory for products. Uses PostgreSQL.

Both APIs share the same PostgreSQL server but use separate database schemas.

Here is the Aspire AppHost that defines the architecture:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres")
    .WithDataVolume(isReadOnly: false);

var redis = builder.AddRedis("cache");

var stocksApi = builder.AddProject<Projects.Stocks_Api>("stocks-api")
    .WithReference(postgres)
    .WaitFor(postgres)
    .WithExternalHttpEndpoints();

builder.AddProject<Projects.Products_Api>("products-api")
    .WithReference(stocksApi)
    .WaitFor(stocksApi)
    .WithReference(postgres)
    .WaitFor(postgres)
    .WithReference(redis)
    .WaitFor(redis)
    .WithExternalHttpEndpoints();

builder.Build().Run();

The Products API depends on the Stocks API for inter-service communication.
When a user purchases a product, the Products API calls the Stocks API via HTTP to verify stock availability and update the count.

Both APIs use EF Core with PostgreSQL and run database migrations on startup.

Now let's explore how to write integration tests for this system.

Best Practice 1: Use DistributedApplicationTestingBuilder Instead of WebApplicationFactory

In my previous article, I used WebApplicationFactory together with TestContainers to spin up Docker containers for PostgreSQL and RabbitMQ.

With .NET Aspire, you don't need either of these.
Aspire provides DistributedApplicationTestingBuilder, which replaces both tools with a single, unified approach.

With the traditional approach, your test project references the API project directly:

<ProjectReference Include="..\Products.Api\Products.Api.csproj" />

With Aspire, your test project references the Aspire AppHost project instead:

<ProjectReference Include="..\AspireNetConf.AppHost\AspireNetConf.AppHost.csproj" />

This means you test the entire distributed application, not just a single API in isolation.

To create a test project, you can use the ready Aspire Test Project template:

You can install the Aspire project templates by running the following command:

dotnet new install Aspire.ProjectTemplates

You will also need to install the Aspire CLI:

dotnet tool install --global aspire.cli

The testing project installs the Aspire.Hosting.Testing NuGet package.

This one package replaces multiple packages from the traditional approach:

Microsoft.AspNetCore.Mvc.Testing (WebApplicationFactory)
Testcontainers.PostgreSql (TestContainers for PostgreSQL)
Testcontainers.RabbitMq (or other container packages)

To create the distributed application in your tests, use DistributedApplicationTestingBuilder:

var appHost = await DistributedApplicationTestingBuilder
    .CreateAsync<Projects.AspireTests_AppHost>();

var app = await appHost.BuildAsync();
await app.StartAsync();

This starts the entire Aspire application, including all containers and services.

To create HTTP clients for your APIs, use CreateHttpClient with the resource name from your AppHost:

var productsClient = app.CreateHttpClient("products-api");
var stocksClient = app.CreateHttpClient("stocks-api");

No need to configure base URLs or connection strings.
Aspire handles service discovery automatically.

👉 Read original article on my newsletter: https://antondevtips.com/blog/dotnet-aspire-integration-testing-best-practices-for-distributed-applications

Optimistic vs Pessimistic Concurrency in .NET

Anton Martyniuk — Tue, 15 Sep 2026 11:13:46 +0000

Almost everyone had this situation in production: a customer changed the delivery address on a shipment, saved it, saw the confirmation, and an hour later the old address is back.

You start investigating, and you don't see any errors or exceptions in the logs.
The request returned 200 OK, but the data is just wrong.

This is a lost update, and it's one of the most common bugs in production .NET systems.
It happens whenever two requests read the same row, change it in memory, and write it back.

I've debugged this exact bug in payment systems, warehouse software, and booking flows.
It never shows up in a unit or integration test, because the tests don't run two requests in the same millisecond (your integration test can actually test concurrent requests).

There are two classic ways to solve it: optimistic concurrency and pessimistic concurrency.
They solve the same problem with different assumptions, and picking the wrong one either kills your throughput or leaves the bug in place.

In this post, we will explore:

The Lost Update Problem
Optimistic Concurrency: Detect the Conflict
Handling DbUpdateConcurrencyException
Retrying Conflicts with a Resilience Pipeline
Pessimistic Concurrency: Lock the Row First
A Third Option: One Atomic Statement
Optimistic vs Pessimistic: Deep Comparison
How to Choose: A Decision Checklist

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/optimistic-vs-pessimistic-concurrency-in-dot-net

The Lost Update Problem

Here is the domain we'll use throughout the post: a shipment that a warehouse operator can edit.

public class Shipment
{
    public Guid Id { get; set; }
    public string Number { get; set; }
    public string Address { get; set; }
    public string Carrier { get; set; }
    public ShipmentStatus Status { get; set; }
    public List<ShipmentItem> Items { get; set; } = [];
}

And here is the update handler almost everyone writes first:

public async Task<Result> Handle(UpdateShipmentRequest request, CancellationToken ct)
{
    var shipment = await dbContext.Shipments
        .FirstOrDefaultAsync(s => s.Number == request.Number, ct);

    if (shipment is null)
    {
        return Result.NotFound($"Shipment '{request.Number}' not found");
    }

    shipment.Address = request.Address;
    shipment.Carrier = request.Carrier;

    await dbContext.SaveChangesAsync(ct);
    return Result.Success();
}

The code reads a row, changes it in memory, and writes it back.

Between the read and the write there is a gap. It's small, usually a few milliseconds, but it's real. Anything that happens inside that gap is invisible to this handler.

Now put two operators in that gap at the same time. One changes the address, the other changes the carrier:

Both requests got a success response, and both updated exactly one row. Neither of them did anything wrong on its own.

But the row ends up with the address "Amsterdam" and the carrier "UPS". Request A's address change is gone, and no one was notified.

This is what a lost update means: one writer silently overwrites another writer's change because it never saw it.

The first instinct is to wrap the handler in a transaction, and that doesn't fix it.

At the Read Committed isolation level, which is the default in PostgreSQL and SQL Server, both transactions read a valid committed row, and both writes succeed.
The database is doing exactly what you asked. You just never told it that the second write depended on the first read.

Serializable isolation does catch this, at the cost of serialization failures that you have to retry anyway.
If you want the full picture of what each level protects against, I covered it in Complete Guide to Transaction Isolation Levels in SQL.

The two techniques below fix the problem directly, and you can apply either one per use case.

Optimistic Concurrency: Detect the Conflict

Optimistic concurrency starts with the assumption that conflicts are rare.

So it doesn't lock anything. It lets both requests run at full speed and, at the moment of writing, makes the database check whether anyone changed the row in the meantime.

The mechanism is a concurrency token: a column whose value changes on every update. You read it together with the row, and your UPDATE statement carries it in the WHERE clause.

If the token in the database no longer matches the one you read, your UPDATE matches zero rows, and you know somebody got there first.

EF Core supports this out of the box, and you have three ways to configure it.

PostgreSQL, using the built-in xmin system column:

modelBuilder.Entity<Shipment>()
    .UseXminAsConcurrencyToken();

This is the cheapest option on PostgreSQL because xmin already exists on every row. You get concurrency checks without adding a column or writing a migration.

SQL Server, using a rowversion column:

modelBuilder.Entity<Shipment>()
    .Property<byte[]>("Version")
    .IsRowVersion();

SQL Server maintains the value itself on every update, so you never assign it in code.

Any provider, using your own token:

public class Shipment
{
    // ...
    public Guid Version { get; set; }
}

modelBuilder.Entity<Shipment>()
    .Property(s => s.Version)
    .IsConcurrencyToken();

A manual token is the one I reach for most often, and not because of provider portability. It's a plain Guid column, so it survives a round trip to a browser or a mobile client, which is exactly what a stateless web API needs.

You do have to change the value yourself. The cleanest place is a SaveChangesAsync override on the DbContext:

public override Task<int> SaveChangesAsync(CancellationToken ct = default)
{
    var entries = ChangeTracker.Entries<Shipment>()
        .Where(e => e.State is EntityState.Added or EntityState.Modified);

    foreach (var entry in entries)
    {
        entry.Entity.Version = Guid.NewGuid();
    }

    return base.SaveChangesAsync(ct);
}

Whichever option you pick, EF Core now generates a different UPDATE:

UPDATE shipments
SET address = @p0, carrier = @p1, version = @p2
WHERE id = @p3 AND version = @p4;

The version = @p4 predicate is the whole trick. EF Core sends the value it read, counts how many rows the statement actually changed, and throws a DbUpdateConcurrencyException when the answer is zero.

Here is the same race as before, with the token in place:

Request A still wins the race, exactly as it did before. The difference is that Request B now finds out rather than quietly replacing the value.

There's one part that's easy to miss in a web API. Your two requests don't share a DbContext, and they don't even overlap in time. The operator opens an edit form, thinks for two minutes, and submits.

For the check to mean anything, the version has to travel to the client and come back:

public sealed record ShipmentResponse(
    string Number,
    string Address,
    string Carrier,
    string Version);

public sealed record UpdateShipmentRequest(
    string Number,
    string Address,
    string Carrier,
    string Version);

Then you tell EF Core to use the client's version instead of the one you just read from the database:

dbContext.Entry(shipment)
    .Property(s => s.Version)
    .OriginalValue = Guid.Parse(request.Version);

shipment.Address = request.Address;
shipment.Carrier = request.Carrier;

await dbContext.SaveChangesAsync(ct);

Setting OriginalValue is what puts the client's version into the WHERE clause. Without this line, you're comparing the row against a value you read milliseconds ago, and the two minutes when the operator was typing go completely unchecked.

Now the write fails when it should. The next question is what to do about it.

👉 Read original article on my newsletter: https://antondevtips.com/blog/optimistic-vs-pessimistic-concurrency-in-dot-net

Building Event-Driven Microservices with Azure Service Bus in .NET

Anton Martyniuk — Fri, 11 Sep 2026 08:18:44 +0000

In Microservices Architecture, services need to communicate with each other.
The simplest approach is synchronous HTTP calls, but it creates tight coupling between services.
If one service is slow or unavailable, it affects all dependent services.

Message brokers solve this problem by enabling asynchronous, message-based communication between your services.
Services publish events to the broker, and other services consume them independently.

When you are working in Azure, you can use Azure Service Bus to implement a message broker.
It supports both point-to-point and publish-subscribe messaging patterns.

In this post, we will explore:

Azure Service Bus: Core Concepts
How To Create Azure Service Bus in Azure Portal
Setting Up Azure Service Bus with .NET Aspire
How to Publish and Consume Messages with Azure Service Bus
The Event-Driven Pipeline: Payments, Fraud Detection, and Notifications
Running the Application Locally with Azure Service Bus Emulator
Deploying Microservices to Azure with Aspire
Azure Service Bus vs Other Azure Messaging Services

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/building-event-driven-microservices-with-azure-service-bus-in-dotnet

Azure Service Bus: Core Concepts

Azure Service Bus is a fully managed enterprise message broker in the Azure Cloud.
It supports two messaging patterns: Queues and Topics with Subscriptions.

Queues

Queues implement point-to-point communication.
One sender sends a message, and one receiver processes it.
Each message is consumed by exactly one consumer.

Use queues when a message should be processed by a single service.
For example, sending a stock update command to the Stocks service.

Topics with Subscriptions

Topics with Subscriptions implement publish-subscribe communication.
One sender publishes a message to a topic, and multiple subscribers can each receive a copy of that message.
Each subscription acts as its own virtual queue.

Use topics when multiple services need to react to the same event.
For example, when a payment is processed, both the Fraud Detection service and the Notifications service may need to be notified.

Our solution has five microservices that communicate through Azure Service Bus:

Product-Service - manages products and handles purchases
Stock-Service - manages product stock levels
Payment-Service - processes payments and tracks their status
FraudDetection-Service - analyzes payments for fraud risk
Notification-Service - sends email notifications

Here is the message flow:

When a user purchases a product:

Product-Service publishes UpdateStockEvent to the update-stock queue and PurchaseCompletedEvent to the payment-created queue
Stock-Service consumes from update-stock and updates the stock count
Payment-Service consumes from payment-created, creates a payment record, and publishes PaymentRegisteredEvent to the payment-registered topic
FraudDetection-Service subscribes to the payment-registered topic, analyzes the payment, and publishes FraudDecisionEvent to the fraud-decision queue
Payment-Service consumes from fraud-decision, updates the payment status, and publishes PaymentProcessedEvent to the payment-processed topic
Notification-Service subscribes to the payment-processed topic and sends a notification

In our project, we use both:

Queues for update-stock, payment-created, and fraud-decision (one sender, one receiver)
Topics for payment-registered and payment-processed (one sender, multiple receivers)

How Messages Flow Through Service Bus

When a consumer receives a message, Service Bus does not delete it immediately.
It locks the message and hides it from other consumers for a configurable lock duration.

The consumer has that time to process the message and complete the call.
If it completes successfully, Service Bus deletes the message.
If the handler throws or the lock expires, Service Bus releases the message and makes it available for retry.

Service Bus tracks how many times a message has been delivered using the delivery count.
When the delivery count exceeds MaxDeliveryCount (default: 10), Service Bus automatically moves the message to the dead-letter queue.

At-least-once delivery is the core guarantee Service Bus provides.
A message will be delivered at least once, but in rare cases it may be delivered more than once — for example, if a network failure prevents the completion acknowledgement from reaching the Service Bus.
Your consumers must be idempotent: processing the same message twice must produce the same result.

Dead-Letter Queue

Every queue and every topic subscription has a built-in dead-letter sub-queue (DLQ).
Messages end up in the DLQ when:

The delivery count exceeds MaxDeliveryCount
Your code explicitly calls DeadLetterMessageAsync — for example, when a message is malformed, and retrying is pointless
The message TTL (time-to-live) expires before it is consumed

The DLQ is permanent — messages do not expire there.
You can inspect, replay, or archive them using the Azure Portal.

In production, monitor the DLQ message count and set up alerts.
A growing DLQ means something in your pipeline is consistently failing.

Duplicate Detection

Service Bus can automatically discard duplicate messages within a configurable time window.
Enable it on a queue or topic at creation time.

Service Bus tracks messages by their MessageId.
If a message with the same MessageId arrives within the duplicate detection window (default: 10 minutes), Service Bus silently drops it.

Use duplicate detection when your producer may retry sending — for example, after a timeout or a transient network failure.

Message Sessions

Sessions enable ordered, grouped processing of related messages.
Set a SessionId on each message to group them together.

Service Bus guarantees that all messages with the same SessionId are processed in order by a single consumer at a time.
No two consumers can process messages from the same session simultaneously.

Use sessions when order matters — for example, processing all state transitions for the same payment in sequence.
Sessions require RequiresSession = true on the queue or subscription.

How To Create Azure Service Bus in Azure Portal

First, create a new Azure Service Bus namespace in the Azure Portal.

Go to the Azure Portal and search for "Service Bus":

Create a new Service Bus namespace with the following settings:

Resource group: Choose your resource group or create a new one
Namespace name: Choose a globally unique name
Location: Select the region closest to your services
Pricing tier: Select Standard

The pricing tier is important.
The Basic tier only supports queues.
If you need topics and subscriptions (which we do), you must use at least the Standard tier.

For most development and production workloads, Standard is sufficient.
Choose Premium only if you need dedicated resources, virtual network integration, or messages larger than 256 KB.

👉 Read original article on my newsletter: https://antondevtips.com/blog/building-event-driven-microservices-with-azure-service-bus-in-dotnet

10 Rare SQL Features Every Developer Should Know

Anton Martyniuk — Tue, 08 Sep 2026 11:17:35 +0000

Most developers use maybe 20 percent of SQL's capabilities.

They write SELECT, JOIN, and GROUP BY, and stop there.

But SQL has a second layer - features that turn a page of application code or three separate queries into a single clean statement.

Senior developers reach for these all the time. Many junior and mid-level developers have never seen them.

None of them is new or obscure. They are sitting in the database you already use, waiting to be picked up.

Today, I want to show you 10 rare SQL features every developer should know.

In this post, we will explore:

Common Table Expressions (CTEs)
Window functions
LATERAL joins
GROUPING SETS, ROLLUP, and CUBE
The FILTER clause in aggregates
UPSERT with INSERT ... ON CONFLICT
JSON support
Computed / generated columns
TABLESAMPLE
Partial indexes

Let's dive in.

All queries in this post were tested on the PostgreSQL database. Most of these features exist in other databases too, though the exact syntax differs - I will note the main differences as we go.

👉 Read original article on my newsletter: https://antondevtips.com/blog/10-rare-sql-features-every-developer-should-know

1. Common Table Expressions (CTEs)

A complex query packed into a single statement is hard to read and even harder to change.

A Common Table Expression (CTE) lets you break that query into named, sequential steps using the WITH keyword. Each step reads like a temporary, named result you can build on.

WITH recent_shipments AS (
    SELECT
        s.id,
        s.number,
        s.carrier,
        s.status,
        s.created_at
    FROM shipments.shipments s
    WHERE s.created_at >= CURRENT_DATE - INTERVAL '30 days'
),
shipment_details AS (
    SELECT
        rs.number,
        rs.carrier,
        rs.status,
        COUNT(si.id) AS total_items,
        SUM(si.quantity) AS total_quantity
    FROM recent_shipments rs
    LEFT JOIN shipments.shipment_items si ON rs.id = si.shipment_id
    GROUP BY rs.number, rs.carrier, rs.status
)
SELECT
    number AS shipment_number,
    carrier,
    status,
    total_items,
    total_quantity
FROM shipment_details
ORDER BY total_quantity DESC;

This query has two named parts.

recent_shipments selects shipments from the last 30 days. shipment_details then builds on it, joining the items and aggregating counts and quantities. The final SELECT reads from the second CTE as if it were a table.

The result is a query you read top to bottom, like steps in a recipe, instead of using nested subqueries from the inside out.

CTEs also support recursion with WITH RECURSIVE, which is how you query hierarchical data like org charts and category trees.

A Common Table Expression can be used within a SELECT, INSERT, UPDATE, or DELETE statement.

2. Window Functions

Sometimes you need a calculation across related rows but still want every individual row in the result.

A GROUP BY collapses rows into one per group. A window function calculates across a set of rows - the window - while keeping each row intact.

SELECT
    number,
    carrier,
    created_at,
    ROW_NUMBER() OVER (PARTITION BY carrier ORDER BY created_at DESC) AS shipment_sequence,
    RANK() OVER (PARTITION BY carrier ORDER BY created_at DESC) AS shipment_rank
FROM shipments.shipments;

SELECT
    number,
    status,
    created_at,
    LAG(status) OVER (ORDER BY created_at) AS previous_status,
    LEAD(carrier) OVER (ORDER BY created_at) AS next_carrier
FROM shipments.shipments;

The first query ranks each carrier's shipments by date. ROW_NUMBER() gives a unique sequence within each carrier (the PARTITION BY carrier), and RANK() does the same, but ties share a rank.

The second query uses LAG and LEAD to look at the previous and next row in order - here, the previous status and the next carrier - without a self-join.

Window functions are how you build running totals, rankings, moving averages, and row-to-row comparisons.

They are standard SQL and work in PostgreSQL, SQL Server, Oracle, and MySQL 8+.

👉 Read original article on my newsletter: https://antondevtips.com/blog/10-rare-sql-features-every-developer-should-know

ASP.NET Core Output Cache: How to Speed Up Your API with In-Memory Cache and Redis

Anton Martyniuk — Mon, 07 Sep 2026 11:00:48 +0000

In ASP.NET Core, one of the most powerful and underused caching tools is the Output Cache middleware.

Though so many developers still don't know about it or how to use it effectively.

Output Cache is not the same as storing objects in IMemoryCache or IDistributedCache.
It operates at the HTTP response level, caching the full serialized response and serving it directly — without touching your handlers, your database, or your business logic.

The result is dramatically lower latency and reduced load on your infrastructure.

In this post, we will explore:

What Output Cache is and how it differs from IMemoryCache and IDistributedCache
How to set up Output Cache in ASP.NET Core
How to customize cache behavior with policies and options
How to evict cached responses using tags, keys, and full cache clearing
How to use Redis as the Output Cache store for distributed scenarios
How to handle caching safely in authenticated APIs to avoid leaking data between users

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/aspnetcore-output-cache-how-to-speed-up-your-api-with-in-memory-cache-and-redis

What Is Output Cache and How Does It Differ from Other Caches

IMemoryCache is an in-process, key-value store that lives in the memory of your application.

You use it to cache any .NET object — a list, a domain model, a computed value.
You control what gets stored, how it is serialized, and when it expires.

It is fast because there is no network hop.
But it is local to a single instance of your app, so it does not work across multiple servers without extra coordination.

public class OrderService(IMemoryCache cache, OrdersDbContext db)
{
    public async Task<List<OrderSummary>> GetOrdersAsync(CancellationToken ct)
    {
        return await cache.GetOrCreateAsync("orders:all", async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);

            return await db.Orders
                .Select(o => new OrderSummary(o.Id, o.Status, o.TotalAmount))
                .ToListAsync(ct);
        });
    }
}

IDistributedCache is an abstraction over an external cache store, usually Redis.
It stores byte arrays, so you serialize and deserialize your objects manually (or with a wrapper).

It works across multiple app instances because all instances share the same external store.
The downside is the added latency of a network call to the cache server.

Both IMemoryCache and IDistributedCache require you to write caching logic inside your service or handler.

You have to call the cache before your database query, check for a hit, store the result after a miss, and handle expiration yourself.
This adds boilerplate to every method you want to cache.

Output Cache works differently.

Instead of caching objects inside your application code, Output Cache intercepts the HTTP response at the middleware level.
It stores the full serialized response — the status code, headers, and body — and replays it on subsequent matching requests.

Your endpoint handler, database query, and business logic are never called when a cached response is available.
The middleware short-circuits the pipeline and writes the stored response directly.

This means you can add caching to existing endpoints with almost no changes to your application code.
You decorate an endpoint or controller with an attribute or a policy name, and the middleware handles the rest.

The built-in cache lock feature in Output Cache is particularly useful.
When multiple requests arrive for the same uncached resource at the same time, only one request is allowed through to execute the handler.

The others wait for the first response and then receive the cached copy.
This prevents the "thundering herd" problem, where a cache miss causes a spike of concurrent database queries.

Output Cache was introduced in .NET 7 and has been improved in further .NET versions.

Setting Up Output Cache in ASP.NET Core

To get started with Output Cache, install the following NuGet package:

dotnet add package Microsoft.AspNetCore.OutputCaching

var builder = WebApplication.CreateBuilder(args);

// Register OutputCache in DI
builder.Services.AddOutputCache();

var app = builder.Build();

// Add OutputCache Middleware
app.UseOutputCache();

app.MapControllers();

app.Run();

The middleware must be placed after UseRouting (if you call it explicitly) and before MapControllers or any Minimal API endpoints like MapGet.

Now, let's define a simple Orders API example:

[ApiController]
[Route("api/orders")]
public class OrdersController(OrdersDbContext db) : ControllerBase
{
    [HttpGet]
    [OutputCache]
    public async Task<IActionResult> GetOrders(CancellationToken ct)
    {
        var orders = await db.Orders.ToListAsync(ct);
        return Ok(orders);
    }

    [HttpGet("{id:guid}")]
    public async Task<IActionResult> GetOrder(Guid id, CancellationToken ct)
    {
        var order = await db.Orders.FindAsync([id], ct);
        if (order is null) return NotFound();
        return Ok(order);
    }
}

To cache the GetOrders endpoint, we add the [OutputCache] attribute.

With this one attribute, the first request to GET /api/orders will execute the handler, call the database and store the response.
Every subsequent request within the default expiration window (60 seconds) will receive the cached response without hitting the database.

You can also cache endpoints in Minimal APIs by calling .CacheOutput() on the RouteHandlerBuilder:

app.MapGet("/api/orders", async (OrdersDbContext db, CancellationToken ct) =>
{
    var orders = await db.Orders.ToListAsync(ct);
    return Results.Ok(orders);
}).CacheOutput();

👉 Read original article on my newsletter: https://antondevtips.com/blog/aspnetcore-output-cache-how-to-speed-up-your-api-with-in-memory-cache-and-redis

Entity Framework Extensions Options Explained: Everything You Can Customize

Anton Martyniuk — Fri, 04 Sep 2026 14:53:00 +0000

When working with Entity Framework Core, you will eventually need to perform bulk operations on large datasets.
Standard EF Core methods work well for small operations, but they become slow and inefficient when dealing with thousands of records.

Entity Framework Extensions is famous for its fastest bulk operations in the market.
It supports various database providers and provides methods for bulk insert, update, delete, merge, and synchronize operations.

But the real power of this library is not just speed.
Entity Framework Extensions is famous for its hundreds of available options.
These options will save you hours, or even days, of tedious coding that is prone to bugs.

In this post, we will explore the most important customizable options available in Entity Framework Extensions.
You will learn how to fine-tune bulk operations for various real-world scenarios.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/entity-framework-extensions-options-explained

Performing Bulk Insert with Entity Framework Extensions

I have been working on an interesting project that manages IoT devices and their telemetry data in the SQL Server database.

The database has three main tables:

Devices - Represent IoT devices with properties like name, serial number, device type, manufacturer, firmware version, hardware version, status, and configuration
Components - Represent components of these devices, such as sensors, and other hardware parts
Telemetry - Store telemetry data collected from these devices, including temperature readings, humidity levels, and other sensor values

In our ASP.NET Core application, we have three main entities: Device, Component, and Telemetry.

Imagine a scenario where your system needs to insert 10,000-50,000 telemetry records into the database every few minutes.

You can wait for minutes for this insert to happen with EF Core, but you don't have to.

Entity Framework Extensions solves this problem and provides lightning-fast bulk insert methods.

To get started with the Entity Framework Extensions library, you need to install the following NuGet package:

dotnet add package Z.EntityFramework.Extensions.EFCore

Here's how to bulk insert IoT devices into the database.

The Entity Framework Extensions library provides various extension methods for the DbContext class, such as BulkInsert.
Both async and sync versions of this method are available.

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10);

await dbContext.BulkInsertAsync(devices);

Entity Framework Extensions provides extensive configuration options to customize the behavior of bulk operations.

Entity Framework Extensions - Bulk Insert Options

The bulk insert method provides several options for customizing behavior. The method accepts an options delegate as a second parameter, allowing you to configure various settings.

Let's explore a few of the most important options.

Entity Framework Extensions - InsertIfNotExists Option

The InsertIfNotExists option allows you to insert only the entities that don't already exist in the database.

To demonstrate this behavior, first insert 10 IoT devices, then attempt to insert the same devices again with InsertIfNotExists enabled:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10);
await dbContext.BulkInsertAsync(devices);

// Insert the same 10 devices again with the InsertIfNotExists = true option
await dbContext.BulkInsertAsync(devices, options =>
{
    options.InsertIfNotExists = true;
});

The second insert operation prevents duplicate entries, ensuring that the 10 devices are not inserted again.

By default, the Entity Framework Extensions library matches the entities by their primary key.
In our case, in the Device entity, it will be the DeviceId.

But you can customize this behavior.

Entity Framework Extensions - Customizing Primary Key with ColumnPrimaryKeyExpression

The ColumnPrimaryKeyExpression option accepts a delegate that defines which property (or properties) to use for matching entities.

This option supports matching by any property or combination of properties. For example, IoT devices can be matched by serial number instead of the default primary key:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

await dbContext.BulkInsertAsync(devices, options =>
{
    options.InsertIfNotExists = true;
    options.ColumnPrimaryKeyExpression = d => d.SerialNumber;
});

Entity Framework Extensions - InsertKeepIdentity Option

The InsertKeepIdentity option allows you to insert custom identity values instead of letting the database generate them automatically. This is particularly useful when the Device entity uses a long type for the primary key in EF Core and a database identity in SQL Server.

Let's try to insert 2 devices with custom IDs:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(2);

devices[0].DeviceId = 1000;
devices[1].DeviceId = 1001;

await dbContext.BulkInsertAsync(devices, options =>
{
    options.InsertKeepIdentity = true;
});

The bulk insert operation preserves the custom identity values (1000 and 1001) instead of using database-generated values.

This option is particularly useful when you synchronize data from other services or external providers, and you want to keep your identity values in sync with those systems.

Entity Framework Extensions - AutoMapOutputDirection Option

The AutoMapOutputDirection option controls whether database-generated values are mapped back to the entity objects after insertion. By default, this option is set to true, which means primary keys and other database-generated columns are automatically populated:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10);
await dbContext.BulkInsertAsync(devices);

// After insertion, devices now have their DeviceId populated
foreach (var device in devices)
{
    Console.WriteLine($"Device ID: {device.DeviceId}");
}

The identity values for primary keys and any database-generated columns are automatically returned and mapped to the entity objects.

When database-generated values are not needed, setting AutoMapOutputDirection to false improves performance:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

await dbContext.BulkInsertAsync(devices, options =>
{
    options.AutoMapOutputDirection = false;
});

With this option disabled, the DeviceId property remains unpopulated after insertion, reducing overhead and improving performance.

Entity Framework Extensions - BulkInsertOptimized Method

The BulkInsertOptimized method provides an alternative to BulkInsert with built-in performance analysis capabilities.

While BulkInsertOptimized behaves similarly to BulkInsert with AutoMapOutputDirection = false, it offers a key advantage: it returns a BulkOptimizedAnalysis object containing performance hints and optimization recommendations.

Here is how to insert 10,000 devices with BulkInsertOptimizedAsync:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10_000);
await dbContext.BulkInsertOptimizedAsync(devices);

In this article, I explained in depth the performance difference between BulkInsertAsync and BulkInsertOptimizedAsync methods.

Entity Framework Extensions - IncludeGraph Option for Related Entities

The IncludeGraph option enables automatic insertion of related entities within an object graph. This feature is particularly useful when working with parent-child relationships, such as devices with their associated components.

Consider a scenario with 10 devices, each containing three components:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10);

foreach (var device in devices)
{
    device.Components = GenerateComponents(3);
}

The IncludeGraph option handles the insertion of the entire object graph, including all related entities:

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

await dbContext.BulkInsertAsync(devices, options =>
{
    options.IncludeGraph = true;
});

This option automatically inserts related entities from the graph of objects and preserves their relationships.

This is a very useful option, typically achieved with a single line of code in EF Core Extensions.
Imagine how much code you will write when using SQL Bulk Copy.

Entity Framework Extensions - AutoTruncate Option for String Length Management

The AutoTruncate option automatically truncates string values to match the maximum length defined in the Entity Framework mapping. When enabled, strings exceeding the database column length are trimmed before insertion, preventing length constraint violations.

// @nuget: Z.EntityFramework.Extensions.EFCore
using Z.EntityFramework.Extensions;

var devices = GenerateDevices(10);

foreach (var device in devices)
{
    device.HardwareVersion += " some long text that needs to be truncated by EF Core Extensions library";
}

await dbContext.BulkInsertAsync(devices, options =>
{
    options.AutoTruncate = true;
});

👉 Read original article on my newsletter: https://antondevtips.com/blog/entity-framework-extensions-options-explained

How Architects (Senior Devs) Choose a Database in 2026

Anton Martyniuk — Tue, 01 Sep 2026 11:13:25 +0000

Choosing a database is one of the most impactful decisions you make in a project.

It affects your application's performance, your monthly bill, and how often your team gets called at night.

When developers discuss databases, the conversation usually starts with product names: PostgreSQL, MongoDB, Redis.

Architects start differently. They first ask questions about the data, the team, and the budget. The product name is the last thing they decide.

Over the past years, I've built and scaled .NET systems using most of the databases on this list.
In this post, I'll break down every major database family: what each one is good at, what it really costs, and how to choose the right one for your project.

In this post, we will explore:

What an architect is actually choosing
Relational databases: PostgreSQL, MySQL and MariaDB
Commercial relational: SQL Server and Oracle
Embedded databases: SQLite
Document databases: MongoDB and RavenDB
Key-value and in-memory: Redis
Wide-column databases: Cassandra
Managed cloud databases
Cloud-native databases: DynamoDB and Cosmos DB
The specialized database families you should know exist
How to evaluate a database before you commit
Choosing a database in 2026

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-architects-choose-a-database-in-2026

What an Architect Is Actually Choosing

When you choose a database, you're not just choosing a product.

You're choosing how your system behaves when something fails, who fixes it at night, and how much you pay every month.

Here are 6 questions that decide the choice before any product is named:

1. What shape is the data, and how do you read it? Rows with relationships, documents that you read as a whole, or values fetched by a known key? This question eliminates most of the list, and it's about the shape of your data, not the scale. I covered this split in Getting Started with System Design.

2. What does a wrong answer cost? A stale like count costs nothing. A stale account balance costs money and trust. This answer sets your consistency requirement, and consistency is the most expensive property to guarantee.

3. What is your p99 latency under real load? The p99 is the response time that 99% of requests stay under. The average hides problems, so measure the p99 with your real query mix — that's what your slowest users actually experience.

4. Who supports the database in production? A managed service moves patching, failover and backups to the provider. Self-hosting moves them to your team. Both options are valid; you just need to know which one you're signing up for.

5. What does it cost at twice today's traffic? Consumption-based pricing looks cheap at the start, but it grows with every request. Per-core licensing is predictable, but it gets expensive when you scale out.

6. What does it cost to leave? When you lock in to a specific database, moving to another one can mean a complete application rewrite.

Notice that only the first question is about the database itself.
The other five are about your team and your organization.

There is one more question that most teams skip: do you need more than one database engine at all?

Each engine can be better at its own job. Still, each one also adds operational work: backups and restores, a high-availability setup, upgrades, monitoring dashboards, driver maintenance, and people who understand it during an incident.
That adds up to weeks of platform work per year, per engine.

Two rules help you keep this under control.

First, nominate one system of record per fact.
Every piece of data has exactly one authoritative home, and every other copy is a projection you can throw away and rebuild.

Second, never dual-write.
If your application writes to PostgreSQL and to a search index in the same request, one of those writes will eventually fail, and the two stores will silently diverge.
Write to the main system of record first, and propagate the change asynchronously through an outbox or change data capture.

Finally, add a new engine only when it's roughly few times better for your workload, not 20% better.

Now let's go through each database family, starting with the most popular one.

Relational Databases: PostgreSQL, MySQL and MariaDB

PostgreSQL is the default choice for most systems, and it's what I recommend to most teams.

It's a relational database that also stores JSON documents, runs full-text search, and handles geospatial queries.
That range is the reason most projects never need a second engine.

MySQL and its fork MariaDB solve a narrower problem well: simple, high-throughput reads on a well-indexed schema, with the shortest learning curve of the three.

Strengths:

One engine covers relational, document, search and geospatial workloads
Mature query tooling — pg_stat_statements shows you which query is slow in seconds
It's easy to hire developers who already know it

Weaknesses:

One write primary. Read replicas scale reads, but scaling writes means sharding or distributed SQL
Self-managed failover needs extra tooling; it's not built in
MySQL lags behind PostgreSQL on window functions, CTEs and richer types

Licensing: PostgreSQL uses the permissive PostgreSQL License and is free for any purpose.
MySQL is dual-licensed under GPLv2 or a commercial license, which you need if you bundle it inside closed-source software you distribute.
MariaDB Server is GPLv2, though its MaxScale proxy moved to a fully proprietary license in 2025.

Choose it when:

You're building a line-of-business application and have no measured reason to do otherwise
Your data has relationships and your reports aren't known in advance
You want the safest hiring and tooling story available

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-architects-choose-a-database-in-2026

Querying and Performing Transactions Across Multiple Database Schemas in a Modular Monolith

Anton Martyniuk — Sat, 29 Aug 2026 12:42:19 +0000

Building a Modular Monolith gives you clear boundaries between modules, but it also introduces a challenge: how do you query data that lives in different schemas?
And how do you maintain data consistency when a business operation spans multiple modules?

In a traditional monolith, you could join tables across the database.

But in a Modular Monolith, each module owns its schema.
Direct database access between modules breaks the boundaries you worked hard to establish.

I have been working with Modular Monoliths for years, and I have seen teams struggle with this exact problem.
They start with good boundaries, create separate schemas for each module, but then they need to show a report that combines data from three different modules. What do they do?

Some teams give up and start querying across schemas directly. Others try to solve it with complex event chains that are hard to debug.
And some just avoid the problem altogether by keeping everything in one module.

But there is a better way.

Today, I want to show you proven approaches for querying data across schemas and strategies for managing transactions in a Modular Monolith.

In this post, we will explore:

Why You Can't Join Tables Across Multiple Schemas
Recommended Approaches for Cross-Schema Queries Inter-module API Calls Domain Events with Eventual Consistency Database Views Composite View Pattern (BFF with YARP) Reporting/Analysis Module
Performing Transactions Across Multiple Schemas Domain Events for Eventual Consistency Transaction across EF Core DbContexts for Strong Consistency
Choosing Between Eventual and Strong Consistency

Let's dive in!

Why You Can't Join Tables Across Multiple Schemas

In a Modular Monolith, each module has its own database schema and DbContext in EF Core.
This separation is intentional. It enforces boundaries and makes it possible to extract a module into a microservice later.

But this separation creates two main challenges:

First, you cannot simply join tables across schemas in your queries. If you want to show shipment details along with carrier information and stock levels, you cannot write a single SQL or EF Core query that joins all three schemas.

Second, you cannot use a single database transaction that spans multiple modules.
If creating a shipment requires updating stock levels and registering with a carrier, you need a strategy to keep all three operations consistent.

Let me show you a concrete example.

Imagine you need to build a dashboard that shows:

All shipments created today
The carrier assigned to each shipment
Current stock levels for products in those shipments

In a traditional Monolith, you might write something like this:

var dashboard = await context.Shipments
    .Include(s => s.Stocks)
    .Include(s => s.Carriers)
    .Where(s => s.CreatedAt.Date == DateTime.UtcNow.Date)
    .Select(x => new
    {
        ShipmentNumber = x.Number,
        CarrierName = x.Carrier.Name,
        StockLevel = x.Stocks.First().Quantity
    })
    .ToListAsync();

But in a Modular Monolith, this code will not work. The ShipmentsDbContext does not know about Carriers or Stocks entities. They live in different schemas with different DbContexts.

So how do you solve this?

Recommended Approaches for Cross-Schema Queries

Inter-module API Calls

The most straightforward approach is to call other modules through their public APIs. Each module exposes an interface that other modules can use to query data.

This is the approach is the simplest and the cheapest.
It respects module boundaries and makes dependencies explicit.

Let's say you need to display shipment details with carrier information. Here is how you would implement it:

First, the Carriers module exposes a public API:

public interface ICarrierModuleApi
{
    Task<CarrierDetailsResponse?> GetCarrierByNameAsync(
        string carrierName, 
        CancellationToken cancellationToken = default);
}

Now in the Shipments module, you can create a handler that combines data from multiple modules:

internal sealed class GetShipmentDetailsHandler(
    ShipmentsDbContext context,
    ICarrierModuleApi carrierApi,
    IStockModuleApi stockApi)
{
    public async Task<ErrorOr<ShipmentDetailsResponse>> HandleAsync(
        string shipmentNumber,
        CancellationToken cancellationToken)
    {
        // 1. Get shipment from the local database
        var shipment = await context.Shipments
            .Include(s => s.Items)
            .FirstOrDefaultAsync(s => s.Number == shipmentNumber, cancellationToken);

        if (shipment is null)
        {
            return Error.NotFound("ShipmentNotFound", $"Shipment {shipmentNumber} not found");
        }

        // 2. Get carrier details from the Carriers module
        var carrierDetails = await carrierApi.GetCarrierByNameAsync(
            shipment.Carrier, 
            cancellationToken);

        // 3. Get stock levels for each product from the Stocks module
        var stockLevels = new Dictionary<string, int>();
        foreach (var item in shipment.Items)
        {
            var stockResponse = await stockApi.GetStockLevelAsync(item.Product, cancellationToken);
            if (stockResponse.IsSuccess)
            {
                stockLevels[item.Product] = stockResponse.Quantity;
            }
        }

        // 4. Combine all data into the response
        return new ShipmentDetailsResponse
        {
            ShipmentNumber = shipment.Number,
            OrderId = shipment.OrderId,
            Status = shipment.Status.ToString(),
            CreatedAt = shipment.CreatedAt,
            Carrier = carrierDetails,
            Items = shipment.Items.Select(i => new ShipmentItemDetails
            {
                Product = i.Product,
                Quantity = i.Quantity,
                CurrentStockLevel = stockLevels.GetValueOrDefault(i.Product, 0)
            }).ToList()
        };
    }
}

This approach has several advantages:

Clear boundaries: each module controls what data it exposes
Type safety: you work with strongly typed interfaces
Easy to test: you can mock the module APIs in unit tests
Flexible: each module can change its internal implementation without affecting others

But it also has some drawbacks:

Multiple database queries: you make separate calls to each module
N+1 query problem: if you need to enrich a list of shipments with carrier details, you will make one query per shipment

For most scenarios, this approach works well. If you have a few items, the performance overhead is usually acceptable, especially when you add caching or support for bulk operations.

Domain Events with Eventual Consistency

Sometimes you need to query data that does not change frequently.
In these cases, you can duplicate the data across modules using integration events.

This approach works well when you need to denormalize data for read performance.

Let's say you want to display the carrier name on the shipment list without having to call the Carriers module each time.
You can store the carrier name directly in the Shipments schema.

When a carrier is updated in the Carriers module, it publishes an event:

public sealed record CarrierUpdatedEvent(
    Guid CarrierId,
    string CarrierName,
    string ContactEmail,
    bool IsActive) : IEvent;

internal sealed class UpdateCarrierHandler(
    CarriersDbContext context,
    IEventPublisher eventPublisher)
    : IUpdateCarrierHandler
{
    public async Task<ErrorOr<CarrierResponse>> HandleAsync(
        UpdateCarrierRequest request,
        CancellationToken cancellationToken)
    {
        var carrier = await context.Carriers
            .FirstOrDefaultAsync(c => c.Id == request.CarrierId, cancellationToken);

        if (carrier is null)
        {
            return Error.NotFound("CarrierNotFound", "Carrier not found");
        }

        carrier.ContactEmail = request.ContactEmail;
        carrier.PhoneNumber = request.PhoneNumber;
        carrier.IsActive = request.IsActive;

        // Publish event for other modules
        var carrierUpdatedEvent = new CarrierUpdatedEvent(
            carrier.Id,
            carrier.Name,
            carrier.ContactEmail,
            carrier.IsActive);

        await eventPublisher.PublishAsync(carrierUpdatedEvent, cancellationToken);

        await context.SaveChangesAsync(cancellationToken);

        return carrier.MapToResponse();
    }
}

The Shipments module subscribes to this event and updates its local copy:

internal sealed class UpdateShipmentCarrierDetailsEventHandler(
    ShipmentsDbContext context)
    : IEventHandler<CarrierUpdatedEvent>
{
    public async Task HandleAsync(
        CarrierUpdatedEvent @event,
        CancellationToken cancellationToken)
    {
        var shipments = await context.Shipments
            .Where(s => s.CarrierName == @event.CarrierName)
            .ToListAsync(cancellationToken);

        foreach (var shipment in shipments)
        {
            shipment.CarrierContactEmail = @event.ContactEmail;
            shipment.UpdatedAt = DateTime.UtcNow;
        }

        await context.SaveChangesAsync(cancellationToken);
    }
}

Now you can query shipments with carrier details in the Shipments module without having to call the Carriers module.

This approach has the following advantages:

Fast queries: all data is in one schema, no joins needed
No runtime dependencies: modules do not need to call each other during queries
Better performance: single database query instead of multiple calls

But it comes with trade-offs:

Eventual consistency: data might be temporarily out of sync
Data duplication: you store the same data in multiple places
More complex: you need to handle events and keep data synchronized

Use this approach when read performance is critical and you can accept eventual consistency.
This approach also allows you to change and scale each module independently.

When using events - I highly recommend using Open Telemetry to monitor your application.

Database Views

Database views provide a way to query data across multiple schemas at the database level. You create a view that joins tables from different schemas, and then map it to a read-only entity in EF Core.

This approach works well for reporting and analytics scenarios where you need to combine data from multiple modules.

Let's create a view that combines shipments with carrier information:

CREATE VIEW shipments_report_view AS
SELECT 
    s.Id,
    s.Number,
    s.OrderId,
    s.Status,
    s.CreatedAt,
    c.Name AS CarrierName,
    c.ContactEmail AS CarrierContactEmail,
    c.PhoneNumber AS CarrierPhoneNumber,
    c.IsActive AS CarrierIsActive
FROM Shipments.Shipments s
LEFT JOIN Carriers.Carriers c ON s.Carrier = c.Name
WHERE c.IsActive = 1;

You can map this view to a read-only entity in EF Core. Create a separate DbContext for read models:

public class ShipmentWithCarrier
{
    public Guid Id { get; set; }
    public string Number { get; set; }
    public string OrderId { get; set; }
    public string Status { get; set; }
    public DateTime CreatedAt { get; set; }
    public string CarrierName { get; set; }
    public string CarrierContactEmail { get; set; }
    public string CarrierPhoneNumber { get; set; }
    public bool CarrierIsActive { get; set; }
}

public class ReadModelsDbContext(DbContextOptions<ReadModelsDbContext> options)
    : DbContext(options)
{
    public DbSet<ShipmentWithCarrier> ShipmentsWithCarriers { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<ShipmentWithCarrier>()
            .HasNoKey()
            .ToView("shipments_report_view");
    }
}

Now you can query the view from your handler:

var shipments = await context.ShipmentsWithCarriers
    .OrderByDescending(s => s.CreatedAt)
    .Take(request.PageSize)
    .ToListAsync(cancellationToken);

return shipments.Select(s => new ShipmentWithCarrierResponse
{
    ShipmentNumber = s.Number,
    OrderId = s.OrderId,
    Status = s.Status,
    CreatedAt = s.CreatedAt,
    CarrierName = s.CarrierName,
    CarrierContactEmail = s.CarrierContactEmail,
    CarrierPhoneNumber = s.CarrierPhoneNumber
}).ToList();

This approach has the following advantages:

Single query: the database handles the join, so you get all data in one query
Good performance: database views are optimized by the query planner
Simple code: you query the view like a regular table
No application-level joins: the database does the heavy lifting

But it has some limitations:

Breaks module boundaries: the view directly accesses multiple schemas
Database coupling: modules are coupled at the database level
Harder to extract to microservices: you need to remove the view first
Schema changes require view updates: if you change a table structure, you need to update the view

Use database views for reporting and analytics when performance is critical, and you do not plan to extract modules into microservices soon.

I recommend using a separate database user for the database views with restricted permissions.

Composite View Pattern (BFF with YARP)

The Composite View Pattern, also known as Backend for Frontend (BFF), involves creating a separate service that aggregates data from multiple modules.
This service sits between your frontend and your Modular Monolith.

This approach is particularly useful when you have complex UI requirements that need data from many modules.

In our case, we can create a BFF service that queries multiple modules and combines the results. To access this BFF service, we use YARP as an API Gateway.

YARP (Yet Another Reverse Proxy) is a reverse proxy toolkit from Microsoft that you can use to route requests to different services.
I have written a detailed guide on how to set up YARP as an API Gateway. You can read it here: YARP as API Gateway in .NET.

Here is how the architecture looks:

Frontend calls YARP Gateway
YARP routes requests to either the main Modular Monolith or the BFF service
BFF service queries the Modular Monolith modules and aggregates the data
BFF returns the combined response to the frontend

Let's create a BFF service that provides a dashboard view:

public class ShipmentDashboardService(
    IHttpClientFactory httpClientFactory)
{
    public async Task<ShipmentDashboardResponse> GetDashboardAsync(
        CancellationToken cancellationToken)
    {
        var client = httpClientFactory.CreateClient("ModularMonolith");

        // Query shipments from the Shipments module
        var shipmentsResponse = await client.GetAsync(
            "/api/shipments?pageSize=10", 
            cancellationToken);
        var shipments = await shipmentsResponse.Content
            .ReadFromJsonAsync<List<ShipmentResponse>>(cancellationToken);

        // Query carriers from the Carriers module
        var carriersResponse = await client.GetAsync(
            "/api/carriers", 
            cancellationToken);
        var carriers = await carriersResponse.Content
            .ReadFromJsonAsync<List<CarrierResponse>>(cancellationToken);

        // Query stock levels from the Stocks module
        var stocksResponse = await client.GetAsync(
            "/api/stocks/summary", 
            cancellationToken);
        var stockSummary = await stocksResponse.Content
            .ReadFromJsonAsync<StockSummaryResponse>(cancellationToken);

        // Combine all data into a dashboard view
        return new ShipmentDashboardResponse
        {
            ...
        };
    }
}

The BFF service exposes its own API endpoint:

public class DashboardEndpoint : ICarterModule
{
    public void AddRoutes(IEndpointRouteBuilder app)
    {
        app.MapGet("/api/bff/dashboard", Handle);
    }

    private static async Task<IResult> Handle(
        ShipmentDashboardService dashboardService,
        CancellationToken cancellationToken)
    {
        var dashboard = await dashboardService.GetDashboardAsync(cancellationToken);
        return Results.Ok(dashboard);
    }
}

This approach has the following advantages:

Separation of concerns: the BFF handles UI-specific data aggregation
Reduced frontend complexity: the frontend makes one call instead of many
Optimized for UI: you can shape the response exactly as the UI needs it
Independent scaling: you can scale the BFF separately from the main application
Better performance for frontend: fewer HTTP calls from the browser

But it has some drawbacks:

Additional service: you need to deploy and maintain another application
Network overhead: the BFF makes HTTP calls to the main application
Duplication: you might duplicate some logic between the BFF and the main application

Use the BFF pattern when you have complex UI requirements that need data from many modules, or when you want to optimize the API for specific frontend needs.

P.S.: For BFF, I can highly recommend using GraphQL. It simplifies a lot of things.
If you are interested in GraphQL, you can read my article on HotChocolate GraphQL in .NET.

Reporting/Analysis Module

The final approach is to create a dedicated Reporting or Analysis module that has permission to query multiple schemas.
This module is the only one allowed to break the boundary rules.

This approach works well when you need complex reporting or analytics that require data from multiple modules.

The key is to enforce this rule with architecture tests.
You can use tools like NetArchTest to ensure that only the Reporting module can access multiple schemas.

I have written a detailed guide on architecture tests.
You can read it here: Why Do You Need to Write Architecture Tests in .NET.

With this approach you can create complex reports that join data from multiple modules.

To ensure that only the Reporting module can access multiple schemas, use separate database users for each module.
Configure connection strings with specific permissions:

{
  "ConnectionStrings": {
    "Shipments": "Server=localhost;Database=ModularMonolith;User Id=shipments_user;Password=***;",
    "Carriers": "Server=localhost;Database=ModularMonolith;User Id=carriers_user;Password=***;",
    "Stocks": "Server=localhost;Database=ModularMonolith;User Id=stocks_user;Password=***;",
    "Reporting": "Server=localhost;Database=ModularMonolith;User Id=reporting_user;Password=***;"
  }
}

Grant the reporting user read access to all schemas, while other users only have access to their own schemas.

This approach has the following advantages:

Powerful queries: you can write complex SQL joins across all schemas
Good performance: single database query with proper indexes
Centralized reporting: all reporting logic is in one place

But it has some limitations:

Breaks module boundaries: the Reporting module knows about other modules' schemas
Database coupling: modules are coupled at the database level
Requires discipline: without architecture tests you can break the module boundaries
Schema changes impact reporting: if you change a table structure, you need to update reports

Use this approach when you need complex reporting and analytics, and you can accept that one module has special privileges.

Performing Transactions Across Multiple Schemas

Querying data across schemas is one challenge, but maintaining data consistency when you modify data in multiple modules is another.

When you create a shipment, you need to update stock levels and register with a carrier.
All three operations should succeed or fail together.
But each module has its own DbContext and schema.

How do you ensure consistency?

You have two main strategies: eventual consistency with domain events, or strong consistency with a shared transaction.

Domain Events for Eventual Consistency

The first strategy is to use domain events.
One module completes its local transaction and publishes an event.
Other modules subscribe to this event and perform their own local transactions in response.

This results in eventual consistency.
All parts of the system will eventually be consistent, but they might be temporarily out of sync.

Let's see how this works with the CreateShipment use case:

internal sealed class CreateShipmentHandler(
    ShipmentsDbContext context,
    IStockModuleApi stockApi,
    IEventPublisher eventPublisher)
    : ICreateShipmentHandler
{
    public async Task<ErrorOr<ShipmentResponse>> HandleAsync(
        CreateShipmentRequest request,
        CancellationToken cancellationToken)
    {
        // 1. Check if the shipment already exists
        // 2. Check stock levels (read-only operation)
        // 3. Save the shipment in the local database

        var shipment = new Shipment { ... };

        await context.Shipments.AddAsync(shipment, cancellationToken);

        // 4. Publish an event for other modules to react
        var shipmentCreatedEvent = new ShipmentCreatedEvent(...);
        await eventPublisher.PublishAsync(shipmentCreatedEvent, cancellationToken);

        await context.SaveChangesAsync(cancellationToken);

        return shipment.MapToResponse();
    }
}

Now the Carriers and Stocks module subscribes to the ShipmentCreatedEvent.

This approach has the following advantages:

Loose coupling: modules do not depend on each other directly
Resilience: if one module fails, others can continue
Scalability: you can process events asynchronously
Easy to add new handlers: you can add new modules that react to the same event

But it has some challenges:

Eventual consistency: data might be temporarily out of sync
Error handling: if an event handler fails, you need a retry mechanism
Debugging: it is harder to trace the flow of execution
Complexity: you need to handle partial failures and compensating transactions

For better reliability, you should implement the Outbox pattern.
This pattern stores events in the same database transaction as your business data, and then publishes them in a separate process. This ensures that events are never lost.

In a production system, you might use a robust event messaging bus such as RabbitMQ.

TransactionManager for Strong Consistency

The second strategy is to use a shared transaction across multiple DbContexts.
This gives you strong consistency: either all operations succeed, or all fail together.

To implement this, you need a TransactionManager that coordinates the transaction across multiple modules.

Here is the TransactionManager implementation:

public interface ITransactionManager
{
    IDbContextTransaction? CurrentTransaction { get; }

    SetTransaction(IDbContextTransaction transaction);

    Task CommitTransactionAsync(CancellationToken cancellationToken = default);
    Task RollbackTransactionAsync(CancellationToken cancellationToken = default);
}

public class TransactionManager : ITransactionManager
{
    private IDbContextTransaction? _currentTransaction;

    public IDbContextTransaction? CurrentTransaction => _currentTransaction;

    public void SetTransaction(IDbContextTransaction transaction)
    {
        _currentTransaction = transaction;
    }

    public async Task CommitTransactionAsync(CancellationToken cancellationToken = default)
    {
        if (_currentTransaction == null)
        {
            throw new InvalidOperationException("No transaction in progress");
        }

        try
        {
            await _currentTransaction.CommitAsync(cancellationToken);
        }
        finally
        {
            _currentTransaction.Dispose();
            _currentTransaction = null;
        }
    }

    public async Task RollbackTransactionAsync(CancellationToken cancellationToken = default)
    {
        if (_currentTransaction == null)
        {
            return;
        }

        try
        {
            await _currentTransaction.RollbackAsync(cancellationToken);
        }
        finally
        {
            _currentTransaction.Dispose();
            _currentTransaction = null;
        }
    }
}

builder.Services.AddScoped<ITransactionManager, TransactionManager>();

Now update your DbContexts to use the shared transaction:

public class ShipmentsDbContext : DbContext
{
    private readonly ITransactionManager _transactionManager;

    public ShipmentsDbContext(
        DbContextOptions<ShipmentsDbContext> options,
        ITransactionManager transactionManager) : base(options)
    {
        _transactionManager = transactionManager;
    }

    public DbSet<Shipment> Shipments { get; set; }
    public DbSet<ShipmentItem> ShipmentItems { get; set; }

    public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
    {
        // If there is a shared transaction, use it
        if (_transactionManager.CurrentTransaction != null && Database.CurrentTransaction == null)
        {
            await Database.UseTransactionAsync(
                _transactionManager.CurrentTransaction.GetDbTransaction(), cancellationToken);
        }

        return await base.SaveChangesAsync(cancellationToken);
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        modelBuilder.HasDefaultSchema(DbConsts.ShipmentsSchemaName);
    }
}

Do the same for CarriersDbContext and StocksDbContext.

Now you can use the TransactionManager in your handler:

public async Task<ErrorOr<ShipmentResponse>> HandleAsync(
    CreateShipmentRequest request,
    CancellationToken cancellationToken)
{
    // Start a shared transaction
    var transaction = await shipmentsContext.Database.BeginTransactionAsync(cancellationToken);
    transactionManager.SetTransaction(transaction);

    // ...

    await stocksContext.SaveChangesAsync(cancellationToken);
    await shipmentsContext.SaveChangesAsync(cancellationToken);
    await carriersContext.SaveChangesAsync(cancellationToken);

    await transactionManager.CommitTransactionAsync(cancellationToken);

    return shipment.MapToResponse();
}

This approach has the following advantages:

Strong consistency: all operations succeed or fail together
ACID guarantees: you get the full benefits of database transactions
Simpler error handling: if anything fails, everything rolls back
Easier to reason about: the flow is linear and predictable

But it has some drawbacks:

Tight coupling: the handler needs to know about all DbContexts
Breaks module boundaries: you are directly accessing other modules' DbContexts
Harder to extract to microservices: you need to remove the coupled transaction

Use this approach when you absolutely need strong consistency and cannot accept any temporary inconsistency.

I recommend using a separate database user for this kind of TransactionManager that is not available to other modules.

👉 Read original article on my newsletter: https://antondevtips.com/blog/querying-and-performing-transactions-across-multiple-database-schemas-in-a-modular-monolith