Milan Jovanović

One small change = 400x FASTER query

Here's what I did to achieve this performance boost.

I was implementing cursor pagination with EF and Postgres.

But I need to make the query faster.

How do you make an SQL query faster?

Add an index, and you're good to go.

Right?

Not quite...

I created a composite index on the required columns to speed up the query.

BUT THIS MADE THE QUERY SLOWER!!!

This led me down a rabbit hole to figure out why the index wasn't used.

I knew about tuple comparison from before, and this solved the problem.

But I didn't know how to translate this into an EF Core query.

Luckily, the Postgres provider supports this with a custom function.

Here's everything you should know: https://lnkd.in/eD629U-B

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/e-XH7dM7

Multiple EF Core DbContexts in a single application?

Here's when it makes sense to do this:

- Working with multiple databases
- Separating concerns
- Modular monolith
- Read replicas

I did this when implementing a modular monolith application.

Each module had a dedicated schema in the database and a separate DbContext in the code.

The surprising part?

How EF Core deals with database migrations and different schemas.

Here's a breakdown of how I solved this: https://lnkd.in/e6JWgpNv

Did you need to use multiple DbContexts with EF?

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

One of the most important distributed systems concepts:

→ Idempotency

It's also crucial when designing REST APIs.

You can repeat an idempotent operation multiple times without changing the system's state after the first API request. This is especially important in distributed systems. Network failures or timeouts can lead to repeated requests. Your system should be able to handle transient errors like this.

Example flow for implementing idempotency:

1. The client generates a unique key for each operation and sends it in a custom header.

2. The server checks if it has seen this key before
- For a new key, process the request and store the result
- For a known key, return the stored result without reprocessing

Are you handling idempotency in your APIs?

Do you know all 3 ways to define Middleware in ASP .NET Core?

Middleware allows you to introduce additional logic before or after executing an HTTP request.

Middleware is an excellent choice for solving cross-cutting concerns in your application.

You are already using many of the built-in middleware available in the framework.

I'm going to show you three approaches to define custom middleware:

- Request Delegates
- Convention based
- Factory based

Here's everything you need to know: https://lnkd.in/eHYAh7Pc

How do you prefer to define middleware in .NET?

If your .NET app runs background jobs or distributed workers, you need a way to prevent duplicate execution.

Otherwise, two instances can pick up the same task: sending duplicate emails, charging twice, or overwriting data.

That’s where distributed locking comes in.

In my latest video, I show how to implement production-ready distributed locks in .NET using a single clean library.

You’ll see how to:
- Use Postgres advisory locks and Redis for distributed coordination
- Build a reusable locking abstraction for any .NET app
- Decide when it actually makes sense to use one

If you care about reliability and data integrity, this one’s worth your time.

Learn more: https://lnkd.in/eWfVWmHk

What's wrong with the first code snippet?

The second example is 43x faster to insert 10,000 records.

But what causes such a huge performance difference?

If you understand how EF works under the hood, the answer should be obvious. 👇

Every call to SaveChanges means one round-trip to the database.

In the first example, inserting each record means one call to the database.

This quickly adds up...

Here's why it's important to use the right tool for the job: https://lnkd.in/eStH9yku

Sending unnecessary queries to the database is one of the biggest performance killers in enterprise applications.

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

C# 15 is getting union types.

That’s a big deal.

It means patterns like Result and Option finally have real language support.

No more awkward wrappers.
No more hacks.
No more pretending exceptions are the best way to model failure.

I’ve advocated for the Result pattern for years, but lack of native support always made it clunky.

That changes with union types.

Don’t want to wait?

Here’s how to implement the Result pattern today: https://lnkd.in/dh8U8E2g

If you still prefer throwing exceptions, you can skip this.

What's a breaking change for an API?

Here are a few examples:

- Removing or renaming APIs or API parameters
- Changing the behavior of existing APIs
- Changing the API error codes

A breaking change means you need to version your API.

Otherwise, you risk breaking existing consumers.

Luckily, ASPNET Core makes it easy to introduce versioning.

Check out this article on API Versioning: https://lnkd.in/dc62ZQFV

Here's a hot take for you to ponder.

Did we make a mistake as an industry with API versioning?

P.S. If you want to learn how to build production-ready REST APIs using the latest ASPNET Core features and best practices, this is for you: https://lnkd.in/dU6Psx5t

Does your application need input validation?

There's a 99% chance the answer is YES.

Don't reinvent the wheel - use FluentValidation.

FluentValidation gives you a simple API to build complex validation rules.

You can write rules to ensure values are:
- Not null
- Not empty
- Have a min/max length
- Are equal/not equal to some value
- Define your completely custom rules

It's easy to write asynchronous validation rules using the MustAsync method. Dependency injection also works as you'd expect.

Here's how you can use FluentValidation to build a global validation middleware in minutes: https://lnkd.in/eKa6XVrT

Have you used FluentValidation before?

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/e-XH7dM7

Yes!🔥🚀

Group related concepts together = build better applications 💡

Another name for this is cohesion, where we want to maximize the "relatedness" of files for a single feature.

Layered architectures typically have low cohesion.

The problem?

They force you to make changes in many different layers to implement or update a feature.

Vertical slices take a different approach.

All the files for a single use case are grouped together, which increases their cohesion. It's easy to find all the relevant components for a feature.

You can learn more about VSA here: https://lnkd.in/e-TKtnay

What do you think about this approach?

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

When I need to add a real-time feature to my app, there's one trusted solution I always go back to.

→ SignalR

SignalR allows you to add real-time functionality to your .NET applications.

And it all starts from a Hub. The Hub is a central component in your application that manages client connections and messaging.

Clients connect to the Hub to receive and send messages. Which means the communication is two-way.

SignalR abstracts away the transport mechanism from you. Usually this will be WebSockets, but if they're not available, it can fall back to SSE or polling.

Here's how you can get started: https://lnkd.in/ecnHcStj

SignalR is easily one of the best tools we have in .NET.

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/e-XH7dM7

Year 4 as a Microsoft MVP 🔥

I'm honored and thankful for being part of this community. Looking forward to doing my best work yet!

Starting from an existing database doesn’t mean you can’t use EF Core effectively.

Most .NET tutorials focus on Code-First.

But in the real world, many teams inherit a schema, and you still need a clean, maintainable way to work with it.

In my latest video, I show how to scaffold a DbContext from an existing PostgreSQL database using EF Core and .NET Aspire.

You’ll learn how to:
- Reverse-engineer your database with Scaffold-DbContext
- Configure it with Aspire’s connection management
- Avoid pitfalls like returning entities directly
- And evolve your setup into a Code-First workflow when your app grows

If you’ve ever had to start from a database instead of code, this one’s for you.

Learn more: https://lnkd.in/edBy4a77

I built a free Clean Architecture template.

And now I've made it even better by adding Aspire.

More than 40,000+ developers have already downloaded it.

Here's what's inside:

- Simple domain model
- Domain Events pattern
- CQRS + clean use cases
- Validation and logging
- Authentication with JWT
- Boilerplate for RBAC Authz
- Minimal APIs, health checks
- Run locally with Aspire in seconds

I also made sure not to use any commercial libraries.

Get the template here: https://lnkd.in/dC4C7NPa

If you're still writing five separate interfaces and classes for every single command in .NET, you need to see this.

For years, many of us in the .NET community have relied on MediatR and MassTransit for command handling and messaging. But the boilerplate is real.

I finally took the plunge and explored Wolverine, a library that claims to be the "next generation" of .NET messaging by focusing on convention over configuration.

In my new video, I share my raw, first-take as a long-time user of other messaging tools: https://lnkd.in/eDm9Aa3p

In-memory rate limiting works perfectly... right until you scale.

If you're running a single API instance, storing rate limits in memory is easy and fast. But the second you scale out to multiple instances, that approach breaks down. Your services suddenly have no centralized way to agree on the correct rate limit values, leaving your API vulnerable.

That’s when you need a distributed rate limiter.

In my new video, we tackle this head-on. I'll show you exactly how to build a production-ready, distributed rate limiter in C# using Redis.

We walk through the code for:
🔹 Why native .NET memory limits fall short at scale
🔹 Building a Fixed Window algorithm using Redis counters
🔹 Implementing a more advanced Sliding Window algorithm with Redis sorted sets
🔹 Hooking it all up with custom middleware in .NET 10

If you want to protect your APIs from abuse and handle high traffic correctly, check out the full step-by-step breakdown here: https://lnkd.in/gWk4SaSM

How do you create background jobs in .NET?

With Quartz, it's as simple as implementing an interface.

You define a job, register it, and Quartz takes care of scheduling and execution for you.

It integrates beautifully with dependency injection, so you can inject any services you need, from logging to your repositories.

Jobs are scoped, meaning you can even inject a DbContext safely without worrying about lifetime issues.

Once you start using Quartz, it’s hard to go back to manual background loops or timers.

I wrote an advanced guide for working with Quartz in .NET that I think you’ll enjoy.

You can read it here: https://lnkd.in/eNjF_jXE

Have you tried Quartz before, or do you use another library for background jobs?

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

System integration testing changed how I test my applications.

Have you heard about it?

This type of test gives you the highest level of confidence.

Let's take a modular monolith and test the integration between modules.

A modular monolith consists of multiple modules (duh), each with a distinct responsibility. Modules represent high-level components with well-defined boundaries.

The modules essentially group together related functionalities (use cases).

What's the best way to test module interactions?

System integration testing (SIT) is an approach to verifying the collaboration of these modules.

During system integration testing, we want to ensure that all these modules interact correctly and fulfill our system's business requirements.

Here's a hypothetical scenario:

- A user registers with our application through the Users Module
- The Users Module publishes an integration event to notify other modules
- The Ticketing Module handles the event and creates a customer record

How would you write a test for this scenario?

If you want to learn more about system integration testing, I wrote a high-level guide.

Read it here: https://lnkd.in/esyaQ6SG

What do you think about this testing approach?

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/eDqzAKsP

Async messaging is one of the best ways to make your .NET systems faster and more reliable.

Instead of services waiting on each other, you send messages through a broker.

In my new video, I'll show you how to build async messaging in .NET using Azure Service Bus step by step:

✅ Queues vs. Topics (when to use which)
✅ Message processing and dead-lettering
✅ Subscriptions and filters
✅ Scheduling and deduplication
✅ Full demo with .NET + Aspire

If you've been curious about event-driven design or scaling your services, this video will give you a solid foundation.

Watch here: https://lnkd.in/eN6FVAEc

The .sln file as we know it is finally dead.

After nearly two decades of dealing with unreadable GUIDs and painful merge conflicts, Visual Studio 2026 has introduced the new .slnx format. It’s clean, it’s XML-based, and it actually makes sense.

But that’s not the only upgrade.

In my latest video, I show you how I moved my entire solution from .NET 9 to .NET 10 in just a few minutes.

The secret isn't upgrading every project manually, it’s using a "Smart Setup" with Directory.Build.props and Central Package Management.

In this video, I break down:

- How to change target frameworks for 20+ projects instantly
- Managing NuGet versions in one single file
- A deep dive into the new .slnx format (and how to migrate)
- Handling Dockerfile updates for .NET 10

Stop fighting with your solution files.

Here is the better way to handle the upgrade: https://lnkd.in/dFgdarZe

Code review is becoming the bottleneck in AI-assisted development.

Uncle Bob recently said he no longer reads any of the code written by his agents.

That sounds irresponsible. But his real argument isn’t "trust the model". It’s "replace eyeballing with evidence".

I unpack this in my latest video.

The approach only makes sense when three things are true.

1) Risk is acceptable.

A bug in a learning platform is not the same as a failure in software where people can get hurt.

2) The agent is constrained.

Unit, integration, architecture, and Gherkin tests can encode what the system is allowed to do.

3) The output is verified.

QA, mutation testing, coverage, and custom harnesses provide evidence without depending entirely on line-by-line review.

The uncomfortable part is that many developers have tied their identity to writing code.

But code is an artifact. The job is turning requirements into reliable systems.

Agents may produce more of the implementation. Engineers still have to design the boundaries, constraints, and feedback loops that make the result trustworthy.

Watch the full breakdown here: https://lnkd.in/d7mMM9x8

I just launched Katabench, it's a practice platform for .NET developers.

Here's why I built it.

Most coding practice tells you whether the output is correct. It doesn't tell you what the code actually did.

An O(n²) solution can pass the same functional tests as an O(n) solution.

A LINQ query that scans 60,000 rows can return the same data as one that uses the index.

A vulnerable feature can pass the same happy-path tests as a safe one.

Production cares about the difference.

So I built Katabench to grade those differences: wall-clock time, managed allocations, real database query plans, code structure, architecture rules, and adversarial security cases.

Now I can open a database puzzle, write C# with LINQ or raw SQL in the browser, and submit it against a real, throwaway PostgreSQL database. Katabench captures the plan PostgreSQL actually chose and checks explicit rules against it.

Did you avoid the full table scan? Did PostgreSQL use the required index? Did the query stay to one round trip?

Same rows. Very different work. Now the green checkmark means more than "the rows matched".

Katabench has 374+ puzzles across seven disciplines: Algorithms, Database & EF Core, Refactoring, Architecture, Secure Coding, Design Principles, and Test Writing. It also has six guided Learning Paths with 98 exercises, progressive hints, reference solutions, streaks, XP, quests, and achievements.

It's free to start. The full algorithm track with performance grading costs nothing, and you can try a puzzle without even signing up.

This is the tool I wish I had ten years ago: https://lnkd.in/dUkDtjSs

P.S. Next up is System Design Studio. You'll build an architecture on an interactive canvas and get deterministic feedback on required components, forbidden connections, and single points of failure instead of only comparing your answer with a reference diagram.

I just released a Claude Skills package for my Clean Architecture template, and it's free.

Here's why I built it. Every AI coding assistant I've used has the same problem: ask it to add a feature and you get code that works but doesn't look like yours. Different folder structure, exceptions where I use results, MediatR where I don't, tests that mock everything.

So I taught Claude Code my conventions. The template now ships with agent skills: markdown files that describe exactly how I build features. Vertical slices, custom command and query handlers, Result-based error handling, minimal API endpoints, and the tests to go with them.

Now I type "/add-feature snooze a todo until a given date" and get the command, the validator, the handler with an ownership check and a domain event, the endpoint, and the tests. Built and verified, in the same shape as every other feature in the solution.

Grab the template and the skills come with it: https://lnkd.in/dC26qBjY

Everyone wants to build a modular monolith these days.

But what's the value of a modular monolith?

Here are a few advantages:

- Fast development velocity
- Lower operational complexity
- Simplified deployment process
- Easier transition to microservices

Have you ever struggled to scale your application?

You're not alone.

Let's say you're running a sale, and your application is in high demand.

Imagine extracting the sales module to its own service, which you can scale dynamically based on demand. This is something you can easily do with a modular monolith.

If you're ready to learn more, I wrote a detailed introduction to modular monoliths.

Check it out here: https://lnkd.in/dgE7bUjR

Modular monoliths blend the simplicity and robustness of traditional monolithic applications with the flexibility and scalability of microservices.

I'm tempted to say they bring together the best of both worlds.

The Outbox pattern gets all the attention.

But reliable publishing is only half the problem.

Your service can publish a message correctly.

The broker can deliver it correctly.

Your consumer can process it correctly.

And you can still process the same message twice.

That’s the reality of at-least-once delivery.

A timeout, crash, or network blip can happen after your consumer finishes the work but before the ACK reaches the broker.

So the broker does the safe thing:

It redelivers the message.

This is where the Inbox pattern helps.

Instead of processing the message directly, the consumer first writes it to an `inbox_messages` table.

Duplicates are ignored with `ON CONFLICT DO NOTHING`.

Then a background processor picks up unprocessed messages and handles them in batches.

This gives you:

- Idempotent message reception
- Independent retry control
- Horizontal scaling with `FOR UPDATE SKIP LOCKED`
- Fewer duplicate side effects leaking into your business logic

The Outbox makes publishing reliable.

The Inbox makes consumption reliable.

You usually need both if you want event-driven systems that behave well under failure.

I wrote a full breakdown of how to implement the Inbox pattern in .NET with PostgreSQL and RabbitMQ: https://lnkd.in/dWvkVtWb

How do you enforce architecture rules in code?

Compilers won’t catch violations. Code reviews are hit or miss.

There’s a better way: architecture tests.

They’re automated checks that verify structure and design, written in C#.

Use them to:

• Enforce project dependency directions
• Restrict coupling between components
• Apply naming conventions

Here’s how to write your first one in minutes: https://lnkd.in/gnWuVAwY

And remember: architecture should speed you up, not box you in.

Here's how I implement CQRS in my applications.

The CQRS pattern is actually simple.

I organize my application around use cases.

Use cases represent a feature (functionality) in your application:

- Get the current user's details
- Add an item to the shopping cart
- Refund the payment for an order

So you can think of a use case as a business capability.

I structure my code around a single use case (feature).

There are two types of use cases:

- Commands → business logic, database write, trigger side effects
- Queries → return the required data representation for the UI

If you think it should be more complex than this, you're overengineering it.

What do you think about applying CQRS?

P.S. No - you don't need event sourcing or a separate database.

Are you using SignalR the right way?

Broadcasting to all users isn’t scalable (or smart).

In most cases, you should target specific users.

The good news? SignalR supports this out of the box.

It maps connections to user IDs using claims from the authentication context (JWT, cookie, etc.).

As long as the client is authenticated, SignalR can route messages to that user directly.

Want to dive deeper?

Here’s a quick guide to doing SignalR right: https://lnkd.in/dDn73TSu

How are you handling real-time communication in your app?

6 things I do to set up my new .NET projects the right way

1. Enforce a consistent code style
2. Centralize build configuration
3. Centralize package management
4. Add static code analysis
5. Set up local orchestration
6. Automate builds with CI

I wrote a step-by-step guide on how to configure all this here: https://lnkd.in/eCpE6KM3

What else would you add to this project setup?

I already know a few people will say tests.

Definitely integration testing with something like Testcontainers.

---
Sign up for the .NET Weekly with 74K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/ew5Adz89

Stop polling your database.

Let Postgres tell you when something changes.

In my latest video, I show how to stream Postgres Write-Ahead Log (WAL) changes directly into your .NET app using Npgsql.

You’ll learn how to:
- Set up logical replication in Postgres
- Stream changes in real time with Npgsql
- React to inserts, updates, and deletes
- Implement cache warming, cache invalidation, or even Outbox publishing

Watch it here: https://lnkd.in/e8iveVDD

If you’ve ever built a cache layer or event-driven system in .NET, this one will spark ideas.

I stopped using Serilog in .NET.

Here's what I use instead.

Let's say you build a microservices system.

How will you monitor what's happening inside?

This is where Observability comes in.

You need to be able to track how requests flow through your system.

This is crucial for debugging and performance optimization.

OpenTelemetry is an open-source observability framework that makes this possible.

It covers everything: metrics, traces, and (structured) logs.

Have you started using OpenTelemetry?

Tired of writing the same unit test over and over with different inputs?

You don’t have to.

Parameterized tests (aka data-driven tests) let you write one test and run it with many inputs.

I use xUnit for this. You have a few options:

- Use TheoryData to define strongly-typed parameters
- Plug it into your test using [ClassData(typeof(...))]
- Or take a simpler approach using [InlineData(...)]

Each has trade-offs.

Want to see all the ways to write parameterized tests in xUnit with clear examples?

Start here: https://lnkd.in/dJKJgcPG

How do you write your test variations?

𝗥𝗮𝘁𝗲 𝗹𝗶𝗺𝗶𝘁𝗶𝗻𝗴 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗔𝗦𝗣 .𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 𝗔𝗣𝗜𝘀 🪙

Rate limiting can make your APIs more robust and secure.

It's a technique to limit the number of requests to a server or an API.

There are four popular rate limit algorithms:

- Fixed window
- Sliding window
- Token bucket
- Concurrency

However, these are global rate limiters and are rarely practical. In reality, you want to rate limit specific users or IP addresses. You can do all this in .NET with the rate-limiting service and partitioner.

If you want to apply rate limiting in a distributed system, you'll have to define the rate limit policies on a reverse proxy like YARP. Luckily, YARP has built-in support for .NET rate limiting.

Have you used rate limiting in .NET?

The test pyramid was good advice for 2009.

I don’t think it’s good advice for modern .NET systems.

Back then, integration tests were expensive:
shared database servers, flaky CI, slow builds, painful setup.

So the advice made sense:
write tons of unit tests, mock everything, keep integration tests small.

But the economics changed.

With Testcontainers, I can spin up PostgreSQL, Redis, and RabbitMQ in seconds.

With Aspire, I can wire up the application graph and test the real system boundaries.

That changes what "fast feedback" means.

For me, the highest-confidence test suite looks more like this:

A thin layer of unit tests for pure domain logic.

A thick middle of integration tests against real infrastructure.

A few critical end-to-end tests for the flows that would really hurt if they broke.

And architecture/contract tests to keep boundaries from drifting over time.

I still write unit tests.

Just not for everything.

Handlers, endpoints, repositories, message consumers, and module APIs usually belong in integration tests.

That’s where the real bugs tend to hide.

I wrote a detailed breakdown of why I stopped taking the test pyramid seriously, and what I use instead: https://lnkd.in/gHpdN9tn

𝗦𝗰𝗮𝗹𝗶𝗻𝗴 𝗪𝗲𝗯 𝗮𝗽𝗽𝘀 𝘁𝗼 𝟭,𝟬𝟬𝟬,𝟬𝟬𝟬 𝘂𝘀𝗲𝗿𝘀

I worked on a large system that had more than a million users. This is how we scaled the system to handle that amount of traffic.

The application started as a humble monolith: one application server and one database server. This worked well for a few years, but as the number of users grew, the system became slower. Something needed to be done.

The next evolution was horizontally scaling the Web API to handle more requests. The database instance was scaled vertically (scale up). However, we soon started running into problems with the database.

We already used caching to some extent, but this was simple in-memory caching on the application servers. So, we decided to introduce distributed caching with Redis. After introducing Redis, the load on the database was drastically reduced as most requests could be served from the cache. An added benefit was improved performance and responsiveness.

I want you to take away one thing from this: solve the problem you have right now. We're prone to overengineering systems before they reach any significant scale.

Also, why would you want to scale an unprofitable application? Developers rarely think about financial stuff. Don't forget that your application is probably there to run a business. And a business is crappy if it's not profitable.

What was the largest application you worked on?

Your modular monolith may not be as modular as you think.

It may have clean module names.

Billing.
Notifications.
Reporting.
Users.

But open the Billing module and you may find it doing all four jobs.

Charging customers.
Sending emails.
Building reports.
Changing user accounts.

That is not a real boundary.

That is a large monolith hiding inside a smaller one.

How do you fix it?

Not by jumping straight to microservices.

Start with one clear split.

For example, move notifications out of billing.

Then remove the direct call between them.

Billing should say:

"A customer was charged."

Notifications can react to that event on its own.

Next, work on data ownership:

→ One clear module per business area
→ Separate database access per module
→ No hidden reads from another module’s tables
→ Clear rules for how modules communicate

The goal is not more projects or folders.

You want to make one part of your app easier to change without breaking three others.

You do not need to split everything at once.

Find the module that has grown too large.
Extract one responsibility.
Ship it.
Repeat.

I wrote a practical step-by-step refactor for overgrown modules in a .NET modular monolith: https://lnkd.in/deV5sj_2

[UPDATE]: THANK YOU! The X support team reached out, and I got my account back.

If my posts ever brought you something good, I ask for a small favor in return.

My X account got hacked, and I'm trying to get it back.

Stefan posted on X with some info on how to report the account.

If you could also help out by reporting the profile, I would really apprecaite it.

EF Core bulk updates are amazing.

Why should you care? Performance.

You can write optimal UPDATE and DELETE queries now. You only execute one SQL statement. In fact, this is how you would write SQL yourself.

I have no idea why EF Core took so long to implement this.

But there's a big PROBLEM with this method. It's not part of the EF unit of work. So you have to wrap it in a transaction!

Do you prefer this EF feature or good ol' SQL?

Most .NET apps are one Redis crash away from teaching you that “it works on my machine” is not a monitoring strategy.

You do not need a big observability stack to get basic uptime monitoring in place.

Uptime Kuma gives you a simple way to monitor:

- Your websites
- Your APIs
- Your health check endpoints
- Your public status pages
- Incidents and scheduled maintenance

In my setup, I use it to monitor a .NET API health endpoint that also reflects the state of dependencies like Postgres and Redis.

That means you are not just checking whether the API responds.
You are checking whether the system is actually healthy.

A few practical things this setup gives you:

- A quick self-hosted monitoring dashboard
- Alerts when services go down
- Status pages you can share
- A simple way to validate your health check flow
- Better visibility into your app without another paid tool

I also cover one Docker networking detail that can easily trip you up when monitoring a local .NET app from inside a container.

If you want a lightweight and practical way to monitor your .NET APIs and microservices, I break the full setup down here: https://lnkd.in/dNV_FT_s

What is the easiest way to generate PDF reports?

HTML-to-PDF conversion is my first choice.

I use IronPDF in most commercial projects.

Looking for a free option?

- Puppeteer Sharp
- Headless Chrome browser

But the core idea is what matters here.

With an HTML template, you have more control over formatting.

You can use modern CSS to style the HTML markup.

Here's the high-level implementation:

1. MVC views and the Razor syntax
2. Render dynamic HTML content
3. Pass HTML to PDF renderer

I've used this approach on a few projects with great results.

Want to see how to implement flexible PDF reporting?

Here's a simple guide: https://lnkd.in/dTd_CtGw

How do you implement PDF reporting?

Clean code tip:

- Merge nested IF statements into one condition

I often make this simple change to improve code readability.

Clean code principles will make you a better developer.

But what is clean code in the first place?

Clean code is code that's:

- Easy to read
- Easy to maintain
- Easy to understand

Writing clean code is a skill.

It's a skill you can learn and improve with practice.

In the initial example:

- Nesting increases complexity
- Nesting makes the code harder to reason about

The solution is to combine the nested IF statements into a single IF.

Three ways you can do this:

- Write an inline boolean expression
- Expose a method with the expression
- Create a variable with the expression

But this is just the start.

Here are 8 more clean code tips: https://lnkd.in/dt84mr9J

Which solution do you like better?

---
Sign up for the .NET Weekly with 75K+ other engineers, and get a free Clean Architecture template: https://lnkd.in/ej4nP9pY

Some LINQ queries are much harder to read than the SQL they create.

Left joins are a great example.

You want a simple result:

→ Show all products
→ Include reviews when they exist
→ Keep products with no reviews

But in EF Core, writing that query used to take several steps.

It worked.

It was also easy to get wrong, hard to scan, and not fun to explain to the next person reading your code.

EF Core 10 fixes this with new LeftJoin and RightJoin operators.

Now your query can say what it is actually doing.

Why this matters:

→ Less noise in common queries
→ Clearer intent for your team
→ Fewer workarounds
→ The same SQL result underneath

This is useful for more than products and reviews.

Think:

→ Users with optional settings
→ Orders with optional shipping data
→ Customers with optional invoices

Anywhere related data may be missing, a clean join makes the code easier to trust.

I wrote a practical guide to the new join operators in EF Core 10, including how they compare to the old approach and when to use each one.

Read it here:
https://lnkd.in/dcK2Nvnq

Injecting settings in .NET?

You have 3 main interfaces to choose from. But picking the wrong one means your app might completely ignore your config changes.

Here is the simple breakdown:

1️⃣ IOptions
• Read once at startup.
• Cached for the entire lifetime of the app.
• Perfect for static settings that never change.

2️⃣ IOptionsSnapshot
• Re-evaluated on every single request.
• Picks up appsettings.json changes without restarting your app.
• Perfect for web APIs (Scoped lifetime).

3️⃣ IOptionsMonitor
• Real-time updates.
• Triggers an event exactly when a setting changes.
• Perfect for background services (Singleton lifetime).

The Rule of Thumb: Use IOptions for static config. Upgrade to IOptionsSnapshot in web apps. Reach for IOptionsMonitor when you need change notifications in background workers.

Want a deeper dive into how the Options Pattern works under the hood?

Read my full breakdown here: https://lnkd.in/d4wfFdC9

Which of these three do you find yourself using the most?

---

Tired of writing the same boilerplate code for every new project? Skip the setup and start building features immediately with my Clean Architecture template: https://lnkd.in/dCddeyp7

45,000+ developers use my Clean Architecture template. The most common question I get about it now is how to make AI write code that fits it.

So I made it a first-class feature.

My Clean Architecture template now ships with 4 agent skills:

/add-feature turns one sentence into a full vertical slice. Command or query, handler, validator, minimal API endpoint, unit and integration tests.

/add-entity wires a new entity through every layer. Error catalog, domain events, EF configuration, migration.

/add-tests reads an existing use case, lists every outcome, then covers each failure path and the happy path.

/ca-review checks your pending changes before you commit. Layer violations, missing auth, cache invalidation, test gaps.

I type "/add-feature snooze a todo until a given date" and get the command, the validator, the handler with an ownership check and a domain event, the endpoint, and 9 tests. Built and verified, in the same shape as every other feature in the solution.

Each skill is a plain Markdown file. Renamed your layers or swapped your test stack? Edit the skill once and every future feature follows suit. It's your team's conventions doc, except it executes.

Get it here: https://lnkd.in/dhrJDAKX

No - you aren't doing "integration" testing with an in-memory database.

At best it's a glorified unit test...

I've seen many examples using the EF Core in-memory provider.

This isn't an integration test because there's no real database.

Worse, this will fail to catch any LINQ or SQL bugs.

Here's a better approach:

- Use a real database or Docker container
- Connect to this database from your tests
- Write proper integration tests that have value

If you want to use Docker, I recommend exploring Testcontainers.

It lets you define throwaway containers in your tests.

What tools or methods do you use for integration testing?

Want to build fast and scalable applications?

Here's how database read replicas can help.

First, let's explain what a read replica is. A database read replica is a 1-1 copy of your primary database. All writes go to the primary database, which streams changes to the read replica.

The replication is usually asynchronous, so there is some replication lag. Keep this in mind if stale data isn't acceptable for a business use case.

Using a read replica gives you a few benefits:

- Scaling read-heavy workloads
- Improved availability (uptime)
- Disaster recovery

Let's break these down one by one.

Routing read queries to the read replica can reduce the load on your primary database. The read replica can also have more compute resources to serve queries better.

In case of an outage on the write database, you can redirect reads to the read database while you restore the write database. This can help minimize downtime and ensure your application remains available to users.

In a disaster scenario where you can't fix the primary database, you can do a failover and promote the read replica to a primary database.

Most relational databases support read replicas, and PostgreSQL is a great example. For example, you can create a read replica with a managed service like Amazon RDS for PostgreSQL.

How can you make use of this in a .NET application?

You can create multiple EF Core DbContexts - one for the primary and one for the replica.

Most Keycloak setups you see online are not production-ready.

They use the embedded database and call it a day.

That works for a demo.
It is not the setup you want for a real system.

If you plan to run Keycloak seriously, the baseline is simple:

• Use a real database like Postgres
• Isolate Keycloak into its own schema
• Configure the DB connection explicitly
• Let Keycloak scaffold its own tables
• Verify the full auth flow end to end
• Inspect the database so you understand what it is actually doing

One thing that stands out very quickly is how much complexity Keycloak hides from you.

Realms, clients, users, credentials, sessions, mappings, and a surprisingly large schema behind it all.

Authentication is not a small feature.
It is a system.

I put together a practical walkthrough showing exactly how I set this up with Postgres, Docker Compose, Swagger, and a look at the schema under the hood.

Watch here: https://lnkd.in/dRjEvqxz