DEV Community: Anton Martyniuk

All Types of Caching in .NET: When to Use Each (Deep Dive, Part 2)

Anton Martyniuk — Tue, 03 Nov 2026 12:07:40 +0000

In .NET, you have 6 ways to cache: IMemoryCache, IDistributedCache, Redis, HybridCache, FusionCache, and Output Cache.

This is the 2nd part of the Caching in .NET series.

Last week, in Part 1 we explored:

Where Each Cache Sits in a .NET App
In-Memory Cache (IMemoryCache) (Part 1)
Distributed Cache (IDistributedCache) with Redis (Part 1)
HybridCache (Part 1)

In this post, we will explore each caching option with pros, cons, pitfalls, and when to use it:

FusionCache
Output Cache
Which Cache Should You Choose

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part2

FusionCache

FusionCache is an open-source hybrid cache that existed years before HybridCache did.

It has the same L1 + L2 shape and the same stampede protection.
It also has what HybridCache lacks: a backplane that syncs L1 across instances, fail-safe, factory timeouts, and eager refresh.

FusionCache is the best caching option available in .NET today.

To get started with FusionCache, add these packages:

dotnet add package ZiggyCreatures.FusionCache
dotnet add package ZiggyCreatures.FusionCache.Serialization.SystemTextJson
dotnet add package ZiggyCreatures.FusionCache.Backplane.StackExchangeRedis
dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis

Then you can configure it in the DI container:

var redisConnection = builder.Configuration.GetConnectionString("Redis")!;

builder.Services.AddFusionCache()
    .WithDefaultEntryOptions(new FusionCacheEntryOptions
    {
        Duration = TimeSpan.FromMinutes(10),
        IsFailSafeEnabled = true,
        FailSafeMaxDuration = TimeSpan.FromHours(1),
        FactorySoftTimeout = TimeSpan.FromMilliseconds(300)
    })
    .WithSerializer(new FusionCacheSystemTextJsonSerializer())
    .WithDistributedCache(new RedisCache(new RedisCacheOptions
    {
        Configuration = redisConnection
    }))
    .WithBackplane(new RedisBackplane(new RedisBackplaneOptions
    {
        Configuration = redisConnection
    }));

Three building blocks are registered here:

Serializer for the L2 payload. System.Text.Json is the default choice.
Distributed cache as L2. This is the same RedisCache type from IDistributedCache.
Backplane as the channel that tells other instances about changes. It uses Redis pub/sub.

The handler uses IFusionCache:

internal sealed class GetShipmentByNumberHandler(
    ShipmentsDbContext dbContext,
    IFusionCache cache)
{
    public async Task<ShipmentResponse?> HandleAsync(
        string shipmentNumber,
        CancellationToken cancellationToken)
    {
        return await cache.GetOrSetAsync<ShipmentResponse?>(
            $"shipment:{shipmentNumber}",
            async (_, ct) => await dbContext.Shipments
                .Where(s => s.Number == shipmentNumber)
                .Select(s => s.MapToResponse())
                .FirstOrDefaultAsync(ct),
            tags: ["shipments"],
            token: cancellationToken);
    }
}

You can remove items by key or a tag, exactly like in HybridCache:

await cache.RemoveAsync($"shipment:{shipmentNumber}", token: cancellationToken);

The difference is what happens after that call on the other app instances:

The backplane message carries only the key and the action without a value.
Instance B drops its L1 (memory) copy, and the next read on B goes to L2 (Redis) and then to the database.

This is the direct fix for the biggest pitfall in HybridCache.

Using FusionCache as HybridCache

If your handlers already inject HybridCache, you don't have to rewrite them.
FusionCache can register itself as the HybridCache implementation:

builder.Services.AddFusionCache()
    .WithSerializer(new FusionCacheSystemTextJsonSerializer())
    .WithDistributedCache(new RedisCache(new RedisCacheOptions { Configuration = redisConnection }))
    .WithBackplane(new RedisBackplane(new RedisBackplaneOptions { Configuration = redisConnection }))
    .AsHybridCache();

So you continue using HybridCache in your classes.

Note: through the HybridCache adapter you can only pass HybridCacheEntryOptions per call. Fail-safe, timeouts, and eager refresh are configured once in the default entry options.

What Else FusionCache Gives You

I will only name the features here, since this library deserves its own article:

Fail-safe: when the database is down and the factory throws, FusionCache serves the last known value instead of an error.
Soft and hard timeouts: if the factory takes longer than the soft timeout and a stale value exists, the stale value is returned and the factory keeps running in the background.
Eager refresh: refresh an entry in the background before it expires, so hot keys never see a miss.
Adaptive caching: the factory can set the TTL per entry based on what it loaded.

FusionCache has the following advantages:

Backplane: L1 caches stay in sync across instances.
Resilience features: fail-safe and timeouts keep your API answering when dependencies are slow.
Drop-in for HybridCache: the AsHybridCache() adapter keeps your handlers on the Microsoft abstraction.
Mature: in production since 2021, well documented, active maintainer.

Here are the drawbacks of FusionCache:

Third-party dependency: one more package to track and upgrade.
Bigger configuration surface: more options means more ways to misconfigure.
Backplane needs Redis pub/sub: a managed Redis tier without pub/sub cannot run it.

Output Cache

Output Cache is middleware that stores the full HTTP response and serves it on the next matching request.

On a hit, your handler and your database never run.
This is the biggest win per line of code in ASP .NET Core, and I wrote a dedicated deep dive on Output Cache.

During registration, you define named policies:

builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("shipment-by-number", policy => policy
        .Expire(TimeSpan.FromMinutes(5))
        .SetVaryByRouteValue("shipmentNumber")
        .Tag("shipments"));
});

var app = builder.Build();

app.UseOutputCache();

After that, the endpoint can use it by name:

app.MapGet("/api/shipments/{shipmentNumber}", async (
    string shipmentNumber,
    GetShipmentByNumberHandler handler,
    CancellationToken cancellationToken) =>
{
    var shipment = await handler.HandleAsync(shipmentNumber, cancellationToken);
    return shipment is null ? Results.NotFound() : Results.Ok(shipment);
})
.CacheOutput("shipment-by-number");

SetVaryByRouteValue makes each shipment number its own cache entry.
For list endpoints, SetVaryByQuery("carrier", "status") does the same for query parameters.

Use Tag("shipments") to quickly evict items from a cache.
You can inject IOutputCacheStore and evict by tag:

internal sealed class UpdateShipmentStatusHandler(
    ShipmentsDbContext dbContext,
    IOutputCacheStore outputCache)
{
    public async Task HandleAsync(
        string shipmentNumber,
        ShipmentStatus status,
        CancellationToken cancellationToken)
    {
        var shipment = await dbContext.Shipments
            .FirstAsync(s => s.Number == shipmentNumber, cancellationToken);

        shipment.UpdateStatus(status);
        await dbContext.SaveChangesAsync(cancellationToken);

        await outputCache.EvictByTagAsync("shipments", cancellationToken);
    }
}

By default, Output Cache stores responses in memory, which brings back the two-instances problem.
For such cases, you will need Redis:

dotnet add package Microsoft.AspNetCore.OutputCaching.StackExchangeRedis

builder.Services.AddStackExchangeRedisOutputCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
});

Now every instance serves from the same cached responses, and EvictByTagAsync on one instance evicts for all of them.

Important note: ASP .NET Core also has the older Response Caching middleware (UseResponseCaching), which relies on Cache-Control headers sent by the client.
It is outdated for APIs. Clients can bypass it, you cannot evict by tag, and it does not support Redis.
Use Output Cache instead.

Output Cache has the following advantages:

Nothing runs on a hit: no handler, no serialization, no database.
Declarative: one attribute-like call per endpoint, policies in one place.
Tag-based eviction that works across instances with the Redis store.

Here are the drawbacks of Output Cache:

Whole-response granularity: you cache the entire payload or nothing. One changed field invalidates everything.
Only GET and HEAD, and only 200 responses, by default.
Authenticated requests are not cached by default. Requests with an Authorization header skip the cache entirely.

Output Cache Pitfalls

Caching per-user data without varying by user.
If you override the default and cache authenticated responses, you must vary by the user, or user A receives user B's shipments:

options.AddPolicy("my-shipments", policy => policy
    .Expire(TimeSpan.FromMinutes(1))
    .SetVaryByHeader("Authorization")
    .Tag("shipments"));

Varying by the Authorization header works, but every token is its own entry, so the hit rate drops as the user base grows.

Eviction lives in the write path.
Every handler that changes shipments must remember to evict the tag; otherwise, stale responses persist until they expire.
Put eviction in one place, such as a domain event handler, rather than in each write handler.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part2

How to Optimize SQL Queries: 20 Proven Best Practices

Anton Martyniuk — Fri, 30 Oct 2026 09:10:33 +0000

A slow SQL query is one of the easiest ways to ruin a fast application.

You can have a clean architecture, a great cache, and a powerful server - and still watch a page hang because one query scans a million rows without an index.

Over the years, I have optimized hundreds of SQL queries across many production systems.

Most of the wins come from the same small set of techniques, applied again and again.

Some of them are obvious.
Some of them go against advice you have probably heard.

To make them easy to remember, I have grouped 20 proven techniques into 6 themes you can reach for whenever a query gets slow.

In this post, we will explore:

Write index-friendly (sargable) queries
- Use indexes wisely
- Avoid functions on columns in WHERE
- Avoid leading wildcards in LIKE
- Match data types exactly
Fetch only the data you need
- Stop using SELECT *
- Filter early
- Paginate with Keyset instead of OFFSET
- Query only what changed
Simplify joins and subqueries
- Reduce JOIN complexity
- Choose the right JOIN type
- Replace redundant subqueries with JOINs or CTEs
- Prefer EXISTS over IN
Design your schema for reads
- Normalize wisely
- Use materialized views
Make writes and transactions efficient
- Batch large operations
- Keep transactions short
Let the database help you
- Read the execution plan
- Keep statistics up to date
- Use query hints sparingly
- Monitor and tune continuously

Let's dive in.

All queries in this post were tested on the PostgreSQL database. The same ideas apply to other databases, though the exact syntax may differ.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-optimize-sql-queries-20-proven-best-practices

Write Index-Friendly (Sargable) Queries

An index only helps if your query lets the database use it.

A "sargable" query (from Search ARGument ABLE) is one where the database can jump straight to the rows it needs through an index, instead of scanning the whole table.
The four techniques below keep your queries sargable.

1. Use Indexes Wisely

Indexes are the single biggest lever for read performance.

An index is a sorted data structure that lets the database find rows without scanning the entire table, much like the index at the back of a book saves you from reading every page.

Create indexes on the columns you filter, join, sort, and group by most often - the columns in your WHERE, JOIN, ORDER BY, and GROUP BY clauses.

When several columns are used together, a single composite index that covers them is far better than separate single-column indexes:

-- A composite index for frequent filters on status and order date
CREATE INDEX idx_orders_status_order_date
    ON orders (status, order_date);

This index speeds up queries that filter on status, and on status together with order_date.

Column order matters: an index on (status, order_date) helps queries that filter by status first, but not queries that filter by order_date alone.

You can also create a covering index that stores extra column values inside the index.
This helps when a query only needs columns available in the index, so the database can avoid reading the actual table rows.

It is especially useful for small, frequent lookup queries.

-- Cover a common read query without fetching rows from the table
CREATE INDEX idx_orders_status_order_date_covering
    ON orders (status, order_date)
    INCLUDE (customer_id, total_amount);

SELECT customer_id, total_amount
FROM orders
WHERE status = 'paid'
  AND order_date >= DATE '2026-01-01';

Note: indexes are not free. Every index must be updated on each insert, update, and delete, and it takes disk space. Index the columns your queries actually use, not every column.

For a deeper look at index types and trade-offs, see Optimizing SQL Performance with Indexing Strategies.

2. Avoid Functions on Columns in WHERE

Wrapping a column in a function is one of the most common ways to accidentally disable an index.

When you call a function on a column, the database has to compute that function for every row before it can compare it, so it cannot use the index on the raw column:

-- Bad: the function on order_date prevents an index scan
SELECT * FROM orders
WHERE EXTRACT(YEAR FROM order_date) = 2025;

Rewrite the condition to compare the raw column against a range. This keeps the query sargable and lets the index do its job:

-- Good: a sargable range over the raw column
SELECT * FROM orders
WHERE order_date >= '2025-01-01'
  AND order_date <  '2026-01-01';

Both queries return the same rows, but only the second can use an index on order_date.

The same rule applies to LOWER(email), CAST(...), and arithmetic on a column.
If you often need to filter on a computed value, create an expression index for that exact expression instead.

3. Avoid Leading Wildcards in LIKE

A LIKE pattern that starts with a wildcard cannot use a normal index.

The database reads an index from left to right, so it needs to know the beginning of the value.
A pattern like '%son' hides the beginning and forces a full scan:

-- Bad: leading wildcard forces a full table scan
SELECT * FROM customers
WHERE last_name LIKE '%son';

-- Good: a known prefix allows an index range scan
SELECT * FROM customers
WHERE last_name LIKE 'Anders%';

If you genuinely need to search inside text - a "contains" search - a normal B-tree index will not help.

Reach for full-text search or a trigram index (the pg_trgm extension in PostgreSQL) built for that job.

4. Match Data Types Exactly

Comparing two different data types forces the database to convert one of them, and that conversion can silently disable an index.

If a column is an integer but you compare it to a string, or you join an integer key to a bigint key, the database adds an implicit cast - and the index on the original column may be skipped.

Keep the types identical on both sides of every join and filter:

CREATE TABLE logs (
    log_id     int PRIMARY KEY,
    event_date timestamptz NOT NULL,
    user_id    int NOT NULL
);

Define logs.user_id to match the type of users.id so the join uses the index on both sides.

Matching types is a small detail at design time that saves you from a confusing, hard-to-spot scan later.

Fetch Only the Data You Need

The fastest data to process is the data you never read.

Every column and every row you pull costs disk I/O, memory, and network time. These four techniques shrink the result set as early and as much as possible.

5. Stop Using SELECT *

SELECT * pulls every column, including the ones you do not need.

That means more data to read from disk, more to send over the network, and more memory to hold - all for columns your code throws away.

It also blocks covering indexes, where the index alone can answer the query without touching the table:

-- Bad: fetches every column
SELECT * FROM customers;

-- Good: only the columns you use
SELECT customer_id, first_name, last_name
FROM customers;

Listing columns explicitly is also safer. Your query will not silently change shape or break when someone adds or reorders a column.

6. Filter Early

The smaller the dataset you work with, the faster everything downstream becomes.

You may have heard the common advice:

Apply your most selective filters to cut the number of rows before joins and aggregations have to process them:

SELECT o.order_id, o.total
FROM orders o
WHERE o.order_date >= '2025-01-01'
  AND o.order_date <  '2025-02-01';

Note: in most cases you do not have to place these filters by hand.
A modern cost-based planner already pushes predicates down - it applies your WHERE conditions as early as it can and reorders joins on its own.
Rewriting the textual order of a WHERE clause rarely changes the plan.

What actually helps is giving the planner a selective, sargable filter and an index to apply it with.
So focus on making the filter index-friendly, not on where you type it.

7. Paginate with Keyset instead of OFFSET - When you can

OFFSET looks like an easy way to implement pagination, but it gets slower the deeper you go.

To return page 1,000, the database still reads and throws away every row before it.
OFFSET 100000 means reading 100,000 rows just to skip them.

Keyset pagination (also called seek pagination) remembers the last value you saw and seeks straight past it:

-- Key-based pagination on an indexed column
SELECT *
FROM orders
WHERE order_id > 1000
ORDER BY order_id
LIMIT 10;

Each page costs the same, whether it is page 2 or page 2,000, because the index jumps directly to order_id > 1000.

The trade-off: keyset pagination gives you fast next- and previous-page navigation, but you can't implement random jumps to any page number.

8. Query Only What Changed

Re-reading an entire table on every run is wasteful when only a few rows have changed.

Track a watermark - the last point you processed - and fetch only the rows newer than it:

-- Fetch only records updated since the last run
SELECT *
FROM records
WHERE modified_date > '2025-05-20 00:00';

This incremental pattern turns a full-table scan into a small, indexed range read.

Index modified_date, store the new high-water mark after each run, and your sync job stays fast even as the table grows.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-optimize-sql-queries-20-proven-best-practices

EF Core and Azure SQL Database: A Step-by-Step Guide

Anton Martyniuk — Thu, 29 Oct 2026 13:36:27 +0000

EF Core is the most popular way to work with a database in .NET.

Azure SQL Database is the managed SQL Server you get in the cloud, with backups, patching, and high availability handled for you.

Putting the two together is straightforward, but the cloud adds a few things you never deal with on a local SQL Server.

Connections drop under load. The firewall blocks you by default. And a database password sitting in your connection string is a risk you want to remove before production.

Today I want to present you with a complete guide to getting started with Azure SQL Database in .NET.

In this post, we will explore:

What Azure SQL Database is
How to create an Azure SQL Database in the Azure Portal
Connecting EF Core to Azure SQL
Running EF Core migrations against Azure SQL
Adding connection resilience for transient faults
Setting up Azure SQL with .NET Aspire
Passwordless authentication with Microsoft Entra ID

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-and-azure-sql-database

What Is Azure SQL Database

Azure SQL Database is a fully managed database service built on the SQL Server engine.

Because it is the same engine, EF Core talks to it through the exact provider you already use for SQL Server.
You do not need a special "Azure" provider - only a connection string that points to the cloud.

Azure manages the parts you do not want to: the operating system, patching, backups, and failover.
You manage your schema and your data.

You pick from two main purchasing models:

Provisioned - a fixed amount of compute that is always on. Predictable cost for steady workloads.
Serverless - compute that scales automatically and pauses when idle. You pay per second of use, which is ideal for development and test environments.

First, let's create one.

Creating an Azure SQL Database in the Azure Portal

Follow these steps:

1. Open the Azure Portal, search for "SQL databases", and click Create.

2. On the next page, select your Azure subscription and click Create:

3. Enter your database name and set up a logical SQL server to host the database:

4. Create a new one, select a location, give it a unique name, set the identification method, and set an admin login and password.

5. For the compute tier, choose Serverless while you are testing.
It pauses when idle, so you only pay while you use it.

6. After the database is created, you need to open the firewall. By default, Azure SQL blocks every connection.

Go to the server's Networking settings, and add your client IP address so you can connect from your machine.
Turn on "Allow Azure services and resources to access this server" so apps you deploy in Azure can connect to it.

Note: The firewall is the most common reason a first connection fails. If you see a "Cannot open server" error, check that your current IP is in the firewall rules.

With the database ready, let's connect EF Core to it.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-and-azure-sql-database

How to Pass Any .NET Interview in 2026: A Complete Roadmap

Anton Martyniuk — Tue, 27 Oct 2026 18:39:15 +0000

Most .NET developers don't fail interviews because they aren't good enough.

They fail because nobody ever showed them the full map of what they are being measured against.

They learn whatever their current job needs, ship features for a few years, and assume that is enough.
Then they walk into a senior interview and get asked about things they have never had a reason to touch.

A senior interview covers a broad range of topics: the C# runtime, async, ASP .NET Core internals, EF Core, security, system design, and how you reason about trade-offs.
Miss a few of those areas, and a strong engineer can look unprepared.

The good news is that the surface is not infinite.
It is a known map, and you can cover it on purpose.

I have spent more than 13 years building production .NET systems, I am a Microsoft MVP, and I have helped tens of thousands of developers level up through my newsletter.

This is the exact roadmap I would follow today to pass a .NET interview at any level - and to keep advancing once you are already a Senior.

In this post, we will explore:

Step 1: Know your target and where you stand today
Step 2: Master the technical foundation (the full map)
Step 3: Build a portfolio that proves senior thinking
Step 4: Turn your GitHub into your portfolio
Step 5: Make LinkedIn bring interviews to you
Step 6: Win the interview itself

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-pass-any-dotnet-interview-in-2026

Step 1: Know your target and where you stand today

You cannot prepare for a target you have not defined.

A mid-level interview and a senior interview measure different things, and a lead interview shifts the bar again.

If you aim at the wrong level, you either over-prepare on trivia or walk in under-prepared on the things that actually matter.

Here is what each level is really measured on - and the signal an interviewer is actually watching for:

Mid-level: Can you write correct, clean code, use the framework properly, and finish a feature without constant hand-holding? What they see: you reach for the right tool and your code works.
Senior: Can you make decisions and defend them? Senior interviews probe trade-offs, failure modes, performance, and whether your design survives real load and a real team. What they see: you name the trade-off before anyone asks for it.
Lead and Staff: Can you own scope beyond a single service, mentor others, and design systems across boundaries? What they see: you scope the problem, not just the solution.

This matters even more in the AI era.
As AI writes most of the code, interviews shift from writing code to judging it.
The edge is no longer how fast you produce a CRUD endpoint - it is what tool and approach you would use, whether you can spot the bug, the security hole, or the wrong abstraction in code an AI just generated.

If you are already senior and want to advance, the trap is different.
You have deep knowledge in the few areas your current job covers, but quite a few gaps elsewhere.

List the topics you quietly hope won't come up.
That list is your study plan.
Moving up means turning those gaps into strengths and learning to talk about architecture and trade-offs, not just code.

Once you know the target, be brutally honest about where you stand against it.

Most developers overestimate the areas they use daily and are unaware of their blind spots.
The async questions feel easy, then a single question about ValueTask or the garbage collector exposes a gap they never knew existed.

So run a five-minute self-audit. For each area, answer one question out loud, with no notes:

C#: can you explain when a struct and record is a better choice than a class, and what boxing actually costs?
Async: can you explain what ConfigureAwait(false) does, and when it stops mattering?
ASP .NET Core: can you explain how model binding turns an HTTP request into your method parameters?
EF Core: can you explain why a specific query is slow, and how you would prove it?
Architecture: can you defend one design decision from your last project, with the trade-off you accepted?
Security: can you explain the difference between authentication and authorization with a concrete example?
Reliability: can you explain what your system does when a dependency it calls goes down?

Any question you stumble on is a gap. That is where your preparation time should go - not on the areas that already feel easy.

Note: The fastest way to waste preparation time is to keep studying what you already know. Find the gaps first, then study those.

If you want an honest baseline before you start, take the free .NET Developer Interview Test created by me.
It's a real interview run as tests; it adapts to how you answer the questions, increasing or decreasing their difficulty.

It scores you from Junior to Senior+ across the main areas and tells you exactly where to focus.
Once completed, you will receive a free report on your strengths and weaknesses and the knowledge gaps you need to fill.
In the report, you will find an explanation for each correct answer.

Once you know the target and your gaps, the next step is closing them - and that starts with the technical foundation.

Step 2: Master the technical foundation (the full map)

This is the part most people get wrong.
They study random videos and scattered blog posts and hope the topics eventually add up to a complete picture.

They never do.
A senior .NET interview draws from a surprisingly fixed set of areas.

Learn these on purpose, and very little will surprise you. For each area I have added the senior signal - the failure mode you are expected to explain, not just the topics you are expected to know:

C# language and runtime:
- Value vs reference types, boxing and unboxing, strings and immutability, generics and variance, records, pattern matching, and nullable reference types.
- Then how it actually runs: the CLR, the JIT, tiered compilation, and AOT.
- Senior signal: explain why a record that holds a List<T> still breaks value equality - the generated Equals compares the list by reference, not by its contents.
Async, threading, and memory:
- async/await and the state machine behind it, Task vs ValueTask, ConfigureAwait, and cancellation tokens.
- Then concurrency: locks, SemaphoreSlim, and channels.
- Then memory: the garbage collector, the large object heap, IDisposable, and Span<T>.
- Senior signal: explain why async void hides exceptions until they crash the process, and why blocking on .Result or .Wait() can deadlock.
ASP .NET Core:
- The host and the request pipeline, middleware, filters, model binding, Minimal APIs vs controllers, and dependency injection lifetimes (transient, scoped, singleton).
- Senior signal: explain why the order of UseAuthentication and UseAuthorization matters, and what quietly breaks if you swap them.
Data and EF Core:
- Change tracking, relationships, loading strategies, migrations, concurrency handling, and query performance.
- This is where a lot of senior interviews dig in, because it is where production systems hurt.
- A good warm-up is Top 10 Mistakes Developers Make in EF Core.
- Senior signal: explain how lazy loading turns one query into an N+1 storm, and when a projection or AsNoTracking is the fix.
API design and architecture:
- REST done properly, versioning, validation, and how to structure an application so it scales with the team.
- Two solid references are Best Practices for Building REST APIs and N-Layered vs Clean vs Vertical Slice Architecture.
- Senior signal: explain why a non-idempotent POST double-charges a customer when the client retries, and how an idempotency key prevents it.
Security and identity:
- Authentication vs authorization, JWT and refresh tokens, cookies, ASP .NET Core Identity, OAuth 2.0 and OpenID Connect, and CORS.
- Senior signal: explain why a JWT must be validated for signature, issuer, audience, and expiry - not just decoded - and why long-lived access tokens are risky without refresh-token rotation.
Performance and reliability:
- Caching layers, output caching, rate limiting, structured logging, health checks, and observability with OpenTelemetry.
- Senior signal: explain how retries without a circuit breaker turn a small outage into a full one, and how a cache stampede hammers the database when a hot key expires.

For each area, train yourself to answer the "why," not just the "how."

Anyone can recite that scoped services live for one request.
A senior explains what breaks when you inject a scoped service into a singleton, and why.

Note: Interviewers rarely want trivia. They want to see that you understand the trade-off behind a feature and can reason about it under pressure.

This is exactly the surface my .NET Senior Playbook was built to map.
It is 800+ questions across 54 chapters covering every area above, with a test after each chapter so you prove a topic you're stuck on instead of assuming it did.

Knowing the material is half the battle. The other half is proving it - and that starts with what you build.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-pass-any-dotnet-interview-in-2026

All Types of Caching in .NET: When to Use Each (Deep Dive, Part 1)

Anton Martyniuk — Tue, 27 Oct 2026 12:08:00 +0000

Your API is slow and Claude recommends you to add caching.

It adds IMemoryCache to the shipment tracking API, and the p95 latency drops from 120 ms to 5 ms.

Everyone is happy.

Then they scale to two instances.

A customer updates the delivery address, refreshes the page, and sees the old one.
Refreshes again and sees the new one. One more refresh, and the old address is back.

Nothing is broken. Each instance has its own memory, and only one of them knows that the address has changed.

Caching is the cheapest performance win in .NET, and one of the easiest things to get wrong.

The first and most important rule is: do not add caching to hide your slow database queries.
It's like fixing symptoms.

First, fix your database queries (the root cause), and only then add caching to increase your throughput and make your API even faster.

In .NET, you have 6 ways to cache: IMemoryCache, IDistributedCache, Redis, HybridCache, FusionCache, and Output Cache.

In this post, we will explore each caching option with pros, cons, pitfalls, and when to use it:

Where Each Cache Sits in a .NET App
In-Memory Cache (IMemoryCache)
Distributed Cache (IDistributedCache) with Redis
HybridCache
FusionCache (Part 2)
Output Cache (Part 2)
Which Cache Should You Choose (Part 2)

Let's dive in.

It's a very long newsletter (no one will read such a long article), so I will release PART 2 next week.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part1

Where Each Cache Sits in a .NET App

Every cache in .NET sits somewhere on the path between an HTTP request and your database.

Some sit in front of your code and cache whole HTTP responses.
Others sit inside your handlers and cache .NET objects, either in the memory of one process or in an external store shared by every instance.

Here is the full picture:

HTTP request
   │
   ▼
Output Cache (whole HTTP response) ──miss──┐
                                           ▼
Endpoint + Handler
   │
   ▼
L1: in-memory (IMemoryCache / HybridCache / FusionCache) ──miss──┐
                                                                 ▼
L2: distributed (IDistributedCache over Redis) ──miss──┐
                                                       ▼
Database

You need to know these three terms:

L1 cache is the memory of the current process. It is the fastest cache you can have because there is no network request and no deserialization.
L2 cache is an external store like Redis, shared by all instances of your app. Slower than L1 (but much faster than a database) and every instance sees the same data.
Cache stampede happens when many requests miss the cache at the same moment and all of them hit the database for the same key.

In this article, we will explore the shipments domain and we will cache shipments.

Here is the Minimal API endpoint that calls a handler, and the handler queries EF Core directly:

app.MapGet("/api/shipments/{shipmentNumber}", async (
    string shipmentNumber,
    GetShipmentByNumberHandler handler,
    CancellationToken cancellationToken) =>
{
    var shipment = await handler.HandleAsync(shipmentNumber, cancellationToken);
    return shipment is null ? Results.NotFound() : Results.Ok(shipment);
});

internal sealed class GetShipmentByNumberHandler(ShipmentsDbContext dbContext)
{
    public async Task<ShipmentResponse?> HandleAsync(
        string shipmentNumber,
        CancellationToken cancellationToken)
    {
        return await dbContext.Shipments
            .Where(s => s.Number == shipmentNumber)
            .Select(s => s.MapToResponse())
            .FirstOrDefaultAsync(cancellationToken);
    }
}

This query is already fast. We have indexed on the Shipment.Number field and we also select only the necessary fields.

Let's add a cache to this query.

In-Memory Cache (IMemoryCache)

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

You store any .NET object in it, and you get the same object reference back.
When you get items from an IMemoryCache, they don't require serialization and you don't need any network requests.

To use IMemoryCache in your application, add it into the DI container:

builder.Services.AddMemoryCache();

In the handler, we will use the cache-aside strategy on top of the database query:

internal sealed class GetShipmentByNumberHandler(
    ShipmentsDbContext dbContext,
    IMemoryCache cache)
{
    public async Task<ShipmentResponse?> HandleAsync(
        string shipmentNumber,
        CancellationToken cancellationToken)
    {
        return await cache.GetOrCreateAsync($"shipment:{shipmentNumber}", async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
            entry.SetSize(1);

            return await dbContext.Shipments
                .Where(s => s.Number == shipmentNumber)
                .Select(s => s.MapToResponse())
                .FirstOrDefaultAsync(cancellationToken);
        });
    }
}

GetOrCreateAsync first checks the cache, calls the database if the item is not found in the cache, and stores the result returned by the factory method.
The entry expires 10 minutes after it was written.

This is the fastest cache you can have in .NET.
A hit is a dictionary lookup that returns a reference. There is nothing to deserialize.

IMemoryCache has the following advantages:

Zero infrastructure: no Redis, no connection strings, nothing to deploy.
Fastest possible reads: a hit costs nanoseconds and allocates nothing.
Any object: you can cache types that are not serializable, including compiled regexes or large immutable lookup tables.

Here are the drawbacks of IMemoryCache:

Per-process only: two instances of your API have two separate caches that never talk to each other.
Lost on restart: every deployment starts with a cold cache.
Shares memory with your app: a cache that grows without a limit can cause memory issues.

IMemoryCache Pitfalls

There is no size limit by default.
SetSize(1) in the code above does nothing until you set a SizeLimit on the cache itself:

builder.Services.AddMemoryCache(options =>
{
    options.SizeLimit = 10_000;
});

The size unit is whatever you decide. Here, each shipment counts as 1, so the cache can hold at most 10,000 shipments.
Once you set SizeLimit, every entry must call SetSize, or the cache throws when you add it.

The cache hands out the same reference every time.
If a caller mutates the object it got from the cache, every later caller sees the mutation.
This is a classic source of bugs that only appear under load:

var response = await cache.GetOrCreateAsync(key, ...);
response.Items.Clear(); // every next request now gets a shipment with no items.

Cache immutable records, or return a copy.

There is no way to remove entries by prefix or tag.
IMemoryCache has Remove(key) and nothing else.
If you need to drop all cached shipments for an order, you need to store all the keys to be able to delete them.

GetOrCreateAsync has no stampede protection.
If 100 requests miss the same key at the same time, 100 factories run and 100 database queries execute.
IMemoryCache does not lock per key. You have to add a SemaphoreSlim yourself (bad!) or use a cache that does it for you.

When you scale to several instances, you need a store they all share.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part1

Claude Skills for .NET: Teach AI to Build Features Your Way

Anton Martyniuk — Fri, 23 Oct 2026 08:17:53 +0000

Every developer who uses AI has felt this.

You open a new chat.
You explain your architecture.
You explain your file naming.
You explain that you do not use repositories, prefer a rich domain model, and that your handlers and services return a Result<T>.

The AI writes good code.

The next day, you open another chat, and you explain it all over again.

This is the hidden tax of AI-assisted development.
You repeat the same instructions in every session for every feature.

A CLAUDE.md file helps; it's added to every session, but you can't make it with a lot of instructions (it should be 100 lines or less).
It holds the facts about your project and overall architecture, not the step-by-step recipe for every kind of task you do.

There is a better way: skills.

A skill packages a set of instructions, and even example files, that Claude loads only when it needs them.
You write the recipe once, and Claude follows it every time, in every session.

Skills also work if you are using the OpenAI Codex agent

In this post, we will explore:

What Claude skills are and why they beat repeating yourself
The building blocks of a skill
When a skill should trigger, and when it should not
How to create a skill with the Skill Creator
Where your skills live: Claude Code, Desktop, and CoWork
How to encode your project's conventions as skills
Skills for gRPC, GraphQL, messaging, and new services
The ready-made .NET skills published by Microsoft

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/creating-claude-skills-for-dotnet-apps

What Are Claude Skills (and Why They Beat Repeating Yourself)

A skill is a folder with instructions that Claude reads when a task matches.
it's placed in your repository root: .claude/skills/*

At its simplest, a skill is a single file called SKILL.md.
It has a short header that tells Claude what the skill does and when to use it, followed by the instructions themselves.

Here is a tiny skill:

---
name: create-endpoint
description: Create a new ASP.NET Core Minimal API endpoint following our project conventions.
Use whenever the user asks to add an endpoint, route, or API operation.
---

# Create a Minimal API Endpoint

1. Create the endpoint in `Features/<UseCase>/<UseCase>.Endpoint.cs`.
2. Implement `IApiEndpoint` and map the route from `RouteConsts`.
3. Call the handler, and convert a failed `Result<T>` with `ToProblem()`.

That is a complete, working skill.

When you ask Claude to "add an endpoint for canceling a shipment," it reads this skill and follows your steps, instead of inventing its own structure.

The difference between a skill and a one-off prompt is reuse.

A prompt lives and dies in a single chat session.
A skill is written once and then reused, shared, and version-controlled like any other file in your project.

This means every team member can use it.

Skills also keep your context small through progressive disclosure.

Claude always sees the skill's name and description, which is about one line of text.
It loads the full SKILL.md only when your task matches that description.
And it opens any bundled files only when it actually needs them.

This means you can have dozens of skills installed without flooding the model with text it does not need right now.
The skill remains quiet until it is useful.

Now that you know what a skill is, let's look at what goes inside one.

The Building Blocks of a Skill

Every skill is a folder. The only required file is SKILL.md.
Everything else is optional.

Here is the anatomy of a fuller skill:

create-feature/
├── SKILL.md            (required: instructions + when to use)
├── references/         (optional: detailed docs loaded on demand)
│   └── architecture.md
├── scripts/            (optional: scripts Claude can run)
│   └── scaffold.ps1
└── assets/             (optional: files used in the output)
    └── Endpoint.template.cs

The SKILL.md file has two parts.

The first part is the YAML frontmatter at the top, between the --- markers. Two fields matter most:

name - a short identifier in kebab-case, like create-feature.
description - one or two sentences that tell Claude what the skill does and when to use it.

This is the most important line in the skill because it determines when the skill triggers. We will cover that in the next section.

The second part is the Markdown body. This is where you write the actual instructions: the steps, the rules, the examples, and the things to avoid.

The references/ folder holds detailed documents that Claude reads only when needed. Keep SKILL.md short and focused, and push long material - a full coding standard, an API reference, a list of edge cases - into separate files.
Claude opens them on demand, so your main instructions stay easy to follow.

The scripts/ folder holds code Claude can run instead of writing it from scratch.
A PowerShell or bash script that scaffolds a folder, or a small script that formats output, belongs here.

The assets/ folder holds files used in the result, like a project template, a Dockerfile, or a .cshtml view.

Note: Keep SKILL.md short, ideally a few hundred lines at most. If it grows large, that is a signal to move the details into references/ and point to them from the body. A focused skill is easier for Claude to follow than one giant wall of rules.

A skill is only useful if Claude opens it at the right moment. Let's look at what controls that.

👉 Read original article on my newsletter: https://antondevtips.com/blog/creating-claude-skills-for-dotnet-apps

10 Tools Every .NET Developer Should Use in 2026

Anton Martyniuk — Fri, 23 Oct 2026 04:41:23 +0000

The developer toolkit looks very different in 2026 than it did just two years ago, or even a year ago.

AI is no longer a side feature you tap into occasionally.
It sits at the center of how you write code, design systems, run meetings, and learn new technologies.

Today, I want to tell you about the 10 tools I actually use with great success in 2026.
And can definitely recommend them to .NET developers, architects, and tech leads to help ship faster, think more clearly, and stop wasting hours on work that machines now handle better.

I receive many LinkedIn messages from people asking what tools I use to be more productive.
That's why I decided to create this newsletter issue.

If you only adopt a few of them this year, you will feel the difference in your daily workflow almost immediately.

P.S.: I'm not sponsored by any vendors of these tools to write this issue.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/10-tools-that-will-make-developers-more-productive-in-2026

AI Coding Assistants

The first wave of AI coding tools focused on autocompletion (like GitHub Copilot).
They suggested the next line or two of code based on what you just typed.

Today, you need tools that reason about your entire codebase, understand your architecture, and can execute multi-step tasks without constant hand-holding.
And most importantly, they produce high-quality code.

For a long time, GitHub Copilot was the default AI coding assistant. But many developers have moved on.

Copilot agent is fine, but it has the following drawbacks:

It's sitting in your IDE and is limited in what it can do on your PC
It has lower limits on using AI models (Claude, OpenAI) - then if you use these directly
Overall, the features and quality are lower than the competitors

Overall, there are two better AI agents:

Claude (best)
OpenAI Codex

1. Claude Code

It's an agentic coding tool that runs directly from your terminal or Desktop.
You describe what you want, and it works through the problem step by step.
It reads your files (on your PC, not just the solution), understands the context, makes changes, runs tests, and reports back.

Here is what makes Claude Code stand out for .NET developers:

Plan Mode

Before Claude writes any code, you can ask it to make a plan first.
It reads your project, thinks through the task, and presents a clear, step-by-step plan.

You review the plan, approve it, and only then does Claude start changing files.

This is a huge time-saver for bigger tasks.
You catch wrong assumptions early, before any line of code is written.

And what I really like is how Claude surveys me with different questions and recommended options each time I create a plan.

Quality of produced code

This is where Claude Code really stands out.

It reads your CLAUDE.md file at the root of the project and follows the rules it defines.
For .NET projects, that means it respects your Vertical Slice structure, uses Result<T> instead of throwing exceptions, applies primary constructors, and skips patterns you told it to avoid, like Repository or MediatR.

The most intelligent model is Claude Opus 4.7.
It is the most capable AI model for writing code in the market.

When using Opus, you spend less time cleaning up after the model and more time reviewing real logic.

Writing code in a separate branch

Claude Code can create a Git worktree and work on a separate branch in the background.

You keep coding on your main branch.
Claude builds a feature, fixes a bug, or runs a refactor on its own branch.
When it's done, you review the diff and merge it as you would any other pull request.

This is perfect for long-running tasks. You don't have to stop your own work to wait for the agent.

Code reviews

Claude Code can review your current diff or a full pull request.
It looks for real bugs, security issues, missing tests, and broken conventions.

You can run a quick review locally with the /code-review skill, or trigger /ultrareview for a multi-agent cloud review on harder pull requests.
Several specialized agents read the code in parallel and give you findings as inline comments on the PR.

It's like having a senior reviewer on call, every hour of the day.

Skills

A Skill is a small set of instructions you write once, and Claude loads on demand.

You can think of Skills as smart commands tuned for your team. Examples include:

A skill that drafts pull request descriptions in your team's format
A skill that scaffolds a new feature folder following your Vertical Slice rules
A skill that runs your release checklist before a deploy
A skill that writes integration tests using Testcontainers and Respawn

Anyone on the team can use a Skill without having to remember the steps.
The Skill remembers them.

You can easily build your own skills from any session with a built-in Claude skill creator tool.

Connectors

Claude Code connects to the systems you already use: GitHub, Jira, Slack, Figma, Google Drive, Notion, MongoDB, Postgres, AWS, and many more.

You can ask things like "show me the failing tests on PR 42" or "Create a JIRA ticket from this bug," and Claude pulls the data and acts on it.
The agent stops being a code-only tool and starts working with your whole stack.

Co Work

Cowork is not just about coding.
It gives Claude access to your PC (where you allow it, and it's pretty secure), so it can do almost any work you do at your desk.

You can ask Claude to:

Create a Word document with a project proposal
Generate a PDF report from your meeting notes
Build an Excel file with a budget, a roadmap, or a backlog
Organize your local documentation folder and rename files in a consistent way
Write a Business Requirements Document (BRD) for a new feature
Prepare a slide deck from your latest design notes
Fill out forms, rename screenshots, sort downloads, clean up your desktop
Delegate any task in your web browser. Like book 10 sits for a conference for your team.

For tech leads and architects, this is a real shift.

And the best part is that Cowork also supports remote sessions.
You can control Claude from your phone, check what it's doing, kick off new tasks, or review results while you're away from your laptop.

And you can also schedule tasks to run while you sleep; you just need your PC on.

Claude Models

Claude Code uses the Claude 4.X model family. You pick the right model for the job:

Claude Opus 4.7 — the most capable model. Best for hard tasks like complex refactors, big architecture changes, tricky debugging, and any work where quality matters more than speed. This is the model I use for the heavy lifting.
Claude Sonnet 4.6 — the balanced default. Fast enough for everyday coding, smart enough for most feature work. Great choice when you want speed and quality together.
Claude Haiku 4.5 — the fastest and cheapest model. Best for quick edits, simple lookups, small fixes, and high-volume tasks where you don't need deep reasoning.

You can use Claude as a plugin in Rider and VS Code, but honestly, they have limited capabilities compared to Claude Desktop.
This is why I recommend using Claude desktop, it works better and has way more features.

I wrote a detailed guide on using Claude for production development.

Pricing: Free tier available on claude.ai (doesn't include Claude Code). Paid plans start at Pro $20/month (or $17/month on the annual plan), with Max at $100/month and $200/month for heavier usage.

Download Claude Desktop here.

👉 Read original article on my newsletter: https://antondevtips.com/blog/10-tools-that-will-make-developers-more-productive-in-2026

Rate Limiting in ASP.NET Core: All 4 Algorithms Explained With Code

Anton Martyniuk — Tue, 20 Oct 2026 11:08:36 +0000

One misbehaving client is enough to take an API down.

It doesn't have to be an attacker.

A mobile app with a bug in its retry loop.
A partner integration that polls your endpoint every 100 milliseconds.
A script a colleague wrote to "quickly export the data".

Every one of those requests hits your database, your cache and your thread pool exactly like a legitimate one.

Rate limiting is the guardrail that prevents a single caller from consuming everything.

You probably know that ASP .NET Core has a built-in rate limiter.
Do you know the four different algorithms and how each one behaves under the same traffic conditions?

After reading, you will be able to pick the right algorithm for each endpoint and wire it up in minutes.

In this post, we will explore:

Why Rate Limiting Matters and How It Works in ASP .NET Core
Fixed Window Limiter
Sliding Window Limiter
Token Bucket Limiter
Concurrency Limiter
Choosing the Right Algorithm
Partitioning by IP, User, and API Key
Handling Rejected Requests and Retry-After

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/aspnet-core-rate-limiting-algorithms-explained

Why Rate Limiting Matters and How It Works in ASP .NET Core

Rate limiting is a rule that says: "this caller may do this much work in this much time, and no more".

It does three jobs:

Protects from abuse: brute-force logins, scraping, and denial-of-service floods are cut off before they reach your handlers.
Protects from accidents: a broken retry loop is stopped before it takes the database down for everyone.
Enforces fair share: a free tier gets a small allowance, a paid tier a bigger one, and one noisy client cannot starve the rest.

Since .NET 7, rate limiting is built into ASP .NET Core.

The algorithms live in System.Threading.RateLimiting, the middleware in Microsoft.AspNetCore.RateLimiting.
Both ship with the framework, so you don't need to install any NuGet packages.

Wiring it up takes three steps: register policies, add middleware and attach a policy to an endpoint.

using System.Threading.RateLimiting;
using Microsoft.AspNetCore.RateLimiting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(/* ... */);
builder.Services.AddAuthorization();

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    // Policies are registered here, one per section below
});

var app = builder.Build();

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

app.MapPost("/api/auth/login", LoginEndpoint.Handle)
    .RequireRateLimiting("login");

app.Run();

AddRateLimiter registers the options object that holds every named policy.

UseRateLimiter adds the middleware that checks each request against the policy attached to its endpoint.

RequireRateLimiting("login") attaches a policy middleware by name.

Endpoints without a policy are not limited at all.

Middleware order matters.
UseRateLimiter sits after UseAuthentication, so the user's claims are populated when the limiter runs, which makes per-user limits possible later.

Now let's explore the Rate Limiting algorithms.

Fixed Window Limiter

Imagine a bakery that sells 100 buns per hour.

At 9:00, the counter resets to 100. When the 100th bun is served, the door closes until 10:00, when the counter resets.

It does not matter whether the buns sold out in five minutes or across the hour. Only the clock brings buns back.

That is the fixed window limiter: a counter and a reset time.

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddFixedWindowLimiter("login", limiter =>
    {
        limiter.PermitLimit = 5;
        limiter.Window = TimeSpan.FromMinutes(1);
        limiter.QueueLimit = 0;
        limiter.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });
});

app.MapPost("/api/auth/login", async (
    LoginRequest request,
    LoginHandler handler,
    CancellationToken cancellationToken) =>
{
    var result = await handler.HandleAsync(request, cancellationToken);
    return result.IsSuccess ? Results.Ok(result.Value) : Results.Unauthorized();
})
.RequireRateLimiting("login");

PermitLimit is how many requests the window allows. Window is how long until the counter resets.

QueueLimit controls what happens after the requests are gone.

With 0, the request is rejected immediately.
With 10, up to ten requests wait for the next window instead.

QueueProcessingOrder determines whether the oldest or newest waiting request receives the first available permit.

For login, rejecting immediately is the right call. Queueing a brute-force attempt only keeps a connection open for the attacker.

Over time:

10:00:00  window opens, 5 requests available
10:00:01  requests 1 to 5   -> 200 OK
10:00:02  request 6         -> 429 Too Many Requests
10:00:59  request 7         -> 429 Too Many Requests
10:01:00  window resets, 5 requests available again

The simplicity has a well-known weak spot: the window boundary.

A client can send 5 requests at 10:00:59 and another 5 at 10:01:00.
That is 10 requests in two seconds against a limit of "5 per minute".
At the boundary, a fixed window lets through up to double the limit.

For login, this is harmless. Ten password guesses instead of five changes nothing. For a downstream that can handle exactly 100 requests per minute, 200 in two seconds is a real problem.

Note: the AddFixedWindowLimiter helper creates one counter shared by every caller of the policy. With the code above, five failed logins from anyone lock the endpoint for the whole world. In the "Partitioning" section, I will show how to give every client its own counter.

When to use the fixed window:

Login, password reset, email sending: cheap to count, and a small overshoot at the boundary does not matter.
Simple abuse caps: "no more than N attempts, then wait" is easy to explain to users and support staff.
Memory-sensitive scenarios: the cheapest algorithm, one counter and one timestamp per partition.

When not to use it:

When the boundary burst matters: a downstream with a hard cap, or a third-party API that bills per call.
When you want smooth traffic: a fixed window does nothing to spread requests out inside the window.
When the reset feels unfair: a client that spreads 5 requests evenly over the minute still waits a full minute for the 6th.

With the sliding window, we can fix the boundary problem.

👉 Read original article on my newsletter: https://antondevtips.com/blog/aspnet-core-rate-limiting-algorithms-explained

EF Core in Clean Architecture the Pragmatic Way

Anton Martyniuk — Mon, 19 Oct 2026 04:34:47 +0000

Clean Architecture is one of the most popular architectural styles in .NET today.

Clean Architecture aims to separate the application's concerns into distinct layers, promoting high cohesion and low coupling.

In the classic implementation you need to hide EF Core behind a Repository so the Application layer never depends on the ORM.

I followed that advice for years.
But after many production projects, I changed my mind and adopted a more pragmatic approach to implementing Clean Architecture.

In this post, I want to explain why I no longer wrap EF Core in a repository inside Clean Architecture, and why I think most teams should do the same.
We will look at what the original Clean Architecture really says and how a pragmatic approach keeps the same boundaries in the code.

In this post, we will explore:

The Traditional Clean Architecture with a Repository
The Hidden Cost of Repositories in Clean Architecture
Pragmatic Clean Architecture: Use EF Core Directly in Application Use Cases
What if We Switch a Database Later?
When You Might Still Need a Custom Repository

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-in-clean-architecture-the-pragmatic-way

The Traditional Clean Architecture with a Repository

Clean Architecture splits an application into four layers, each with a clear role:

Domain — entities, value objects, and core business rules.
Application — use cases, commands, queries, and handlers.
Infrastructure — implementations of external concerns: database, cache, message bus, email, identity provider.
Presentation — the entry point: Web API, gRPC, GraphQL, MVC, Blazor, etc.

The key rule is the Dependency Rule: dependencies point inwards:

Domain knows nothing about other layers
Application depends only on the Domain.
Infrastructure and Presentation depend on Application and Domain.

In the traditional setup, the Application layer defines the Repository contract:

public interface IShipmentRepository
{
    Task<Shipment?> GetByIdAsync(Guid id, CancellationToken cancellationToken);
    Task<bool> ExistsForOrderAsync(string orderId, CancellationToken cancellationToken);
    Task AddAsync(Shipment shipment, CancellationToken cancellationToken);
}

public interface IUnitOfWork
{
    Task<int> SaveChangesAsync(CancellationToken cancellationToken);
}

Infrastructure implements it on top of EF Core:

internal sealed class ShipmentRepository(ShipmentsDbContext context) : IShipmentRepository
{
    public Task<Shipment?> GetByIdAsync(Guid id, CancellationToken cancellationToken)
        => context.Shipments
            .Include(x => x.Items)
            .FirstOrDefaultAsync(x => x.Id == id, cancellationToken);

    public Task<bool> ExistsForOrderAsync(string orderId, CancellationToken cancellationToken)
        => context.Shipments.AnyAsync(x => x.OrderId == orderId, cancellationToken);

    public async Task AddAsync(Shipment shipment, CancellationToken cancellationToken)
        => await context.Shipments.AddAsync(shipment, cancellationToken);
}

internal sealed class UnitOfWork(ShipmentsDbContext context) : IUnitOfWork
{
    public Task<int> SaveChangesAsync(CancellationToken cancellationToken)
        => context.SaveChangesAsync(cancellationToken);
}

A use case handler injects the abstractions:

internal sealed class CreateShipmentHandler(
    IShipmentRepository repository,
    IUnitOfWork unitOfWork,
    ILogger<CreateShipmentHandler> logger)
{
    public async Task<Result<ShipmentResponse>> HandleAsync(
        CreateShipmentCommand command,
        CancellationToken cancellationToken)
    {
        var exists = await repository.ExistsForOrderAsync(command.OrderId, cancellationToken);
        if (exists)
        {
            return ShipmentErrors.AlreadyExists(command.OrderId);
        }

        var shipment = command.MapToShipment();

        await repository.AddAsync(shipment, cancellationToken);
        await unitOfWork.SaveChangesAsync(cancellationToken);

        return shipment.MapToResponse();
    }
}

The Dependency Rule is satisfied, and you can switch the implementation in tests. So far, so good.
But...

The Hidden Cost of Repositories in Clean Architecture

I have built many systems with this pattern. Here is what tends to happen as the project grows.

1. A repository is an abstraction over an abstraction.

EF Core's DbContext already implements both the Repository pattern and the Unit of Work pattern.
This is stated in the official DbContext summary. When you put IShipmentRepository on top of it, you are wrapping a wrapper.

When we create a repository over EF Core, we create an abstraction over an abstraction, leading to over-engineered solutions.

Each DbSet<TEntity> in your DbContext represents a collection of entities, just like a typical repository.

It allows you to:

Query data using LINQ
Add, update, and remove entities
Project data to other types

2. Method explosion.

What starts as four methods becomes 20:

public interface IShipmentRepository
{
    Task<Shipment?> GetByIdAsync(...);
    Task<List<Shipment>> GetByOrderIdAsync(...);
    Task<List<Shipment>> GetByCarrierAsync(...);
    Task<List<Shipment>> GetActiveAsync(...);
    Task<List<Shipment>> GetByStatusAsync(...);
    Task<List<Shipment>> GetCreatedBetweenAsync(...);
    Task<List<Shipment>> GetWithItemsAsync(...);
    // ... many more
}

Every new feature adds a new method.
After a year, no one knows whether the method they need already exists, so they add another one that does almost the same thing.

3. Cross-entity queries have no right place.

What if a feature needs a shipment, its order, plus the customer's address?
Where does that method live? IShipmentRepository? IOrderRepository? A new IShipmentOrderRepository?

4. Includes and projections leak or duplicate.

Some callers need Include(x => x.Items), some do not.
Some want a ShipmentResponse projection, and some want the full entity.
You end up with GetByIdWithItemsAsync, GetByIdSlimAsync, GetByIdForReportAsync — or you load too much data on every call.

5. Mocked-repository tests give false confidence.

Mocking IShipmentRepository is fast, but it does not test how EF Core translates your LINQ-to-SQL queries, whether your Include clauses work, or whether your database uniqueness constraints are enforced.
The exact things that break in production.

6. Slower feature delivery.

Every new use case touches three files: the repository interface, the repository implementation, and the handler.
For a single new query, that is a lot of ceremony.

Now, let's look at a pragmatic approach to using EF Core in Clean Architecture.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-in-clean-architecture-the-pragmatic-way

How to Structure Production Apps with Vertical Slice Architecture in .NET in 2026

Anton Martyniuk — Sat, 17 Oct 2026 08:16:35 +0000

Vertical Slice Architecture (VSA) is one of the most popular ways to structure .NET projects today.

It structures an application by features instead of technical layers.

In a traditional layered project, you have a Controllers folder, a Services folder, and a Repositories folder (and probably way more).
To change one feature, you jump between three or four folders (or even projects).

In VSA, every feature is a single slice.
The endpoint, business logic, validation, and data access for that feature live next to each other.

This brings several benefits:

High cohesion within a feature
Loose coupling between features
Faster navigation in the codebase
Independent changes to one feature do not take effect on the others

I have built many systems with VSA and shipped them to production, and over the years, my layout has settled into a single shape that I now reuse in every new project.

In this post, we will explore:

How I Structure my Projects with Vertical Slice Architecture
The Shared folder within a module
Auto-registration of endpoints, and handlers
Cross-slice side effects via events
Inter-module communication via PublicApi

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-structure-production-apps-with-vertical-slice-architecture-in-dotnet-in-2026

How I Structure my Projects with Vertical Slice Architecture

There are many ways to structure a slice.
In all of them, each vertical slice is placed in its own folder named after the use case.

Here are the most popular ones:

1. Each class for a feature is in a separate file name

2. Single file per slice with nested classes

public static class CreateShipment
{
    public sealed record Request(...);

    public sealed record Response(...);

    public class Validator : AbstractValidator<Request> { }

    public static void MapEndpoint(WebApplication app)
    {
        app.MapPost("/api/shipments", Handle);
    }

    private static async Task<IResult> Handle() { }
}

3. Separate file with each concern

This code structure combines the advantages of the first two options:

You put the request and response modules together in the endpoint file
You don't have too many files, as concerns are separated
You don't have a static file that nests other classes

This is the exact approach I use in production.

Each slice is a folder named after the use case.
Inside the folder, I keep four files, each focused on one concern.

For the "Create Shipment" use case, the layout looks like this:

Features/
└── CreateShipment/
    ├── CreateShipment.Endpoint.cs
    ├── CreateShipment.Handler.cs
    ├── CreateShipment.Mapping.cs
    └── CreateShipment.Validators.cs

When a slice raises events that other modules react to, I add an Events subfolder:

Features/
└── CreateShipment/
    ├── CreateShipment.Endpoint.cs
    ├── CreateShipment.Handler.cs
    ├── CreateShipment.Mapping.cs
    ├── CreateShipment.Validators.cs
    └── Events/
        ├── ShipmentCreatedEvent.cs
        ├── UpdateStockEventHandler.cs
        └── CreateCarrierEventHandler.cs

The naming convention uses a dot suffix: {Slice}.Endpoint.cs, {Slice}.Handler.cs, and so on.
This keeps files easy to find in the IDE search and easy to scan in the file tree.

I also extract cross-cutting concerns, such as validators and mappers, into separate files, so I don't clutter the main file with too many classes.

The Endpoint File

The endpoint file contains the request, response records and the Minimal API endpoint class.

The endpoint is responsible for:

Parsing the HTTP request
Running validation
Calling the handler
Translating the handler result into an HTTP response

Here is CreateShipment.Endpoint.cs:

public sealed record CreateShipmentRequest(
    string OrderId,
    Address Address,
    string Carrier,
    string ReceiverEmail,
    List<ShipmentItemRequest> Items);

public class CreateShipmentApiEndpoint : IApiEndpoint
{
    public void MapEndpoint(WebApplication app)
    {
        app.MapPost(RouteConsts.BaseRoute, Handle);
    }

    private static async Task<IResult> Handle(
        [FromBody] CreateShipmentRequest request,
        IValidator<CreateShipmentRequest> validator,
        ICreateShipmentHandler handler,
        CancellationToken cancellationToken)
    {
        var validationResult = await validator.ValidateAsync(request, cancellationToken);
        if (!validationResult.IsValid)
        {
            return Results.ValidationProblem(validationResult.ToDictionary());
        }

        var response = await handler.HandleAsync(request, cancellationToken);
        if (response.IsError)
        {
            return response.Errors.ToProblem();
        }

        return Results.Ok(response.Value);
    }
}

The endpoint class implements a small marker interface called IApiEndpoint:

public interface IApiEndpoint
{
    void MapEndpoint(WebApplication app);
}

This interface lets me discover and register all endpoints in a single line at startup (more on that later).

response.Errors.ToProblem() is an extension method that maps error types (Conflict, NotFound, Validation, and so on) to the appropriate HTTP status codes.

Validation runs explicitly in the endpoint, before the handler is called.
I do not use a MediatR pipeline behavior, like in many implementations.
The validation flow stays simple and easy to follow.

The Handler File

I implement the business logic inside the Handler class.

I use a manual handler pattern, which is a simple class without an interface.

I do not use MediatR. Instead, I have a small marker interface called IHandler:

public interface IHandler;

Every handler class in the project extends IHandler.
This lets me auto-register handlers with assembly scanning.

Here is CreateShipment.Handler.cs:


internal sealed class CreateShipmentHandler(
    ShipmentsDbContext context,
    IStockModuleApi stockApi,
    IEventPublisher eventPublisher,
    ILogger<CreateShipmentHandler> logger)
    : IHandler
{
    public async Task<Result<ShipmentResponse>> HandleAsync(
        CreateShipmentRequest request,
        CancellationToken cancellationToken)
    {
        var shipmentExists = await context.Shipments
            .AnyAsync(x => x.OrderId == request.OrderId, cancellationToken);

        if (shipmentExists)
        {
            logger.LogInformation("Shipment for order '{OrderId}' already exists", request.OrderId);
            return ShipmentErrors.AlreadyExists(request.OrderId);
        }

        var stockRequest = CreateCheckStockRequest(request);

        var stockResponse = await stockApi.CheckStockAsync(stockRequest, cancellationToken);
        if (!stockResponse.IsSuccess)
        {
            logger.LogInformation("Stock check failed: {@Errors}", stockResponse.Errors);
            return stockResponse.Errors;
        }

        var shipmentNumber = new Faker().Commerce.Ean8();
        var shipment = request.MapToShipment(shipmentNumber);

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

        logger.LogInformation("Created shipment: {@Shipment}", shipment);

        var shipmentCreatedEvent = new ShipmentCreatedEvent(shipment);
        await eventPublisher.PublishAsync(shipmentCreatedEvent, cancellationToken);

        return shipment.MapToResponse();
    }

    private static CheckStockRequest CreateCheckStockRequest(CreateShipmentRequest request)
    {
        return new CheckStockRequest(
            request.Items
                .Select(x => new ProductStock(x.Product, x.Quantity))
                .ToList()
        );
    }
}

Notice how simple the structure is.
No extra interfaces, no commands, no command handlers, no mediator, no magic navigation to implementation, just a direct call to an exact class.

Instead of throwing exceptions for expected errors, the handler uses a Result Pattern and returns Result<ShipmentResponse>.

Errors for the module live in a single static class, so they stay consistent and easy to find:

internal static class ShipmentErrors
{
    private const string ErrorPrefix = "Shipments";

    internal static Error NotFound(string shipmentNumber) =>
        Error.NotFound($"{ErrorPrefix}.{nameof(NotFound)}",
            $"Shipment with number '{shipmentNumber}' not found");

    internal static Error AlreadyExists(string orderId) =>
        Error.Conflict($"{ErrorPrefix}.{nameof(AlreadyExists)}",
            $"Shipment for order '{orderId}' already exists");
}

Cross-module calls go through public APIs.
The handler does not reference any internals of the Stocks module.
It only uses IStockModuleApi, which is exposed by a separate Modules.Stocks.PublicApi project.

Events fire after the save.
Once the shipment is persisted, the handler publishes a ShipmentCreatedEvent.
Other slices and other modules can react to this event without the handler knowing about them.

The Mapping and Validation Concerns

I do all object mapping manually, in static extension methods (I don't use mapping libraries like AutoMapper, Mapster or Mapperly).

internal static class CreateShipmentMappingExtensions
{
    public static Shipment MapToShipment(this CreateShipmentRequest request)
    {
        // Mapping code omitted for brevity
    }

    public static ShipmentResponse MapToResponse(this Shipment shipment)
    {
        // Mapping code omitted for brevity
    }
}

Manual mapping has two big advantages:

It is explicit: you can navigate to it directly and know exactly what happens
It has no reflection overhead

If a mapping is reused across multiple slices, I move it into the Shared/ folder of the module instead of duplicating it.

For validation, I use FluentValidation.
I keep all validators for a slice in one file:

public class CreateShipmentRequestValidator : AbstractValidator<CreateShipmentRequest>
{
    public CreateShipmentRequestValidator()
    {
        RuleFor(shipment => shipment.OrderId).NotEmpty();
        RuleFor(shipment => shipment.Carrier).NotEmpty();
        RuleFor(shipment => shipment.ReceiverEmail).NotEmpty();
        RuleFor(shipment => shipment.Items).NotEmpty();

        RuleFor(shipment => shipment.Address)
            .Cascade(CascadeMode.Stop)
            .NotNull()
            .WithMessage("Address must not be null")
            .SetValidator(new AddressValidator());
    }
}

public class AddressValidator : AbstractValidator<Address>
{
    public AddressValidator()
    {
        RuleFor(address => address.Street).NotEmpty();
        RuleFor(address => address.City).NotEmpty();
        RuleFor(address => address.Zip).NotEmpty();
    }
}

The Shared Folder Within a Module

Some things are needed by more than one slice in the same module (of a Modular Monolith): route constants, errors and response shapes for related slices.
To avoid duplication, I put them in a Shared/ folder inside the module's Features project.

Features/
├── CreateShipment/
├── DispatchShipment/
├── GetShipmentByNumber/
└── Shared/
    ├── Errors/
    │   └── ShipmentErrors.cs
    ├── Requests/
    │   └── ShipmentItemRequest.cs
    ├── Responses/
    │   ├── ShipmentResponse.cs
    │   └── ShipmentItemResponse.cs
    └── Routes/
        └── RouteConsts.cs

For all the API endpoint names, I used a static class called RouteConsts:

internal static class RouteConsts
{
    internal const string BaseRoute = "/api/shipments";

    internal const string GetByNumber = $"{BaseRoute}/{{shipmentNumber}}";

    internal const string CancelShipment = $"{BaseRoute}/cancel/{{shipmentNumber}}";

    internal const string DispatchShipment = $"{BaseRoute}/dispatch/{{shipmentNumber}}";
    // ... and so on
}

I wrote a detailed guide on how to share code and avoid code duplication in Vertical Slices. Read it here.

👉 Read original article on my newsletter: https://antondevtips.com/blog/how-to-structure-production-apps-with-vertical-slice-architecture-in-dotnet-in-2026

40 Lessons I Learned in 12 Years as a .NET Developer

Anton Martyniuk — Fri, 16 Oct 2026 08:17:39 +0000

17 years ago, I wrote my first line of C# code (.NET Framework 3.5).
It was in the IT school.

12 years ago, I wrote my first application in .NET and pushed it to production.
It worked, but it had bad code. I did not know it at the time, but I would spend the next few years learning how to improve.

Over more than 12 years, I have shipped buggy releases.
I have over-engineered features nobody asked for.
I have argued about tabs and spaces in pull requests.

I have debugged distributed systems on weekends, missed estimates, and watched "future-proof" architectures rot into legacy.

Some lessons were painful.
Others were priceless.

None of them came from a textbook; they came from real projects, real bugs, and real teammates who pushed me to be better.

Today, I want to share the 40 most important takeaways I have learned over my career.
Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer

0. The best code is the one you don't write

Every line of code is a future liability.
It needs to be read, tested, debugged, deployed, and maintained for years.

The cheapest, safest, fastest code is the code that never gets shipped.

Before writing anything new, I ask myself: do we really need this? Is there a simpler way? Can an existing tool, library, or feature solve the problem instead?

Many projects fail because they have too much code.
Less code means fewer bugs, faster onboarding, and less time spent maintaining things nobody uses.

1. You're not paid to write code - you're paid to solve problems

Code is just a tool. The real product is the value you deliver to the business and to the users.

I have seen developers spend weeks polishing a feature nobody asked for, while a critical bug stayed in production.
I have seen teams build complex frameworks when a simple script that runs in 5 minutes would have done the job.

The best engineers I know start with the problem, not with the technology.
They ask questions, understand the context, and only then choose the right tool. And sometimes that tool is no code at all.

👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer

EF Core Optimization Guide: A Step-By-Step Guide to Faster Queries

Anton Martyniuk — Tue, 13 Oct 2026 11:07:50 +0000

"EF Core is slow, don't use it."

I heard this from so many developers.

And almost every time, the cause is the same: EF Core makes it very easy to write a query that loads far more data than you need, and then you blame it for speed.

Integration tests don't catch this.

In development, your queries complete in a few milliseconds for a database with a few hundred rows.
Then production grows to 2 million rows and the same endpoint takes 30 seconds.

I've spent a lot of time optimizing EF Core in production systems, and I know a set of techniques that work.

Some of them you need to apply daily, others - when you need to make it faster, or based on your specific datasets.

Let's dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-optimization-guide-step-by-step

Step 0: Measure Before You Optimize

All examples in this article use a shipment tracking domain:

public class Shipment
{
    public Guid Id { get; set; }
    public string Number { get; set; }
    public string OrderId { get; set; }
    public string Carrier { get; set; }
    public string ReceiverEmail { get; set; }
    public ShipmentStatus Status { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? UpdatedAt { get; set; }

    public Address Address { get; set; }

    public List<ShipmentItem> Items { get; set; }
}

public class ShipmentItem
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }

    public Guid ShipmentId { get; set; }
    public Shipment Shipment { get; set; }
}

Note: all queries were tested on PostgreSQL. The same ideas apply to SQL Server, MySQL, and Oracle, though the generated SQL and the exact limits differ.

Most performance work goes wrong before a single line of code changes.

A query feels slow, someone puts a cache in front of it, and the endpoint gets faster.

The slow query is still there. It just runs less often, and it will hurt again the moment the cache misses or the data changes more frequently than you expected.

So the first step is finding out what SQL your LINQ actually produces.

Turn on query logging in development:

builder.Services.AddDbContext<ShipmentsDbContext>(options =>
{
    options.UseNpgsql(connectionString);

    if (builder.Environment.IsDevelopment())
    {
        options.LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging()
            .EnableDetailedErrors();
    }
});

LogTo writes every generated SQL statement to the console.
EnableSensitiveDataLogging includes the actual parameter values, so you can copy the statement straight into your database client and run it.

You can also enable EF Core logging through your logging configuration - set the Microsoft.EntityFrameworkCore.Database.Command category to Information and let your logging framework (Serilog, NLog) write the SQL to a file or a sink of your choice.

Note: never enable EnableSensitiveDataLogging in production. It writes parameter values, including emails, addresses, and anything else your queries filter on.

Once you have the SQL, run it with an execution plan (EXPLAIN ANALYZE in PostgreSQL, or the actual execution plan in SQL Server).
The plan tells you whether the database is scanning an entire table or using an index, and where the time is actually spent.

Let's explore the query plan for this small query (from the screenshot above) that finds a Shipment by a number:

var shipment = await context.Shipments
    .Include(x => x.Items)
    .Where(s => s.Number == shipmentNumber)
    .FirstOrDefaultAsync(cancellationToken);

Three numbers are worth checking every time:

Does the database use a full table scan or an index?
How many rows the database returns. If a query returns 50,000 rows to build a page of 100, the fix is in your LINQ in EF Core query.
How many round-trips your code makes. One request per loop iteration is a different problem from one slow request.

For anything you plan to tune repeatedly, write a benchmark with BenchmarkDotNet so you have a number to compare against.

Now that you can see what's actually happening, let's explore ways we can improve performance.

Fetch Less Data

Almost every slow EF Core query is slow for the same reason: it moves more data out of the database than the code needs.

The three optimizations in this step all attack that.

1. Add the Right Indexes

In EF Core (migrations), it automatically creates indexes for primary keys and foreign keys.
It doesn't create indexes for the columns you filter and sort on.

If your shipment list screen filters by status and orders by creation date, the database has to scan the table on every request:

Add the index in your entity configuration (the database migration will create it):

public class ShipmentConfiguration : IEntityTypeConfiguration<Shipment>
{
    public void Configure(EntityTypeBuilder<Shipment> builder)
    {
        builder.HasKey(x => x.Id);

        builder.HasIndex(x => x.Number)
            .IsUnique();

        builder.HasIndex(x => new { x.Status, x.CreatedAt });
    }
}

The composite index on (Status, CreatedAt) matches the shape of the query.

Column order matters here.
The database can use this index to filter by:

Status alone
Status and then sort by CreatedAt

But it can't use it to sort by CreatedAt alone.

Put the column you filter on for equality first, and the column you range-filter or sort on second.

When most of your queries only care about a small slice of the table, a filtered index is cheaper to maintain:

builder.HasIndex(x => x.CreatedAt)
    .HasFilter("\"Status\" NOT IN (4, 5)");

This indexes only the shipments that are still in flight and skips the delivered and canceled rows, which make up most of the table over time.

Remember that indexes aren't free.
Every index has to be updated on every insert, update, and delete that touches its columns.
Add indexes only for the query shapes you actually run.

Indexes help the database find your rows quickly. The next step is making sure you ask for fewer of them.

2. Filter Early, in the Database

This is the mistake I see most often from young developers (sometimes AI does this, duh!), and it usually hides behind a helper method:

// Loads every shipment in the table
var shipments = await dbContext.Shipments.ToListAsync(cancellationToken);

var pending = shipments
    .Where(s => s.Status == ShipmentStatus.Processing)
    .ToList();

The moment you call ToListAsync, the query is executed, and the rest happens in memory in your application.

The database sends every row over the network. EF Core materializes each row into an object. And then your code throws most of them away.

Keep the filter inside the IQueryable so it becomes a WHERE clause:

var pending = await dbContext.Shipments
    .Where(s => s.Status == ShipmentStatus.Processing
        && s.CreatedAt >= since)
    .ToListAsync(cancellationToken);

The same applies to sorting, grouping, and aggregation. Count(), Any(), Sum(), and Max() all translate to SQL when you call them on an IQueryable.
It all runs in memory when you call them after calling ToListAsync.

3. Project Only the Columns You Need

Loading a full entity means loading every column it maps to, including the ones your endpoint never returns.

If a Shipment has 10 columns and your list screen shows 4 of them, you're moving more than twice the data you need.

Project into a record or class instead:

public record ShipmentResponse(
    Guid Id,
    string Number,
    string Carrier,
    ShipmentStatus Status,
    DateTime CreatedAt);

var shipments = await dbContext.Shipments
    .Where(s => s.Status == ShipmentStatus.Processing)
    .OrderByDescending(s => s.CreatedAt)
    .Select(s => new ShipmentResponse(
        s.Id,
        s.Number,
        s.Carrier,
        s.Status,
        s.CreatedAt))
    .ToListAsync(cancellationToken);

EF Core translates the Select into a SELECT list with exactly those five columns.

Projections do three things at once:

They cut the size of data the database reads
They cut the size of data you transfer over the network from the database to your app
They skip change tracking entirely, because there's no entity to track.

This is consistently the single biggest win available.
Projecting only the required columns can take your query somewhat from 10 seconds to 40 milliseconds (when reading 10,000 or more rows).

You can explore the benchmarks in the optimization challenge I did before with EF Core.

Projections also compose well with aggregation:

var summaries = await dbContext.Shipments
    .Where(s => s.CreatedAt >= since)
    .Select(s => new ShipmentSummary(
        s.Number,
        s.Status,
        s.Items.Count,
        s.Items.Sum(i => i.Quantity)))
    .ToListAsync(cancellationToken);

The database computes the item count and quantity sum. No ShipmentItem objects are created in your application at all.

👉 Read original article on my newsletter: https://antondevtips.com/blog/ef-core-optimization-guide-step-by-step