Sometimes an API returns exactly what the client requested, passes all its tests, and produces no errors. Yet users still complain that the application feels slow.
Where should we look?
It's tempting to blame the database immediately. But backend performance problems are not always caused by slow SQL queries. Sometimes the real issue is how the application retrieves, processes, and delivers information.
Consider a common situation in a business application.
A dashboard needs to display customer information, recent transactions, payment status, and monthly summaries. The backend makes several database calls, processes the results, and returns a response to the frontend.
Everything works.
But as the number of records increases, the dashboard takes longer to load.
This is where backend developers need to look beyond whether the code works.
A few areas are worth investigating.
1. Database queries that retrieve too much data
Using Entity Framework makes database operations convenient, but convenience doesn't automatically mean efficient queries.
For example, loading complete entities when the application only needs three fields can create unnecessary data retrieval and processing.
Projection with Select() can help retrieve only the required columns.
2. The N+1 query problem
Imagine retrieving a list of 100 customers and then executing another query for each customer's orders.
That's potentially 101 database queries instead of a more efficient approach.
Depending on the use case, projections, joins, or carefully designed eager loading can reduce unnecessary database round trips.
3. Missing pagination
Returning thousands of records in a single API response is rarely necessary for a normal list page.
Pagination helps control response size and database workload.
For large datasets, developers should also consider suitable indexing and efficient pagination strategies.
4. Expensive business logic
Not every performance problem comes from SQL Server.
Complex calculations, repeated object mapping, unnecessary loops, and synchronous operations can also increase response time.
Profiling the application helps identify where the actual time is being spent.
5. Returning more information than the frontend needs
A good API contract should be designed around the information required by the client.
Returning an entire database entity when a small response DTO would be sufficient can make the API unnecessarily complicated and increase data transfer.
Measure before optimizing
One thing I strongly believe is that performance optimization should start with evidence, not assumptions.
Useful tools include:
- SQL Server Query Store for examining query performance.
- Application logging for understanding request execution.
- Entity Framework query logging for inspecting generated SQL.
- Profiling tools for identifying expensive application operations.
A backend application doesn't become faster simply because we rewrite a few methods or add caching everywhere.
Sometimes one poorly designed query is responsible for most of the delay. In other cases, the bottleneck is somewhere completely different.
The real skill is finding the actual bottleneck before changing the code.
I'd like to hear from other .NET and backend developers:
When an ASP.NET Core API becomes slow as the application grows, what do you investigate first: SQL queries, Entity Framework behavior, application-level processing, or network communication?
What performance issue has surprised you the most in a real project?