Forem: Ayman Atif

3 LINQ Mistakes That Hurt Backend API Performance in .NET

Ayman Atif — Mon, 27 Apr 2026 17:24:31 +0000

LINQ looks clean and harmless in C#.

But in real backend APIs, small mistakes can quietly turn into serious performance issues.

Here are 3 I’ve seen (and made) while working with .NET and Entity Framework:

1. Loading entire tables into memory

A common mistake is doing this:

var orders = dbContext.Orders.ToList();

var recent = orders.Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7));

This pulls everything into memory first, then filters in C#.

The problem:

unnecessary memory usage
slow processing on large datasets
wasted database optimization

Fix:

Let the database do the work:

var recent = dbContext.Orders .Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7)) .ToList();

2. Hidden multiple database calls

LINQ queries can be deceptively reused:

var query = dbContext.Orders.Where(o => o.Total > 100);

var count = query.Count();
var list = query.ToList();

This can result in multiple database executions depending on how it's used.

Fix:

Materialize once:

var list = dbContext.Orders .Where(o => o.Total > 100) .ToList();

var count = list.Count;

3. Fetching more data than needed

Another common issue:

var orders = dbContext.Orders.ToList();

var result = orders.Select(o => new { o.Id, o.CustomerName });

You are still loading full rows from the database even though you only need 2 fields.

Fix:

Project early:

var result = dbContext.Orders .Select(o => new { o.Id, o.CustomerName }) .ToList();

Key idea

LINQ itself is not the problem.

The real issue is where the execution happens:

in memory
or in the database

In backend systems, that difference matters a lot.

Closing thought

Most performance issues in APIs are not “big architecture problems”.

They start with small LINQ decisions like these.

I stopped rebuilding the same .NET backend every project (here’s what changed)

Ayman Atif — Sun, 26 Apr 2026 13:20:29 +0000

A couple of years ago, every new .NET project I started looked exactly the same.

The first few days were always the same routine:

set up JWT auth
add roles
figure out refresh tokens
recreate the folder structure

It felt productive at the time.

But looking back, it was just repetition.

The worst part wasn't even the time I lost.

It was the same small mistakes that kept coming back over and over:

auth edge cases
inconsistent structure across projects
temporary decisions that somehow stayed forever

Every project started out messy before it even had a chance to become something good.

At some point, I just got tired of it.

So instead of rebuilding everything from scratch again, I created a base system I could reuse on every project.

A simple rule: if I have solved it once, I should not have to solve it again.

I ended up with something like this:

a Clean Architecture structure auth already wired up with JWT, roles, and refresh tokens
a predictable project layout
no more "I will fix this later" parts

The difference was immediate.

When I start a new project now, I do not touch the setup anymore. I go straight into building actual features.

Another thing I noticed: a lot of these same patterns show up in interviews. Not the exact code, but the thinking behind it. How auth flows work. How you structure projects. How you avoid common mistakes.

So I started documenting those patterns too.

Now I basically have a starter system I use for everything. It is not perfect. But it is consistent, and that is what matters.

If you are in that phase where every project starts from zero, try this: build your own base system once. It does not have to be fancy. Just something you can trust and reuse.

I also turned mine into a small bundle, an API starter plus interview prep, since a few people asked for it:

https://yaman95.gumroad.com/l/full-dotnet-backend-system

I opened affiliates for my .NET interview guide (but here’s why I hesitated)

Ayman Atif — Sat, 25 Apr 2026 17:50:23 +0000

A few months ago, I kept seeing the same pattern in .NET interviews.

Not “hard questions”…
Just the same concepts, asked in slightly different ways.

Things like:

Thread

vs Task
Async pitfalls
Database performance questions

At some point, I stopped studying randomly and started tracking patterns.

That’s what helped me pass interviews faster.

So I turned it into a small guide:

Real questions I’ve personally faced
The patterns behind them
Simple explanations (not textbook stuff)

Now here’s the part I wasn’t sure about:

I opened an affiliate program for it.

Not because I want “marketers”…
But because I know some devs already create content around:

Interview prep
Junior dev journeys
Learning C# / .NET

And this might actually help their audience.

If you create content in that space, I’m happy to:

Give you full access to the guide
Let you decide if it’s worth sharing
And if you do, you can earn from it

👉 Affiliate link:
https://yaman95.gumroad.com/affiliates

Either way, even if you’re not interested in affiliates:

Curious... what’s one question you keep seeing in .NET interviews?

Why .NET interviews feel harder than they should

Ayman Atif — Fri, 24 Apr 2026 14:19:20 +0000

Most .NET interview prep goes into learning concepts.

But in actual interviews, I’ve noticed something else matters more.

It’s not just what you know, it’s how you explain it.

A lot of people run into the same issues:

They start explaining too much at once, or they lose clarity halfway through their answer.

And even simple questions like “what’s the difference between IEnumerable and IQueryable?” end up sounding more complicated than they are.

I think the better approach is actually pretty simple:

Start with a clear, short answer first. Then add detail only if needed.

Something like:
“IEnumerable works in memory, IQueryable works with the database.”

Then expand from there if the interviewer wants more.

It sounds small, but it changes how your answers come across a lot.

At the end of the day, interviews are less about how much you know, and more about how clearly you can communicate it.

If you're preparing for .NET interviews, this is something worth paying attention to.