DEV Community: Anton Martyniuk

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

YARP as an API Gateway in .NET: 7 Real-World Scenarios You Should Know

Anton Martyniuk — Fri, 28 Aug 2026 19:12:14 +0000

Building modern distributed applications requires a robust API Gateway to manage traffic, security, and routing.

YARP (Yet Another Reverse Proxy) is Microsoft's high-performance reverse proxy built on ASP.NET Core.
You can use it as a flexible and extensible foundation for building API Gateways in .NET.

It features high performance and integrates seamlessly with ASP.NET Core.
And it's pretty simple to set up.

If you are using Ocelot, consider that YARP provides improved performance and more efficient integration with ASP.NET Core, making it a stronger choice for .NET environments.

If you use complex API Gateways such as Traefik or Envoy, YARP can serve as a simpler solution if advanced features are unnecessary.

In this post, we will explore:

Getting Started with YARP
Using YARP as an API Gateway for Microservices
Load Balancing Across Service Instances
Centralized Authentication and Authorization
Request Routing and Path Rewriting
YARP as Backend-For-Frontend (BFF) Gateway
Traffic Shaping and Rate Limiting
Observability and Centralized Logging
Additional Scenarios You Might Consider

Let's dive in.

Getting Started with YARP

YARP is a reverse proxy toolkit developed by Microsoft for building fast and customizable proxy servers using ASP.NET Core infrastructure.

Unlike traditional API Gateway solutions with fixed features, YARP offers building blocks you can compose for your needs.

Why choose YARP:

Built on ASP.NET Core, using the same high-performance infrastructure
Fully extensible through middleware and custom transformations
Configuration can be loaded from appsettings.json, C# code, or external sources
Supports dynamic configuration updates without restarting the application
Integrates seamlessly with existing ASP.NET Core features like authentication, logging, and health checks
Open source and actively maintained by Microsoft
Available as a Docker container

Getting started with YARP is easy.

First, create a new ASP.NET Core Web API project and install the YARP NuGet package:

dotnet add package Yarp.ReverseProxy

Here is how to configure YARP in your Program.cs file:

var builder = WebApplication.CreateBuilder(args);

// Add YARP services
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

var app = builder.Build();

// Map YARP routes
app.MapReverseProxy();

app.Run();

This minimal setup lets YARP read the reverse proxy configuration from appsettings.json and sets up all the necessary routing.

Let's create a simple reverse proxy that forwards requests to a backend service.

Add this configuration to your appsettings.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ReverseProxy": {
    "Routes": {
      "products-route": {
        "ClusterId": "shipments-cluster",
        "Match": {
          "Path": "/products/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "shipments-cluster": {
        "Destinations": {
          "destination1": {
            "Address": "https://localhost:5001/"
          }
        }
      }
    }
  }
}

In this configuration:

Routes define how incoming requests are matched and which cluster handles them
Match.Path uses pattern matching - {**catch-all} captures everything after /products/
Clusters define groups of backend destinations
Destinations specify the actual backend service addresses

When a client sends a request to https://127.0.0.1:5000/products/123 (assuming you run your YARP application on port 5000), YARP forwards it to https://localhost:5001/products/123.

You can also configure YARP entirely in code if you prefer:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddReverseProxy()
    .LoadFromMemory(
        routes: new[]
        {
            new RouteConfig
            {
                RouteId = "products-route",
                ClusterId = "shipments-cluster",
                Match = new RouteMatch
                {
                    Path = "/products/{**catch-all}"
                }
            }
        },
        clusters: new[]
        {
            new ClusterConfig
            {
                ClusterId = "shipments-cluster",
                Destinations = new Dictionary<string, DestinationConfig>
                {
                    {
                        "destination1",
                        new DestinationConfig
                        {
                            Address = "https://localhost:5001/"
                        }
                    }
                }
            }
        });

var app = builder.Build();

app.MapReverseProxy();

app.Run();

This approach provides identical functionality with full code control, useful for dynamic configurations.

YARP supports loading the proxy configuration from multiple sources. LoadFromConfig may be called multiple times, referencing different IConfiguration sections from different config files, or it may be combined with a different config source, such as InMemory.

In YARP, code-based configuration loaded via IProxyConfigProvider generally takes priority or can override appsettings.json.

Now that you have YARP set up, let's explore real-world scenarios where it's helpful.

API Gateway for Microservices

In a microservices architecture, you have multiple services, each handling a specific business boundary.
An API Gateway acts as a single entry point for all client requests, routing them to the appropriate backend service.

Without an API Gateway, clients need to know the address of every microservice. This creates tight coupling and makes it difficult to change service locations or add new services.

YARP solves this by providing a unified endpoint that routes requests based on path patterns.

Let's build an API Gateway for three microservices:

Shipment Service - manages shipments and their states (runs on port 5001)
Stock Service - handles stock updates (runs on port 5002)
User Service - manages users (runs on port 5003)

Here is the complete appsettings.json configuration:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Yarp": "Information"
    }
  },
  "ReverseProxy": {
    "Routes": {
      "products-route": {
        "ClusterId": "shipments-cluster",
        "Match": {
          "Path": "/api/shipments/{**catch-all}"
        }
      },
      "orders-route": {
        "ClusterId": "stocks-cluster",
        "Match": {
          "Path": "/api/stocks/{**catch-all}"
        }
      },
      "customers-route": {
        "ClusterId": "users-cluster",
        "Match": {
          "Path": "/api/users/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "shipments-cluster": {
        "Destinations": {
          "products-service": {
            "Address": "https://localhost:5001/"
          }
        }
      },
      "stocks-cluster": {
        "Destinations": {
          "orders-service": {
            "Address": "https://localhost:5002/"
          }
        }
      },
      "users-cluster": {
        "Destinations": {
          "customers-service": {
            "Address": "https://localhost:5003/"
          }
        }
      }
    }
  }
}

With this configuration:

Requests to https://gateway:5000/api/shipments/123 route to the Shipments Service
Requests to https://gateway:5000/api/stocks/456 route to the Stocks Service
Requests to https://gateway:5000/api/users/789 route to the Users Service

The {**catch-all} pattern captures the entire path after the prefix, including any additional segments and query strings.

Load Balancing Across Service Instances

When your application scales, you may need to run multiple instances of the same service to handle increased traffic.
Load balancing spreads incoming requests across these service instances to ensure no single instance becomes overwhelmed.

YARP provides built-in load balancing strategies that automatically distribute traffic across multiple destinations within a cluster.

Load Balancing Strategies

YARP supports several load balancing policies:

PowerOfTwoChoices (default) - picks two random destinations and chooses the one with fewer active requests
RoundRobin - spreads requests evenly across all destinations in sequence
Random - randomly selects a destination for each request
FirstAlphabetical - always picks the first destination alphabetically (useful for testing)
LeastRequests - routes to the destination with the fewest active requests

Here is how you can configure load balancing for the Shipment Service running on three instances:

{
  "ReverseProxy": {
    "Routes": {
      "products-route": {
        "ClusterId": "shipments-cluster",
        "Match": {
          "Path": "/api/shipments/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "shipments-cluster": {
        "LoadBalancingPolicy": "RoundRobin",
        "Destinations": {
          "shipment-service-instance-1": {
            "Address": "https://localhost:5001/"
          },
          "shipment-service-instance-2": {
            "Address": "https://localhost:5011/"
          },
          "shipment-service-instance-3": {
            "Address": "https://localhost:5012/"
          }
        }
      }
    }
  }
}

With this configuration, YARP distributes requests evenly across all three instances using the Round-Robin strategy.

Health checks let YARP route traffic only to healthy instances.
If an instance fails its health check, YARP automatically stops sending requests to it until it recovers.

First, install the health checks package:

dotnet add package Microsoft.Extensions.Diagnostics.HealthChecks

Configure health checks in appsettings.json:

{
  "ReverseProxy": {
    "Routes": {
      "products-route": {
        "ClusterId": "shipments-cluster",
        "Match": {
          "Path": "/api/shipments/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "shipments-cluster": {
        "LoadBalancingPolicy": "RoundRobin",
        "HealthCheck": {
          "Active": {
            "Enabled": true,
            "Interval": "00:00:10",
            "Timeout": "00:00:05",
            "Policy": "ConsecutiveFailures",
            "Path": "/health"
          },
          "Passive": {
            "Enabled": true,
            "Policy": "TransportFailureRate",
            "ReactivationPeriod": "00:01:00"
          }
        },
        "Destinations": {
          "shipment-service-instance-1": {
            "Address": "https://localhost:5001/",
            "Health": "https://localhost:5001/health"
          },
          "shipment-service-instance-2": {
            "Address": "https://localhost:5011/",
            "Health": "https://localhost:5011/health"
          },
          "shipment-service-instance-3": {
            "Address": "https://localhost:5012/",
            "Health": "https://localhost:5012/health"
          }
        }
      }
    }
  }
}

Active Health Checks periodically send requests to the /health endpoint of each destination:

Interval - how often to check (every 10 seconds)
Timeout - how long to wait for a response (5 seconds)
Policy - when to mark a destination as unhealthy (after consecutive failures)
Path - the health check endpoint on the backend service

Passive Health Checks monitor actual traffic and mark destinations as unhealthy based on real request failures:

Policy - what triggers marking as unhealthy (transport failures like connection errors)
ReactivationPeriod - how long to wait before trying an unhealthy destination again (1 minute)

For this to work, your backend services need to expose a health check endpoint. See this article for how to add Health Checks in ASP.NET Core.

Sometimes you need to route requests from the same client to the same backend instance.
This is called session affinity or sticky sessions.

For more information, see the following article from official Microsoft documentation.

👉 Read original article on my newsletter: https://antondevtips.com/blog/yarp-as-api-gateway-in-dotnet

How to Validate Configuration in ASP.NET Core

Anton Martyniuk — Tue, 25 Aug 2026 11:17:44 +0000

Your app starts fine.
The first few requests work.
Then, hours later, one feature reaches for a setting that was never configured - and throws, deep in a request, far from the real cause.

I've been through this multiple times.

Configuration is just JSON or strings until you validate it.

ASP.NET Core can check your configuration the moment the app starts, so a typo in appsettings.json stops the app right away instead of returning a 500 Internal Error later.

There are two ways to do this: Data Annotations and FluentValidation.

In this post, we will explore:

Why configuration validation matters
Validate with Data Annotations
Fail fast at startup with ValidateOnStart
Validate with FluentValidation
Cross-field rules and named options
Data Annotations vs FluentValidation: when to use each

Let's dive in.

Why Configuration Validation Matters

Most apps bind configuration to a strongly typed class with the Options pattern.

Here is a settings class for talking to the GitHub API:

public sealed class GitHubSettings
{
    public string Token { get; set; } = string.Empty;
    public string BaseUrl { get; set; } = string.Empty;
    public int RetryCount { get; set; }
    public int RetryDelaySeconds { get; set; }
}

It is bound from appsettings.json:

{
  "GitHubSettings": {
    "Token": "ghp_xxx",
    "BaseUrl": "https://api.github.com",
    "RetryCount": 3,
    "RetryDelaySeconds": 2
  }
}

builder.Services
    .AddOptions<GitHubSettings>()
    .Bind(builder.Configuration.GetSection(nameof(GitHubSettings)));

This binds the section, but it does not check anything.

If Token is missing or RetryCount is 0, binding still succeeds - you get an empty string and a zero.
The problem only shows up later, when some code actually uses those values.

An empty Token sails through binding and only fails when you make your first GitHub call - as a 401, or a NullReferenceException three layers deep, with nothing pointing back to the real cause: a missing config value.

Validation closes that gap. It turns a silent, half-configured object into an immediate failure.

If the Options pattern is new to you, start with Master Configuration in ASP.NET Core with the Options Pattern.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/how-to-validate-configuration-in-aspnet-core

How to Avoid Code Duplication in Vertical Slice Architecture in .NET

Anton Martyniuk — Fri, 21 Aug 2026 08:24:27 +0000

Vertical Slice Architecture gives you incredible speed and flexibility by organizing code around features instead of technical layers.

Each slice encapsulates all aspects of a specific feature, including the API, business logic, and data access.
When you implement each feature, the necessary code stays together in the same folder or file.

Many developers were adopting Vertical Slice Architecture because of the following benefits:

Changes are isolated to specific features, reducing the risk of unintended side effects.
Other developers and teams to work on different features independently.
You can use different technologies or approaches within each slice as needed (aka CQRS on steroids).
It's easier to navigate in the solution, as all the code for a specific feature stays together.

I have built many projects using N-Layered and Clean Architecture, and one of the biggest challenges I faced was too much abstraction.
These types of Architectures often result in you creating a lot of premature abstractions that tend to solve some future problems:

What if a database might change in the future
What if we need to replace a messaging or logging library
What if this, what if that...

That's why I liked the Vertical Slice Architecture approach from the start.
I finally have the freedom to get rid of many premature abstractions and have the actual implementation sit in my slices.

But this freedom comes with a challenge: you can end up with a lot of code duplication:

Two slices need similar validation logic.
Three features query the same database table.
Five handlers format dates the same way.

That's why some devs critique Vertical Slice Architecture, saying it violates the DRY principle and encourages the WET Principle (write everything twice).

I have built a few projects with Vertical Slice Architecture in the last few years, and I want to show you my pragmatic approach to managing duplication.

In this post, we will explore:

Why Vertical Slice Architecture Leads to Code Duplication
Detecting Code Duplication
How to Avoid Duplication in Database Concerns
How to Avoid Duplication in Infrastructure Concerns
How to Avoid Duplication in Business Concerns
How to Avoid Duplication in Application Concerns
Decision Framework When Addressing Code Duplication

Let's dive in.

Why Vertical Slice Architecture Leads to Code Duplication

In traditional layered architecture, you organize code by technical concerns: Controllers, Services, Repositories, and Models.

When you need to add a new feature, you touch multiple layers. You add a controller method, a service method, a repository method, and maybe a DTO.

This structure naturally pushes you toward reuse.
If two features need similar logic, you put it in a shared service.
If three features query the same table, you add a method to the repository.

Vertical Slice Architecture flips this approach.

Each feature is a vertical slice that contains everything it needs: the endpoint, the handler, the validation, the data access, and the response model.

Here is what a typical VSA project structure looks like:

Each slice is independent. CreateShipment feature does not call GetShipmentByNumber and doesn't share code with other features.
This independence is the superpower of VSA. You can change one feature without worrying about breaking another.

But this independence also makes duplication visible.

If CreateShipment and ProcessShipment both need to validate that a product exists, you will write that validation twice.

But before addressing every code duplication case, you need to stop and think for a while.

Two pieces of code can look identical today and evolve in completely different directions tomorrow.

If you share them too early, you create coupling.
When one feature needs to change, you have to modify shared code that affects the other feature.

This is the cost of premature abstraction: you trade the flexibility to change one feature independently for the illusion of DRY code.

And the most important part is that most developers misunderstand DRY.
They think it's about removing duplicate code. It's not.

DRY is about duplicated knowledge, not the code.

Duplicate code is only a symptom. The real problem is duplicated business rules hiding across the system.

Here is where most teams get it wrong:

❌ They extract shared helpers too early.
❌ They create generic utilities that are hard to maintain
❌ They couple unrelated features just to reduce duplication.

This actually makes the code worse. Sometimes duplication is fine.

If two pieces of code change for different reasons, keep them separate.
This follows Single Responsibility better than forced reuse.

DRY is violated only when the same reason to change exists in multiple places.

Okay, enough theory.
Now, let's explore how we can avoid duplication and when and where we should extract shared code.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/how-to-avoid-code-duplication-in-vertical-slice-architecture-in-dotnet

Getting Started with System Design: 7 Key Decisions

Anton Martyniuk — Tue, 18 Aug 2026 11:49:59 +0000

Most developers learn system design in the wrong way, especially with the help of AI.

They usually study concepts such as load balancing, the CAP theorem, Kafka and Saga.
Something AI can explain.

But knowing the components is not the same as designing a system.

Every real system is the result of a handful of decisions and trade-offs, and each one costs you something.

For example:

Pick strong consistency, and you pay in latency.
Pick a queue, and you pay in debugging across multiple services.
Pick microservices, and you pay in premium operations.

Over the past years, I have built and scaled .NET systems that made every one of these choices, sometimes badly.
This is the short version of what I wish someone had handed me at the start.

In this post, we will explore the 7 decisions every system has to make:

How fresh does this data have to be?
Where should this data live?
Do you buy a bigger machine or more machines?
What do you cache, and where?
Should this be a call or an event?
What happens when more work arrives than you can handle?
How many things do you deploy?

Let's dive in.

How Fresh Does This Data Have To Be?

Most teams answer this once, for the whole system, and then live with the answer for years.
That is the mistake. Freshness is a per-data-type decision.

A payment balance and a product review count do not need the same guarantee.
Treating them the same means you either overpay for the reviews or underprotect the money.

These are the models you are actually choosing between:

Model	What you are promised	Typical use
Strong (linearizable)	Every read sees the latest committed write, from any node.	Bank balances, stock counts, leader election.
Read-after-write	A user always sees their own most recent write.	Your own post appearing in your own feed.
Monotonic reads	Once you see a value, you never see an older one again.	News feeds, where going backward looks broken.
Causal	If A caused B, every reader sees A before B.	Comment threads, chat messages.
Eventual	All replicas converge given enough time and no new writes.	Analytics counters, review totals.

Now the part most articles get wrong.
The CAP theorem says a distributed system can only guarantee two of Consistency, Availability, and Partition tolerance.

That "pick two of three" framing is the part Eric Brewer himself walked back in 2012.
Partition tolerance is not optional because networks fail, and a system that does not tolerate them just falls over.

So the real choice is binary, and only active during a partition.
Either you keep accepting writes and risk divergence (AP), or you refuse writes to protect correctness (CP).
CA databases do not exist in any meaningful sense.

Network partition happens

Can the system
safely guess?

Pick CP
Refuse the request

Pick AP
Answer anyway

Bank ledger
Booking seats
Leader election
Stock counts

Social feed
Shopping cart
DNS
CDN cache

A more honest everyday framing is PACELC:

Partition: choose Availability or Consistency.
Else: choose Latency or Consistency.

When the network is healthy, and it usually is, you trade consistency against latency on every write.
Synchronous quorum costs roughly 1-5 ms per write inside a region and 50-200 ms across regions, and a US East to Europe round trip is 80-100 ms before your code does anything.

CAP only shows up when something is on fire. PACELC is the tax you pay every day.

When you do have to pick a side for a specific piece of data, answer these four questions:

What is the cost of stale data? An old balance leads to a bad decision. An old like count leads to nothing.
What is the cost of downtime? If 30 seconds of unavailability costs thousands in lost sales, lean toward AP.
Can you reconcile later? Merging two shopping carts is easy. Merging two conflicting bank transfers is not.
How long do partitions last? Short ones favour CP. Long multi-region ones favor AP.

Most production systems use both CP for payments, orders, and auth tokens and AP for the catalog, recommendations, and activity tracking.

Once you know how fresh each piece of data must be, the list of databases that can hold it gets much shorter.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/getting-started-with-system-design

How to Set Up Production-Ready Monitoring With ASP.NET Core Health Checks

Anton Martyniuk — Fri, 14 Aug 2026 08:13:52 +0000

Deploying an application to production is only the beginning. You need to know whether your application is healthy and whether your database, cache, and message queue are reachable.

Without proper monitoring, you will only find out about issues when your users start complaining.

I have spent years building and maintaining high-load .NET systems, and health checks have always been my first line of defense. Today, I want to show you how to set up a production-ready monitoring system that gives you complete visibility into your application's health.

In this post, we will explore:

Why health checks matter for production applications
Adding health checks for Postgres, Redis, MongoDB, and RabbitMQ
Building custom health checkers
Building a custom JSON response formatter
Implementing a custom health check publisher
Setting up a professional Health Checks UI

Let's dive in.

Why Health Checks Matter

When you run an application in a modern environment like Kubernetes or Azure, the platform needs to know if your app is ready to handle traffic. This is where health checks come in.

A health check is a simple endpoint that returns the status of your application. If the database or message queue is down, the health check should report that the service is "Unhealthy".

Without health checks:

Load balancers might send traffic to a broken instance.
You won't know about database connection issues until users report errors.
Background tasks might stop running without anyone noticing.

ASP.NET Core provides a built-in framework for health checks. It allows you to check everything from database connections to external APIs and system resources.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/how-to-set-up-production-ready-monitoring-with-aspnetcore-health-checks

REST API Security Best Practices in ASP.NET Core

Anton Martyniuk — Tue, 11 Aug 2026 11:20:09 +0000

It does not matter how clean your architecture is or how fast your queries run - if an attacker can read another user's orders or forge a token, none of that matters.

Most API security problems come from skipping the basics:

Not updated NuGet package with security vulnerability
Missing validation check
Weak authentication setup
An over-permissive CORS policy
A secret committed to source control.

The good news is that ASP .NET Core gives you almost everything you need built in.

Over the years, I have shipped and reviewed many .NET APIs, and the same set of practices keeps them safe.

Here are 18 of them, each with the code to apply it.

In this post, we will explore:

Enforce HTTPS everywhere
Authenticate with tokens, not sessions
Validate the JWT signature, issuer, audience, and lifetime
Authorize with policies, not just [Authorize]
Apply the principle of least privilege
Validate and sanitize all input
Protect against over-posting / mass assignment
Validate content types and limit request size
Use parameterized queries and EF Core
Implement rate limiting and throttling
Configure CORS restrictively
Return minimal error detail
Set security headers
Store secrets securely
Enforce CSRF protection where relevant
Version your API and deprecate insecure endpoints
Log and audit security events
Keep dependencies patched

Let's dive in.

1. Enforce HTTPS Everywhere

Every request to your API should travel over an encrypted connection.

Without HTTPS, tokens, passwords, and personal data move in plain text, where anyone on the network path can read them.
Plain HTTP also opens the door to downgrade attacks, in which an attacker forces a client to use an insecure connection.

ASP .NET Core gives you two tools. UseHttpsRedirection redirects HTTP requests to HTTPS, and HSTS (HTTP Strict Transport Security) tells browsers to only ever connect over HTTPS:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHsts(options =>
{
    options.MaxAge = TimeSpan.FromDays(365);
    options.IncludeSubDomains = true;
    options.Preload = true;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseHsts();
}

app.UseHttpsRedirection();

UseHttpsRedirection upgrades any HTTP request to HTTPS.
UseHsts adds the Strict-Transport-Security header, so compliant browsers refuse to talk to your API over plain HTTP at all - which blocks downgrade attacks.

HSTS is skipped during development because you often use http://localhost.

For the full setup, see Configuring HTTPS Redirection and HSTS in ASP .NET Core.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/rest-api-security-best-practices-in-aspnetcore

How to Start a New .NET Project in 2026

Anton Martyniuk — Fri, 07 Aug 2026 08:16:35 +0000

Starting a new .NET project is exciting, but it can also be overwhelming. There are so many decisions to make, and the choices you make in the first few days will affect your project for months or even years.

I have created dozens of .NET projects over the years, and today I want to share my experience with you.

In this post, we will explore the following essential steps to start a new .NET project:

Set Project-Wide Standards
Add Static Code Analysis Packages
Enforce Coding Standards
Centralize Package Management
Simplify Local Development with Aspire
Setup OpenTelemetry
Automate Build and Testing with GitHub Actions
Project Template to Start With

Let's dive in.

1. Directory.Build.props - Set Project-Wide Standards

Every .NET solution should start with a Directory.Build.props file. This file defines project-wide settings that apply to all projects in your solution.

Without this file, you end up duplicating the same configuration across multiple .csproj files. When you want to change a setting, you have to update every project file manually. This leads to inconsistencies and wasted time.

Directory.Build.props solves this problem by centralizing configuration in one place. You create this file in the same directory as your .sln file, and MSBuild automatically applies it to all projects in the solution.

Here is the configuration I use for every new project:

<Project>
    <PropertyGroup>
        <Nullable>enable</Nullable>
        <ImplicitUsings>enable</ImplicitUsings>
        <AnalysisLevel>latest</AnalysisLevel>
        <AnalysisMode>All</AnalysisMode>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
        <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
        <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    </PropertyGroup>
</Project>

If needed, you can also put Directory.Build.props on any directory level in your project hierarchy and override settings there.

Here is what each setting does:

Nullable: Enables nullable reference types, which help prevent null reference exceptions. The compiler warns you when you might be using a null value incorrectly.

ImplicitUsings: Automatically includes common namespace imports in every file. You do not need to write using System; or using System.Linq; anymore.

AnalysisLevel: Sets the code analysis level to the latest version. You get the most recent code quality checks from Microsoft.

AnalysisMode: Enables all code analysis rules. This gives you the most comprehensive feedback on code quality.

TreatWarningsAsErrors: Prevents compilation if there are any warnings. This forces you to fix issues immediately rather than letting them accumulate.

CodeAnalysisTreatWarningsAsErrors: Applies the same strict treatment to code analysis warnings.

EnforceCodeStyleInBuild: Runs code style checks during build, not just in the IDE. Your CI/CD pipeline will catch style violations.

These settings create a strong foundation for code quality. They catch issues early and enforce consistency across your entire solution.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/how-to-start-a-new-dotnet-project-in-2026