DEV Community: ConvergeSol

.NET 10 for Enterprise Applications: What Developers Should Evaluate Before Upgrading

ConvergeSol — Tue, 29 Sep 2026 12:00:00 +0000

A .NET upgrade can start with a simple pull request:

TargetFramework = net10.0

The difficult part comes after that.

Enterprise applications rarely depend on the .NET runtime alone. They may include custom middleware, authentication systems, Entity Framework Core queries, third-party packages, background workers, cloud infrastructure, containers, and external APIs.

So when developers ask "What are the important .NET 10 features?", there is another question worth asking:

Which .NET 10 capabilities are actually relevant to the application I'm maintaining?

This article looks at that question from a practical engineering perspective.

Why a .NET 10 Upgrade Needs More Than Compatibility Testing

Getting an application to compile on .NET 10 is only the first milestone.

A production migration should also answer:

Did API performance change?
Did CPU or memory usage change?
Are existing dependencies compatible?
Did authentication and authorization continue working?
Are database queries behaving as expected?
Did container startup time improve?
Can the application still meet its production SLAs?
Is the deployment and rollback process ready?

This is why performance and production baselines should be captured before starting the migration.

Useful metrics include:

API latency
P95 / P99 response time
Requests per second
CPU utilization
Memory usage
GC activity
Database latency
Error rate
Container startup time

Without a baseline, it's difficult to determine whether an upgrade actually improved the application.

1. .NET 10 Runtime Performance

Runtime improvements are one of the obvious areas to evaluate.

But don't assume a newer runtime automatically means every application becomes faster.

Performance depends on the application's workload, architecture, dependencies, database behavior, and traffic patterns.

For example, one healthcare SaaS workload associated a .NET 10 evaluation with:

14% lower average API response time
11% lower quarterly cloud compute costs during peak usage

Those figures are specific to that workload rather than universal .NET 10 benchmarks.

For your own application, compare metrics before and after the upgrade.

The most useful question isn't:

"Is .NET 10 faster?"

It's:

"Which part of my application became faster, and by how much?"

2. ASP.NET Core API Performance

Enterprise applications often expose their most important functionality through ASP.NET Core APIs.

But an API's performance isn't determined by ASP.NET Core alone.

Consider a request such as:

Client
  ↓
API Gateway
  ↓
Authentication
  ↓
Middleware
  ↓
ASP.NET Core Endpoint
  ↓
Business Logic
  ↓
EF Core
  ↓
Database
  ↓
External Service
  ↓
JSON Response

If the database takes 500 ms, improving framework-level execution may have little impact on the total response time.

During a .NET 10 migration, test the complete request pipeline.

Pay particular attention to:

Authentication middleware
Authorization
Custom middleware
Routing
Dependency injection
Serialization
Third-party packages
External APIs

One digital banking platform evaluation associated a phased .NET upgrade with an 8–12% reduction in latency, while also identifying compatibility problems with legacy authentication middleware.

That's a good example of why migration testing needs to cover both performance and compatibility.

3. Native AOT: Where Does It Actually Make Sense?

Native AOT is particularly interesting for applications where startup time matters.

Potential use cases include:

Serverless functions
Containerized microservices
Short-lived workers
Frequently scaled services

However, Native AOT can expose compatibility problems in older applications.

Reflection-heavy code, dynamic loading, and certain dependencies may require changes before an application can be compiled successfully.

In one migration assessment, around 35% of tested legacy systems initially failed AOT builds because of older patterns or incompatible dependencies.

So don't approach Native AOT as:

.NET 10
+
Native AOT
=
Faster application

Instead, evaluate:

Startup-sensitive workload
        ↓
AOT compatibility
        ↓
Benchmark
        ↓
Operational benefit

If startup time isn't a meaningful problem for the workload, Native AOT may not be the first capability worth prioritizing.

4. System.Text.Json and Serialization

Serialization can become a hidden source of CPU consumption in high-volume APIs.

Applications that frequently process large or complex JSON payloads should evaluate:

Large object graphs
Custom converters
Polymorphic serialization
Reflection-heavy models
Large API responses
Repeated serialization/deserialization

One government SaaS workload recorded an 18%+ reduction in CPU usage on critical endpoints after serialization-related optimization.

Again, this isn't a universal benchmark.

The useful lesson is to profile serialization when CPU usage is already a concern instead of assuming the runtime is responsible for all application overhead.

5. EF Core: Check the Database Before Blaming .NET

A .NET upgrade won't automatically fix inefficient database access.

This is particularly important for applications using Entity Framework Core.

Common problems include:

N+1 queries
Missing indexes
Inefficient joins
Excessive tracking
Oversized queries
Poor pagination
Repeated database calls
Unnecessary round trips

Consider an endpoint that takes 800 ms:

Application processing     100 ms
Database operations       600 ms
Serialization              50 ms
Other                      50 ms
-------------------------------
Total                     800 ms

Reducing application processing from 100 ms to 80 ms doesn't solve the primary bottleneck.

The database still accounts for most of the request time.

A .NET 10 migration is therefore a good opportunity to profile EF Core queries, but it shouldn't be treated as a substitute for database optimization.

6. OpenTelemetry and Distributed Diagnostics

Modern enterprise systems are increasingly distributed.

A single user request may travel through:

API
 ↓
Authentication Service
 ↓
Database
 ↓
Message Queue
 ↓
Background Worker
 ↓
External API

When an incident occurs, application logs alone may not provide enough context.

Distributed tracing can help answer:

Where did the request slow down?
Which dependency failed?
How long did the database call take?
Which service generated the exception?
Was the problem isolated to one endpoint?

OpenTelemetry can provide a standardized way to collect and connect these signals.

In one large logistics environment, improvements that included better observability were associated with reducing mean time to resolution from 44 minutes to 15 minutes.

The broader lesson for developers is that application performance and application diagnosability are closely connected.

7. .NET 10 in Containers and Cloud Environments

Many enterprise .NET applications run in containers or cloud environments.

When upgrading, don't only test the application locally.

Validate:

Container startup
Memory limits
CPU limits
Health checks
Environment variables
Logging
Deployment configuration
Scaling behavior
CI/CD pipelines

It is also useful to separate the framework migration from unrelated infrastructure changes.

For example:

Baseline
   ↓
Upgrade to .NET 10
   ↓
Functional testing
   ↓
Performance testing
   ↓
Production validation
   ↓
Infrastructure optimization

This makes it easier to understand which change produced a measurable result.

8. Security and Dependency Compatibility

A framework upgrade also means reviewing the application's dependency chain.

Check:

NuGet packages
Authentication libraries
Authorization components
Cryptography usage
Secrets management
Identity providers
Security middleware
Cloud permissions

An application running successfully on .NET 10 isn't necessarily ready for production.

Security and compliance requirements still need to be validated independently.

This is especially important for financial, healthcare, government, and other regulated applications.

9. Don't Turn a Framework Upgrade Into an Uncontrolled Rewrite

Migration projects often uncover technical debt.

You might find:

Deprecated APIs
Old packages
Tightly coupled services
Difficult-to-test components
Legacy configuration
Inconsistent dependency injection
Reflection-heavy code

It can be tempting to fix everything while you're already touching the application.

That can quickly turn a framework upgrade into a rewrite.

A better approach is to separate:

Required migration changes

from

Future modernization work

Fix what is necessary for compatibility, security, and production readiness. Track unrelated technical debt separately.

10. Plan the Rollout, Not Just the Code Changes

A successful .NET 10 migration needs an operational plan.

Before production deployment, consider:

Staging validation
Database compatibility
Monitoring
Deployment sequencing
Rollback procedures
Support-team readiness
Production health checks

For larger applications, a phased rollout can reduce the impact of unexpected compatibility or performance issues.

One enterprise migration program reported a 75% reduction in rollback events after introducing a more controlled migration approach.

That result is specific to that program, but the underlying principle is broadly useful:

The migration strategy is part of the engineering work.

How Should Developers Evaluate .NET 10?

Rather than creating a checklist of features to adopt, connect each capability to a measurable problem.

For example:

Problem                         Area to investigate

Slow APIs                  →    Runtime / ASP.NET Core
High CPU usage             →    Runtime / Serialization
Slow startup               →    Native AOT
Database latency           →    EF Core / SQL
Hard-to-debug incidents    →    OpenTelemetry
Cloud resource usage       →    Runtime / Infrastructure
Legacy dependencies        →    Compatibility
Deployment risk            →    Rollout strategy

This approach keeps the migration focused.

You don't need to adopt every .NET 10 capability simply because it exists.

You need to determine which ones provide value for your application's architecture and workload.

A Practical .NET 10 Migration Sequence

For an existing enterprise application, a simple migration workflow could look like this:

Step 1: Capture the baseline

Record performance, resource usage, errors, and operational metrics.

Step 2: Audit dependencies

Review NuGet packages, middleware, authentication, database libraries, and external integrations.

Step 3: Upgrade in a controlled environment

Move the application to .NET 10 and resolve compatibility issues before production testing.

Step 4: Run regression tests

Validate business workflows, APIs, authentication, background jobs, and integrations.

Step 5: Benchmark important workloads

Compare the new runtime against the baseline using realistic traffic and production-like data.

Step 6: Validate production readiness

Check monitoring, deployment, rollback, security, and infrastructure configuration.

Step 7: Roll out gradually

Use a controlled production rollout where the application architecture and business requirements allow it.

Final Thoughts

.NET 10 gives developers plenty to evaluate, but a successful enterprise migration isn't about adopting the largest possible number of new features.

It's about finding the capabilities that solve real engineering problems.

If your application has slow APIs, startup delays, high CPU usage, difficult production diagnostics, database bottlenecks, or growing maintenance costs, those problems provide a much better starting point than the release notes.

Measure the application. Identify the bottleneck. Test the relevant .NET 10 capability. Then make the migration decision based on the results.

For a deeper look at the production implications of .NET 10, including the features, performance considerations, security, cloud deployment, and migration strategy that enterprise teams should evaluate, see the full article:

👉 .NET 10 in Production: 10 Features That Actually Matter for Enterprise Applications

What to Remember

.NET 10 performance should be measured against your own application baseline.
ASP.NET Core improvements don't eliminate database or dependency bottlenecks.
Native AOT is most relevant when startup time matters and dependencies support it.
Serialization can affect CPU usage in high-volume APIs.
EF Core performance still depends heavily on query design and database architecture.
OpenTelemetry can improve visibility across distributed systems.
Security and dependency compatibility need independent validation.
A phased rollout can reduce migration risk.

The best .NET 10 migration isn't necessarily the one that adopts the most features.

It's the one that produces measurable improvements without compromising production stability.

Why Is My ASP.NET Core API Slow? 5 Things to Check First

ConvergeSol — Tue, 22 Sep 2026 12:03:58 +0000

You deploy an ASP.NET Core API expecting it to be fast.

Then someone reports:

“This endpoint takes 2–3 seconds to respond.”

You check the server.

CPU looks fine.
Memory looks fine.
The database server isn't overloaded.

So where is the time going?

In many cases, the problem isn't ASP.NET Core itself. The delay is hidden somewhere inside the request path — a database round trip, blocking code, an external API, a large response, or application logic.

Here are 5 things I check first when troubleshooting a slow ASP.NET Core API.

1. Check How Many Database Queries One Request Executes

One of the easiest performance problems to miss with EF Core is the N+1 query problem.

For example:

var orders = await dbContext.Orders.ToListAsync();

foreach (var order in orders)
{
    var items = await dbContext.OrderItems
        .Where(x => x.OrderId == order.Id)
        .ToListAsync();
}

If the first query returns 100 orders, the application can end up making 101 database queries.

The code looks reasonable when reading it line by line.

The database sees something very different.

Instead of asking:

"Is this LINQ query correct?"

also ask:

"How many SQL commands does this request actually generate?"

Look at your SQL logs, profiler, APM tool, or database monitoring data.

For read-heavy endpoints, projection can often be a better approach:

var orders = await dbContext.Orders
    .Select(o => new OrderDto
    {
        Id = o.Id,
        CustomerName = o.Customer.Name,
        Total = o.Items.Sum(i => i.Price * i.Quantity)
    })
    .ToListAsync();

The important part isn't blindly replacing every query with Select().

It's understanding the SQL and round trips generated by your application.

2. Search Your Codebase for `.Result` and `.Wait()`

This is one of the quickest checks I make when an ASP.NET Core API suddenly becomes slow under load.

Look for patterns such as:

var result = service.GetDataAsync().Result;

or:

service.GetDataAsync().Wait();

These calls can block threads while asynchronous work is waiting for I/O.

Under light traffic, you might never notice.

Under higher concurrency, blocked threads can contribute to thread pool starvation and increasing request latency.

Prefer async all the way through the request path:

var result = await service.GetDataAsync();

The important question isn't simply:

"Does this endpoint use async?"

Trace the entire call chain.

Controller → service → repository → database/API

One blocking call buried in that chain can still become a problem.

3. Check Whether Your API Is Waiting for Another API

Your endpoint may look fast from the application code perspective, but your API could actually be spending most of its time waiting for another service.

For example:

Client
  ↓
ASP.NET Core API
  ↓
Customer Service
  ↓
Payment Service
  ↓
External Provider

If the external provider takes 800 ms, optimizing a few lines of C# won't suddenly make the request 100 ms.

This is where distributed tracing becomes useful.

Instead of only measuring:

Request: 1.4 seconds

you want something closer to:

Total request:       1400 ms
Database:             120 ms
Customer API:         180 ms
Payment API:          850 ms
Serialization:         40 ms
Application logic:    210 ms

Now you have somewhere specific to investigate.

Measure the individual dependencies instead of guessing from the total response time.

4. Look at the Size of Your Response

Sometimes the database query isn't the main problem.

The API simply returns too much data.

For example, an endpoint might return an entire entity when the frontend only needs five fields.

var customers = await dbContext.Customers
    .ToListAsync();

If Customer contains dozens of properties and relationships, you're potentially retrieving and serializing much more data than necessary.

A DTO can make the response contract explicit:

var customers = await dbContext.Customers
    .Select(x => new CustomerDto
    {
        Id = x.Id,
        Name = x.Name,
        Email = x.Email,
        Status = x.Status
    })
    .ToListAsync();

Also check for:

Large collections
Missing pagination
Deeply nested JSON
Unnecessary navigation properties
Repeated data in responses
Expensive serialization

A 5 KB response and a 5 MB response are very different performance problems.

5. Don't Optimize Until You Know Where the Time Goes

This is probably the most important one.

When an API is slow, it's tempting to immediately:

Add caching
Increase server resources
Rewrite LINQ queries
Change the database
Add more application servers
Replace EF Core
Rewrite the endpoint

Sometimes those changes help.

Sometimes they solve the wrong problem.

Start with measurements.

A simple troubleshooting flow is:

Measure
   ↓
Trace
   ↓
Find the bottleneck
   ↓
Fix it
   ↓
Measure again

For example, if your endpoint takes 1.8 seconds:

Don't start with:
"Let's optimize the C# code."

Start with:
"Where are those 1.8 seconds being spent?"

That question usually leads to a much better investigation.

What About the Other ASP.NET Core Performance Problems?

These five checks are only a starting point.

Slow ASP.NET Core APIs can also be affected by:

Inefficient SQL queries
Missing database indexes
Poor caching strategies
Connection management
Excessive middleware
Excessive logging
Inefficient application logic
Serialization overhead
Production configuration
Lack of performance profiling

The important thing is to avoid treating "slow API" as a single problem.

Find the bottleneck first.

Once you know whether the time is being spent in SQL, application code, network calls, serialization, or something else, the optimization becomes much more targeted.

Final takeaway

When an ASP.NET Core API is slow, don't immediately blame the framework.

Start by asking:

How many database queries does this request execute?
Is anything blocking an async operation?
Is the API waiting on another service?
How much data is being returned?
Where is the request actually spending its time?

Those five questions can eliminate a lot of guesswork.

If you're troubleshooting a production API, the next step is to look beyond these five checks and examine the other bottlenecks that can affect request latency, database performance, caching, connections, middleware, and application logic.

👉 Read the full guide:
Why ASP.NET Core API Is Slow: 10 Performance Bottlenecks and How to Fix Them

Read the full guide on ConvergeSol

EF Core N+1 Query Problem: How to Detect, Measure, and Fix It

ConvergeSol — Tue, 15 Sep 2026 11:47:53 +0000

Your EF Core code can look clean, pass every functional test, and still make hundreds of database calls for a single API request.

That is the N+1 query problem.

It is one of those performance issues that can remain invisible during development because small datasets make inefficient database access look harmless. Once the same application handles larger datasets and real concurrency, the extra database round trips can become a significant performance bottleneck.

In this article, we'll look at:

What the N+1 query problem actually means
How it develops in EF Core
Why it is easy to miss during development
How to measure database query behavior
When to use Include(), Select(), or explicit loading
Why fewer queries isn't always the goal
How to prevent N+1 problems from reaching production

What Is the N+1 Query Problem?

The N+1 pattern occurs when an application executes:

1 query to retrieve a collection of records
N additional queries to retrieve related data for each record

For example, suppose an API retrieves 100 invoices:

var invoices = await context.Invoices
    .ToListAsync();

That is one database query.

Now imagine the application accesses a related customer for every invoice:

foreach (var invoice in invoices)
{
    Console.WriteLine(invoice.Customer.Name);
}

If lazy loading is enabled and configured, accessing invoice.Customer can trigger another database query for each invoice.

The resulting database activity could look like:

1 query for invoices
+ 100 queries for customers
---------------------------
101 database queries

That is the N+1 pattern.

The important point is that N is not always 100. It depends on how many parent records are returned.

For 10 records:

1 + 10 = 11 queries

For 1,000 records:

1 + 1,000 = 1,001 queries

The problem scales with the data.

Does EF Core Automatically Cause N+1 Queries?

No.

Simply using EF Core or having navigation properties does not automatically mean your application has an N+1 problem.

N+1 behavior typically develops when related data is loaded repeatedly, such as through lazy loading or application code that performs additional queries inside a loop.

For example:

var orders = await context.Orders
    .ToListAsync();

foreach (var order in orders)
{
    var customer = await context.Customers
        .FirstAsync(c => c.Id == order.CustomerId);

    Console.WriteLine(customer.Name);
}

The problem is easier to see here:

1 query → Orders

N queries → Customer for each Order

The code is functionally correct.

That is what makes N+1 dangerous.

Why N+1 Queries Are Easy to Miss

N+1 problems often survive development and testing because developers test with small datasets.

Imagine testing an API with five records:

1 + 5 = 6 queries

Six queries may not look concerning.

But production could return 500 records:

1 + 500 = 501 queries

Now consider concurrent requests.

If 20 users trigger the endpoint at roughly the same time:

501 queries × 20 requests
= 10,020 database queries

The exact impact depends on query complexity, latency, database capacity, concurrency, indexing, and other workload characteristics, but the example illustrates how quickly query counts can grow.

This is why functional correctness is not enough to validate database performance.

What Does N+1 Look Like in Production?

The problem is not just the number of SQL statements.

Every additional database round trip can contribute to:

Higher API latency
Increased database workload
More connection and resource pressure
Higher infrastructure costs
Reduced scalability
Greater risk of SLA/SLO violations
Poorer user experience

And the problem can compound as data volume and concurrent traffic increase.

A page that feels perfectly responsive with development data can behave very differently when the application processes thousands or millions of production records.

How to Detect N+1 Queries in EF Core

The first rule is simple:

Measure the SQL behavior instead of assuming the LINQ code tells the whole story.

1. Enable EF Core SQL Logging

During development, EF Core logging can help reveal how many SQL commands are being executed.

For example:

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options
        .UseSqlServer(connectionString)
        .LogTo(Console.WriteLine, LogLevel.Information);
});

You can then inspect the generated SQL.

If you expected one database operation but see a repeated pattern such as:

SELECT ... FROM Orders

SELECT ... FROM Customers WHERE Id = 1
SELECT ... FROM Customers WHERE Id = 2
SELECT ... FROM Customers WHERE Id = 3
...

you may have an N+1 problem.

2. Count Queries Per Request

SQL logs are useful, but query counts are even more valuable when you want to detect regressions.

For example, you might establish a rule such as:

Endpoint: GET /api/orders
Expected SQL commands: ≤ 5
Actual SQL commands: 87

That immediately gives the development team something measurable to investigate.

For critical APIs, query-count thresholds can become part of automated performance testing.

3. Inspect Generated SQL

LINQ can hide database behavior.

This query:

var orders = await context.Orders
    .Where(o => o.Status == "Open")
    .ToListAsync();

looks simple.

But what matters in production is the SQL EF Core actually sends to the database.

Use SQL logging and profiling tools to understand:

Number of SQL commands
Query duration
Returned rows
Repeated queries
Large result sets
Expensive joins
Unexpected database access

The database workload—not just the C# syntax—is what ultimately affects performance.

How to Fix the N+1 Problem in EF Core

There isn't one universal solution.

The right approach depends on the data you actually need.

Three common approaches are:

Include()
Select()
Explicit loading

1. Use Include() When You Need Related Entities

If an endpoint genuinely needs the related entity data, eager loading can avoid repeatedly loading related records.

For example:

var orders = await context.Orders
    .Include(o => o.Customer)
    .ToListAsync();

You can then access:

foreach (var order in orders)
{
    Console.WriteLine(order.Customer.Name);
}

without relying on per-record lazy loading for the customer relationship.

However, Include() should not automatically be treated as the best solution for every query.

If you load a large or deeply connected object graph, you may retrieve much more data than the application actually needs.

2. Prefer Select() When You Only Need Specific Fields

For read-only APIs, projections are often a better fit.

Instead of loading complete Order and Customer entities:

var orders = await context.Orders
    .Include(o => o.Customer)
    .ToListAsync();

you might project directly into the response model:

var orders = await context.Orders
    .Select(o => new OrderSummary
    {
        OrderId = o.Id,
        CustomerName = o.Customer.Name,
        Total = o.Total
    })
    .ToListAsync();

This communicates exactly what the API needs.

Projection can help reduce:

Unnecessary columns
Object materialization
Memory usage
Data transfer
Complex entity graphs

For read-heavy APIs and reporting scenarios, Select() is often worth considering before reaching for broad Include() calls.

3. Use Explicit Loading When You Need More Control

Sometimes related data is needed conditionally.

Explicit loading allows you to decide when the relationship should be loaded:

var order = await context.Orders
    .FirstAsync(o => o.Id == orderId);

await context.Entry(order)
    .Reference(o => o.Customer)
    .LoadAsync();

This provides more control, but it also adds complexity.

It is most useful when the application genuinely needs conditional or targeted loading rather than loading an entire object graph upfront.

Include() vs Select() vs Explicit Loading

Approach	Best For	Main Benefit	Potential Concern
`Include()`	Entity graphs	Convenient related-data loading	Can load more data than necessary
`Select()`	Read APIs / DTOs	Retrieves only required fields	Requires projection design
Explicit loading	Conditional relationships	Fine-grained control	More verbose and easier to misuse

The important question isn't:

"Which one is always fastest?"

Instead ask:

"What data does this operation actually need?"

Fewer Queries Isn't Always Better

This is an important distinction.

The goal isn't simply to reduce:

100 queries → 1 query

at any cost.

A single enormous query can also create problems.

For example, loading a large object graph with multiple collection relationships can result in:

Large result sets
Excessive joins
Duplicate data in result rows
Higher memory consumption
More complicated SQL
Longer database execution times

So the real objective is:

Predictable database behavior and appropriate data access—not simply the lowest possible query count.

Sometimes two well-designed queries are better than one unnecessarily large query.

A Practical Example

Consider an insurance dashboard that displays:

Policy information
Customer details
Coverage information
Recent claims

A simplistic implementation might load policies first and then retrieve related data repeatedly.

With 400 policies, the application could unexpectedly generate hundreds of database calls.

The better approach is to first understand what the dashboard actually needs.

If it only needs:

Policy Number
Customer Name
Coverage Type
Claim Count

then loading complete entities and their entire relationship graph may be unnecessary.

A projection could retrieve the required read model directly:

var dashboard = await context.Policies
    .Where(p => p.IsActive)
    .Select(p => new PolicyDashboardDto
    {
        PolicyNumber = p.PolicyNumber,
        CustomerName = p.Customer.Name,
        CoverageType = p.Coverage.Type,
        ClaimCount = p.Claims.Count()
    })
    .ToListAsync();

The key is that the application is designed around the required data rather than around the entity structure alone.

How to Prevent N+1 Problems Before Production

Fixing an N+1 problem after customers report slow performance is much more expensive than detecting it during development.

A practical prevention strategy includes:

1. Review SQL behavior

Don't review only the LINQ.

Review the generated SQL and query count.

2. Test with realistic datasets

Five records aren't enough to validate a query pattern that will process 5,000 records in production.

3. Monitor query counts

For important APIs, establish reasonable query-count thresholds.

4. Profile slow endpoints

Look at:

Request duration
SQL execution time
Number of database commands
Rows returned
Database resource usage

5. Review data-loading strategy

Ask whether the endpoint really needs:

Full entity
+ related entity
+ nested collection
+ another nested collection

or whether a small projection is enough.

6. Include database behavior in performance testing

A performance test should measure more than HTTP response time.

It should also help answer:

How much database work was required to produce this response?

A Simple EF Core N+1 Checklist

Before shipping a data-heavy endpoint, ask:

[ ] How many SQL commands does one request execute?
[ ] Does a loop trigger additional database calls?
[ ] Is lazy loading enabled?
[ ] Are related entities actually required?
[ ] Could Select() return only the required fields?
[ ] Would Include() load too much data?
[ ] Would explicit loading provide better control?
[ ] Have we tested with realistic data volumes?
[ ] Have we tested under concurrent requests?
[ ] Do we have query-count or performance thresholds?
[ ] Have we inspected the generated SQL?

If you can't answer these questions, the endpoint probably needs more database-level testing.

The Real Lesson

The N+1 query problem is not simply an EF Core coding mistake.

It is a data-access and scalability problem.

The C# code may look clean.

The API may return the correct response.

The automated tests may pass.

But the database may still be doing far more work than necessary.

The most effective approach is to:

Measure → Understand → Optimize → Test at scale → Monitor

And remember:

The goal isn't simply fewer queries. The goal is predictable performance at scale.

If you're building or maintaining ASP.NET Core applications with EF Core, measuring actual database behavior should be part of your performance workflow—not something you investigate only after production slows down.

Read the Full Analysis

For a deeper breakdown of the N+1 problem, production impact, measurement techniques, and EF Core optimization strategies, read the full ConvergeSol guide: 100 Database Queries vs 1 Query: Measuring the N+1 Problem in EF Core

dotnet #efcore #csharp #performance

What Causes Thread Pool Starvation in ASP.NET Core APIs? A Practical Guide

ConvergeSol — Mon, 07 Sep 2026 13:30:43 +0000

Have you ever had an ASP.NET Core API that looked perfectly healthy in production, yet suddenly became slow under load?

CPU usage isn't near 100%.

Memory looks normal.

The application is still running.

But response times are increasing, requests are waiting longer, and some users are receiving timeouts.

One possible explanation is Thread Pool starvation.

In this article, we'll look at what Thread Pool starvation means in ASP.NET Core, why blocking operations cause it, how to recognize the symptoms, and which .NET diagnostic tools can help you investigate the problem.

What Is Thread Pool Starvation in ASP.NET Core?

The .NET ThreadPool provides worker threads for executing application work.

Thread Pool starvation occurs when available worker threads become constrained because existing threads are occupied for too long, often due to blocking operations.

For an ASP.NET Core API, this can create a situation where:

Incoming Requests
       ↓
Request Processing
       ↓
Worker Threads Become Blocked
       ↓
Available Workers Decrease
       ↓
Requests Wait in Queue
       ↓
Latency Increases
       ↓
Timeouts / Reduced Throughput

The important part is that the server doesn't necessarily need to show high CPU usage for this to happen.

The Most Common Cause: Blocking Async Code

One of the first things to look for is sync-over-async.

For example:

var result = service.GetDataAsync().Result;

Or:

service.GetDataAsync().Wait();

The underlying operation may be asynchronous, but .Result and .Wait() cause the current thread to block while waiting for the task.

Under light traffic, this might not produce an obvious problem.

Under higher concurrency, the effect can become significant.

Imagine hundreds of requests reaching the same endpoint while worker threads are waiting on I/O. More threads become occupied, new work waits longer, and overall latency can increase.

What Else Can Cause Thread Pool Starvation?

.Result and .Wait() aren't the only things worth investigating.

Other potential sources include:

1. Synchronous I/O

Synchronous database, file, or network operations can keep worker threads occupied while waiting for I/O to complete.

2. Blocking External APIs

An API that synchronously waits for a downstream service can consume a worker thread for the duration of the external call.

3. Third-Party Libraries

A dependency may expose an asynchronous-looking API while internally performing synchronous work.

Always evaluate the behavior of libraries used in critical request paths.

4. Legacy Components

Older application components may rely heavily on synchronous execution patterns that don't scale well with modern high-concurrency workloads.

5. Long-Running Work on Request Threads

CPU-intensive or long-running operations executed directly within request processing can reduce the application's ability to handle additional concurrent requests.

How Do You Know If Thread Pool Starvation Is Happening?

The symptoms can be easy to confuse with infrastructure problems.

Look for combinations of:

Increasing API response times
Growing request queues
Intermittent timeouts
Reduced throughput
Increasing ThreadPool activity
Low or moderate CPU utilization despite poor response times
Performance degradation during traffic spikes

The key is correlation.

If latency increases at the same time that ThreadPool activity and queued work increase, investigate what is occupying those worker threads.

How to Diagnose Thread Pool Starvation

Use `dotnet-counters`

dotnet-counters is useful for observing .NET runtime metrics while an application is running.

For example:

dotnet-counters monitor --process-id <PID>

During an incident or load test, correlate runtime metrics with:

Request rate
Response latency
Throughput
Queue length
Error rate
ThreadPool behavior

The goal isn't to find one magic number.

You're looking for a runtime behavior pattern that corresponds with the performance degradation.

Use `dotnet-trace`

When counters show that something unusual is happening but don't identify the cause, dotnet-trace can provide deeper runtime information.

dotnet-trace collect --process-id <PID>

Tracing can help you investigate thread activity, runtime events, and periods where work is waiting longer than expected.

Use Profiling and Load Testing

Performance profiling is especially useful when combined with realistic load testing.

A blocking operation that appears harmless with a few concurrent requests can become a serious bottleneck when the application handles hundreds or thousands of concurrent operations.

Testing should therefore reflect the expected production workload rather than simply checking whether individual requests succeed.

How Do You Fix Thread Pool Starvation?

The first step is to identify what is blocking the worker threads.

Where possible, replace synchronous waits with asynchronous execution.

Instead of:

var result = service.GetDataAsync().Result;

prefer:

var result = await service.GetDataAsync();

But there's an important caveat.

Changing only the controller method to async isn't enough if the underlying dependency remains synchronous.

Ideally, the asynchronous path should continue through the relevant I/O layers:

Controller
    ↓
Service
    ↓
Repository
    ↓
Async Database / HTTP Operation

If one layer introduces unnecessary blocking, it can still affect scalability.

Don't Automatically Increase ThreadPool Threads

When an application experiences Thread Pool starvation, it can be tempting to increase ThreadPool configuration values.

That may change the symptoms, but it doesn't necessarily fix the underlying problem.

If application code continues blocking worker threads, the application can eventually encounter the same bottleneck again.

Find the blocking operation first.

Configuration should be evaluated based on the application's workload and runtime behavior rather than used as a replacement for application-level fixes.

Should You Add More Servers?

Horizontal scaling can increase capacity, but it isn't always the correct first response.

Suppose every application instance contains the same blocking operation.

Adding more instances may distribute the workload, but the underlying execution pattern remains inefficient.

A better troubleshooting sequence is:

Measure
   ↓
Identify the bottleneck
   ↓
Investigate blocking operations
   ↓
Analyze dependencies
   ↓
Fix the root cause
   ↓
Load test
   ↓
Monitor in production

Infrastructure scaling can still be part of the final solution, but it should be based on evidence.

How Can You Prevent Thread Pool Starvation?

Preventing starvation is easier than diagnosing it during a production incident.

Keep I/O asynchronous

Use asynchronous database, HTTP, and file APIs where supported.

Avoid synchronous waits

Be particularly careful with:

.Result
.Wait()
.GetAwaiter().GetResult()

Review dependencies

Check whether important libraries and integrations introduce synchronous or blocking behavior.

Test under realistic concurrency

Measure how the application behaves when multiple operations execute simultaneously.

Monitor runtime metrics

Application monitoring should include runtime-level signals in addition to CPU, memory, and infrastructure health.

Review production incidents

Use performance incidents to improve code-review standards, testing strategies, observability, and architecture.

Thread Pool Starvation Isn't Just a Server Problem

One of the most important lessons is that API performance isn't determined by infrastructure alone.

A system can have:

Plenty of CPU
Plenty of memory
Multiple application instances
Auto-scaling enabled

…and still experience poor performance because application threads are blocked.

For customer-facing applications, this can affect response times, SLAs, user experience, and operational costs.

The real goal isn't simply to add capacity.

It's to make sure the application can use its available resources efficiently as concurrency increases.

Frequently Asked Questions

What is Thread Pool starvation in ASP.NET Core?

Thread Pool starvation occurs when ThreadPool worker threads are occupied for extended periods, leaving insufficient threads available to process new work efficiently.

What causes Thread Pool starvation in ASP.NET Core?

Common causes include .Result, .Wait(), synchronous I/O, blocking external calls, third-party libraries, and long-running work occupying ThreadPool threads.

How do you detect Thread Pool starvation?

Look for increasing latency, queued requests, reduced throughput, and unusual ThreadPool activity, especially when CPU utilization remains relatively low. Tools such as dotnet-counters and dotnet-trace can provide deeper runtime visibility.

How do you fix Thread Pool starvation?

Identify and remove unnecessary blocking operations, use asynchronous APIs throughout the relevant I/O path, review dependencies, and validate the fix through realistic load testing.

Final Takeaway

When an ASP.NET Core API becomes slow under load, don't look at CPU and memory alone.

Ask what the application is waiting for.

Check for synchronous waits.
Monitor ThreadPool behavior.
Investigate dependencies.
Capture runtime traces when necessary.
Test the application under realistic concurrency.

Thread Pool starvation is often a symptom of a deeper scalability problem. Understanding the relationship between application code, asynchronous execution, dependencies, runtime behavior, and observability can help you build ASP.NET Core APIs that remain reliable as workload increases.

📖 Read the complete technical guide:
Diagnosing Thread Pool Starvation in ASP.NET Core APIs

What Makes ASP.NET Core APIs Secure in Production?

ConvergeSol — Mon, 31 Aug 2026 12:30:00 +0000

Securing an ASP.NET Core API is more than adding JWT authentication and enabling HTTPS.

Once an API moves into production, it often becomes part of a much larger ecosystem. It may serve web and mobile applications, communicate with third-party services, integrate with identity providers, and handle sensitive business data.

That means ASP.NET Core API security needs to cover more than authentication alone.

You need to think about token validation, authorization, identity management, secrets, API configuration, monitoring, and continuous security testing.

Here are some practical areas developers should consider when securing an ASP.NET Core Web API for production.

🔐 1. Validate JWT Tokens Properly

JWT bearer authentication is commonly used to protect ASP.NET Core Web APIs.

But simply configuring JWT authentication doesn't guarantee that incoming tokens are safe.

A production API should validate important token properties, including:

Issuer
Audience
Signature
Expiration
Signing credentials

Proper JWT validation ensures that the token comes from a trusted issuer, was intended for your API, hasn't been modified, and hasn't expired.

Avoid treating the presence of a JWT as proof that the request is authorized.

🛡️ 2. Separate Authentication from Authorization

Authentication and authorization are closely related, but they solve different problems.

Authentication: Who are you?

Authorization: What are you allowed to do?

For example, an authenticated user may be allowed to access the application but shouldn't automatically have permission to access administrative endpoints.

ASP.NET Core supports several authorization approaches:

Role-based authorization
Claims-based authorization
Policy-based authorization

For simple applications, roles may be sufficient. For enterprise APIs with complex access requirements, claims and policies provide more flexibility.

🔗 3. Use OAuth 2.0 and OpenID Connect

Modern applications often need centralized identity, delegated access, and single sign-on.

OAuth 2.0 provides a framework for delegated authorization.

OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0 and is commonly used for authentication and SSO.

When an ASP.NET Core API integrates with an external identity provider, make sure the authentication flow, token validation, scopes, audiences, and authorization rules are configured according to the application's requirements.

Using a standard protocol is important, but correct implementation matters just as much.

🔑 4. Protect Access and Refresh Tokens

Token management is another important part of API security.

If an access token or refresh token is compromised, an attacker may be able to access protected resources.

Production applications should consider:

Appropriate access-token lifetimes
Secure token storage
Refresh-token rotation
Token revocation
Protection against token leakage
Avoiding sensitive token information in logs

Don't treat tokens as ordinary application data. Their lifecycle should be part of the overall security design.

🧩 5. Use Policy-Based Authorization for Complex Rules

As applications grow, authorization requirements usually become more complicated.

A simple role such as Admin or User may not be enough.

Access might depend on:

User role
Claims
Department
Resource ownership
Subscription level
Business operation

ASP.NET Core policy-based authorization can help developers express these requirements in a more structured way.

Instead of scattering authorization logic throughout controllers, policies can provide a consistent mechanism for enforcing application-specific rules.

🚫 6. Watch for Common Production Security Gaps

Security issues aren't always caused by sophisticated attacks.

Configuration mistakes can create serious vulnerabilities too.

Before deploying an ASP.NET Core API, review areas such as:

Exposed or unnecessary endpoints
Permissive CORS configuration
Hard-coded secrets
Sensitive information in logs
Incomplete JWT validation
Missing input validation
Weak production configuration

Development settings should not simply be copied into production.

Production environments should use appropriate secret management, restricted configuration, and carefully controlled access.

🧪 7. Make Security Testing Continuous

Security shouldn't be treated as a final step before deployment.

APIs change continuously. New endpoints are introduced, dependencies are updated, integrations are added, and authorization rules evolve.

That means security testing needs to be continuous as well.

Useful practices include:

Threat modeling
Security-focused code reviews
Penetration testing
Dependency vulnerability scanning
API monitoring
Authentication and authorization logging
Regular security reviews

The goal is to identify security weaknesses early and reduce the likelihood of vulnerabilities reaching production.

✅ A Simple Production API Security Checklist

Before deploying an ASP.NET Core Web API, ask:

Authentication

Are JWT tokens properly validated?
Are issuer, audience, signature, and expiration checked?

Authorization

Are sensitive endpoints protected?
Are roles, claims, or policies being applied correctly?

OAuth/OIDC

Is the identity provider configured correctly?
Are scopes and audiences appropriate?

Token Security

Are access and refresh tokens protected?
Are token lifetimes appropriate?
Is token rotation or revocation required?

Configuration

Are secrets stored securely?
Is CORS restricted?
Are unnecessary endpoints disabled?

Testing & Monitoring

Are authentication failures monitored?
Are authorization failures reviewed?
Is API security tested regularly?

Final Thoughts

A production-ready ASP.NET Core API needs more than authentication.

Strong ASP.NET Core API security comes from combining JWT token validation, OAuth 2.0, OpenID Connect, authorization policies, secure token management, protected configuration, and continuous security testing.

More importantly, these controls need to evolve as the application evolves.

The API you secure today may have completely different users, integrations, endpoints, and business rules a year from now.

Building security into the development process from the beginning makes it easier to maintain a secure and reliable API as the system grows.

📖 Read the complete guide:
https://convergesolution.com/blog/secure-aspnet-core-apis-production

💬 What API security practice has been the most important in your projects—JWT validation, authorization policies, OAuth/OIDC, or security testing?

How Can Enterprises Implement AI Beyond Chatbots?

ConvergeSol — Tue, 25 Aug 2026 11:54:57 +0000

For many organizations, a chatbot is the first step toward adopting AI.

But once the initial proof of concept is complete, a more important question emerges:

How can AI become part of real enterprise workflows?

The engineering challenge is not simply connecting an AI model to an application. Enterprise AI needs to work with existing data, business applications, workflows, and decision processes while meeting requirements for security, reliability, governance, and scalability.

What Are the Main Enterprise AI Use Cases?

Enterprise AI can be applied to several areas where traditional software and automation may not be enough.

1. AI-Powered Workflow Automation

Traditional automation works well when processes can be defined through fixed rules.

AI-driven workflow automation can support more dynamic processes involving unstructured information, changing conditions, decision points, and exceptions.

However, successful implementation starts with understanding the actual business workflow. Teams need to identify bottlenecks, define escalation paths, and determine where human review is still required.

2. Predictive Analytics

Enterprise systems generate large volumes of operational data. Predictive analytics can use that data to support forecasting, risk assessment, resource planning, and other business decisions.

From an engineering perspective, the model is only one part of the solution.

Data quality, model ownership, governance, monitoring, KPIs, and how predictions are incorporated into real decision workflows all matter.

A prediction that never reaches the right decision-maker has limited operational value.

3. AI Copilots

AI copilots are moving beyond simple question-and-answer interfaces.

An enterprise copilot can work with internal knowledge, documents, business data, and existing applications to help employees complete knowledge-intensive tasks.

This introduces additional engineering considerations:

What data can the copilot access?
How is user authorization enforced?
How is relevant context retrieved?
How are incorrect responses handled?
What happens when human judgment is required?

The deeper the integration, the more important security and governance become.

4. Intelligent Document Processing

Documents remain a major source of manual work across many enterprise environments.

AI can help extract, classify, summarize, and analyze information from documents. But real-world documents are rarely perfect.

Handwritten information, incomplete data, ambiguous cases, and unexpected formats can cause AI systems to produce unreliable results.

A production-ready solution therefore needs validation, fallback workflows, and human review rather than assuming every document can be processed automatically.

5. Enterprise System Integration

Enterprise AI rarely operates as a standalone application.

It often needs to connect with:

CRM systems
ERP platforms
SaaS applications
APIs
Databases
Legacy systems

This makes architecture an important part of AI implementation.

Authentication, authorization, data flows, observability, error handling, system dependencies, and reliability need to be considered before AI capabilities are introduced into production workflows.

Why Do Enterprise AI Projects Struggle to Scale?

A technically successful AI proof of concept does not automatically become a successful production system.

Common challenges include:

Data readiness: AI systems depend on reliable and relevant enterprise data.

Legacy integration: Existing applications may have complex dependencies that make AI integration difficult.

Governance: Enterprises need appropriate controls for compliance, auditability, explainability, and risk.

Skills: Teams may need new AI and data capabilities as well as business analysts who understand how AI fits into existing processes.

Change management: Employees need to understand how AI changes their workflows and where human judgment remains important.

ROI: Organizations need measurable KPIs to determine whether an AI initiative is actually improving business performance.

These challenges are why enterprise AI adoption is often as much an organizational problem as a technical one.

How Should Enterprises Start With AI?

A practical approach is to avoid trying to implement AI across the entire organization at once.

Start with a bounded business use case.

For example:

Identify a workflow with a measurable problem.
Map the existing process and its decision points.
Determine where AI can provide value.
Define KPIs before implementation.
Establish security and governance requirements.
Keep human oversight for appropriate cases.
Measure the results.
Scale the solution when it demonstrates value.

This approach allows teams to learn from a controlled implementation before expanding AI across additional workflows or business units.

The Engineering Goal Isn't Just to Add AI

Enterprise AI is not about adding an AI model to every application.

The real goal is to build systems where AI can work reliably with enterprise data, applications, workflows, and people.

That requires more than model selection.

It requires good architecture, clean data, secure integration, clear governance, measurable outcomes, and a practical understanding of how people actually work.

The most valuable enterprise AI solutions may not always be the most visible ones. They can be the systems quietly reducing manual work, improving decisions, processing information, and removing operational bottlenecks.

Final Thought

The next stage of enterprise AI is not simply better chatbots. It is AI becoming part of the workflows and systems that run the business.

The engineering challenge is making that integration reliable, secure, explainable, and scalable.

💬 What do you think is the biggest challenge when bringing enterprise AI into production: data quality, legacy integration, security, governance, or workflow design?

AI #EnterpriseAI #AIEngineering #AIAutomation #ArtificialIntelligence #SoftwareArchitecture #PredictiveAnalytics #DevOps

Building an AI-Powered ATS with .NET and Angular: Key Architecture Considerations

ConvergeSol — Wed, 19 Aug 2026 05:48:36 +0000

AI is changing how modern Applicant Tracking Systems (ATS) handle recruitment.

From resume analysis and candidate matching to recruitment automation, AI can reduce repetitive work and help recruiters process candidates more efficiently.

But building a reliable AI-powered ATS requires more than adding an AI model. The platform also needs to handle scalability, security, integrations, monitoring, and human oversight.

Where AI Fits in an ATS

A simplified AI-assisted recruitment workflow can look like:

The exact implementation will vary depending on the organization's recruitment process, but the key idea is simple: AI should support the workflow rather than replace it.

.NET for the Application Layer

.NET can provide the foundation for core ATS functionality, including:

Candidate and job management
REST APIs
Authentication and authorization
Recruitment workflows
Third-party integrations
Background processing
Reporting and analytics

Keeping AI capabilities separate from core business logic can also make the platform easier to maintain as AI models and services evolve.

Angular for the Recruiter Experience

Recruiters need a simple way to review candidate information and AI-generated recommendations.

Angular can support interfaces for:

Candidate profiles
Resume information
Candidate matching
Job management
Recruitment dashboards
AI-assisted recommendations

Rather than showing only an AI-generated score, the interface should provide useful context so recruiters can review and understand the recommendation.

AI-Powered Candidate Matching

AI can help analyze candidate profiles against job requirements and identify potentially relevant matches.

A practical approach is to combine AI capabilities with application-level rules and human review.

For example, AI might help identify relevant skills and experience, while business rules handle specific requirements and recruiters make the final assessment.

This creates a better balance between automation and human judgment.

Scalability Through Background Processing

Resume analysis can become resource-intensive when an organization processes hundreds or thousands of applications.

Instead of performing every operation directly during a user request, longer-running tasks can be handled through background processing.

This can help with:

Large document volumes
AI processing workloads
Retry handling
Application responsiveness
Horizontal scaling

The specific implementation will depend on the application's infrastructure and requirements.

Security and Data Protection

An ATS handles sensitive candidate information, so security needs to be considered throughout development.

Important areas include:

Authentication and authorization

Role-based access
Secure document storage
Data encryption
Audit logging
API security
AI service data handling

Organizations should also understand what candidate information is shared with external AI services and how that information is processed.

Monitoring AI and Application Performance

Traditional application monitoring isn't enough for an AI-powered ATS.

Teams should consider monitoring both:

Application performance

API response times
Errors
Database performance
Processing workloads

AI performance

Processing time
Service failures
Model versions
Usage
Recommendation outcomes

This helps developers identify whether a problem is coming from the application, infrastructure, or AI layer.

Keep Humans in the Loop

AI can assist recruiters, but important hiring decisions still require human judgment.

A recruiter should be able to review AI recommendations, understand the relevant information, and make the final decision.

This is particularly important when AI recommendations can have a significant impact on candidates.

Build for Continuous Improvement

AI-powered recruitment isn't a one-time implementation.

Models change. Recruitment workflows change. Business requirements change.

A well-designed platform should therefore be flexible enough to:

Introduce new AI capabilities
Change AI services
Update matching approaches
Add integrations
Improve workflows
Monitor AI outcomes

Final Thoughts

Building an AI-powered ATS isn't simply about connecting an AI model to recruitment software.

.NET can provide the backend foundation, Angular can support the recruiter experience, and AI can enhance capabilities such as resume analysis, candidate matching, automation, and recruitment analytics.

The real value comes from bringing these components together with scalability, security, observability, and human oversight.

If you'd like to explore the broader business and implementation considerations behind AI-powered recruitment, read the complete guide on ConvergeSol:

How AI Is Changing Recruitment and Applicant Tracking

What would you prioritize when building an AI-powered ATS: scalability, security, AI accuracy, or explainability?

Multi-Tenant SaaS with .NET and Angular: Architecture Practices That Matter

ConvergeSol — Tue, 11 Aug 2026 12:45:00 +0000

Building a multi-tenant SaaS application is more than adding a TenantID to your database.

The architecture needs to ensure that every request, query, user, and resource remains correctly associated with its tenant—while still delivering the performance and scalability expected from a modern SaaS product.

Here are some important engineering considerations:

🔐 1. Tenant Isolation

Use tenant-aware middleware, authorization policies, and service-level tenant context to ensure that API requests and database operations cannot cross tenant boundaries.

For a multi-tenant application, tenant isolation is critical because customer data and resources must remain securely separated. .NET applications can use tenant-aware middleware and context, while Angular can use route guards to help restrict access to tenant-specific resources.

The goal is simple:

One tenant should never be able to access another tenant's data.

🗄️** 2. Database Architecture**

Choosing the right database strategy is one of the most important decisions in a multi-tenant SaaS application.

Common approaches include:

Shared database + shared schema
Shared database + separate schema
Separate database per tenant

The right choice depends on tenant size, compliance requirements, performance expectations, scalability, operational complexity, and cost.

A shared schema can be cost-effective for many smaller tenants, while separate schemas or dedicated databases can provide stronger isolation for customers with greater security or compliance requirements.

🔑 3. Authentication & Authorization

Multi-tenant authentication needs to identify not only who the user is, but also which tenant the user belongs to.

Tenant-aware authentication can be combined with:

JWT claims
OAuth 2.0
OpenID Connect
Role-Based Access Control (RBAC)
Multi-factor authentication
Angular route guards

A typical flow can be represented as:

User
↓
Authentication
↓
Tenant Identification
↓
Authorization
↓
Tenant Resources

This approach helps ensure that users can access only the resources and functionality they are authorized to use.

🚀 4. Application Scalability

As the number of tenants increases, so do application workloads.

Stateless APIs, distributed caching such as Redis, containerization, microservices, and auto-scaling can help applications handle increasing tenant workloads.

Stateless Services

Stateless services make it easier to distribute requests across multiple application instances.

Distributed Caching

Caching can reduce repeated database operations and improve application response times.

Containerization and Microservices

Docker and Kubernetes can support consistent deployments and allow individual services to scale independently where appropriate.

Auto-Scaling

Cloud infrastructure can dynamically adjust resources based on workload demand.

The objective isn't simply to add more servers. The application architecture needs to be designed so that additional capacity can actually improve performance and reliability.

📊 5. Monitoring & Observability

As SaaS platforms grow, monitoring becomes increasingly important.

Centralized logging with tools such as Serilog and ELK, combined with Application Insights or Azure Monitor, can provide visibility into tenant usage, API performance, and application health.

Useful metrics can include:

Tenant usage
API response times
Application errors
Resource consumption
Database performance
SLA-related metrics

Tenant-level monitoring can also help identify performance issues that affect specific customers.

The key question isn't only:

“Is the application working?”

It is also:

“Which tenant is experiencing the problem, and why?”

🔄** 6. DevOps & Automation**

As the number of tenants grows, manual operations become increasingly difficult to manage.

Infrastructure as Code, CI/CD pipelines, automated testing, and repeatable deployments can help reduce deployment risk and accelerate development cycles.

Automation can be particularly useful for:

Tenant onboarding
Database or schema provisioning
Infrastructure provisioning
Application deployment
Testing
Configuration management

Repeatable processes make it easier to operate and scale the platform consistently.

Putting It All Together

A scalable SaaS architecture isn't defined by one technology or pattern.

It's the result of making the right decisions across:

*Tenant Isolation + Database Architecture + Security + Scalability + Observability + Automation
*
Each architectural decision can affect the others.

For example, the database strategy can influence tenant isolation, performance, cost, and scalability. Authentication affects security, while infrastructure architecture determines how efficiently workloads can scale.

That's why multi-tenancy should be treated as an architectural strategy, not simply a feature.

Final Thoughts

Building a multi-tenant SaaS application with .NET and Angular requires careful planning around tenant isolation, database architecture, authentication, scalability, monitoring, and DevOps.

The architecture that works for a small number of tenants may not necessarily work when the platform grows to hundreds or thousands of customers.

The goal is to build a platform that can scale securely, remain maintainable, and adapt as tenant requirements evolve.

📖 Explore the complete guide:

https://convergesolution.com/blog/best-practices-multi-tenant-saas-with-dot-net-and-angular

💬 Which tenancy model would you choose for an enterprise SaaS application: shared schema, separate schema, or database-per-tenant—and why?

What Makes a SaaS Product Scalable? Engineering Practices Behind High-Growth Applications

ConvergeSol — Wed, 05 Aug 2026 12:55:00 +0000

Launching a SaaS application is only the beginning.

Many startups successfully build and release an MVP, but scaling that product to support thousands of users, frequent feature releases, and increasing business requirements introduces a completely different set of engineering challenges.

A scalable SaaS product is not created by adding more servers or writing more code. It requires thoughtful architecture decisions, reliable infrastructure, automation, security practices, and continuous performance improvements.

The goal is to build a platform that can evolve as the business grows without requiring expensive redesigns.

1. Design Modular and Flexible Architectures

A scalable SaaS application starts with a strong software architecture.

Monolithic applications may work well during early stages, but as products grow, tightly coupled systems can make development slower and maintenance more difficult.

Modern SaaS applications often benefit from:

Modular architecture
Service-based design patterns
Clear separation of responsibilities
Reusable components
Well-defined APIs

A flexible architecture allows engineering teams to introduce new features faster without impacting existing functionality.

2. Build Cloud-Native SaaS Applications

Cloud infrastructure plays an important role in SaaS scalability.

Cloud-native development enables applications to automatically adapt to changing workloads while improving reliability and operational efficiency.

Key practices include:

Scalable cloud infrastructure
Containerization
Load balancing
Database optimization
Automated resource management

A properly designed cloud architecture helps SaaS products handle growth while maintaining performance.

3. Automate Delivery with CI/CD Pipelines

As SaaS products evolve, teams need to release updates quickly and safely.

Continuous Integration and Continuous Deployment (CI/CD) pipelines help engineering teams automate:

Code testing
Build processes
Deployment workflows
Quality checks

Automation reduces manual errors, accelerates delivery cycles, and allows developers to focus more on building valuable product improvements.

4. Integrate Security Throughout Development

Security should not be treated as a final step before deployment.

Scalable SaaS applications need security practices integrated throughout the Software Development Lifecycle (SDLC).

Important considerations include:

Secure authentication and authorization
Data encryption
API security
Vulnerability testing
Compliance requirements

Building security from the beginning helps protect user data and maintain customer trust.

5. Implement Monitoring and Observability

Application performance becomes harder to manage as systems become more complex.

Monitoring and observability provide insights into:

Application health
Performance bottlenecks
Infrastructure issues
User experience problems

Metrics, logs, and tracing help engineering teams identify and resolve issues before they impact customers.

6. Add AI Where It Creates Real Value

Artificial Intelligence is becoming an important capability in modern SaaS applications.

However, AI adoption should focus on solving real business and user problems.

Practical AI use cases include:

Automating repetitive workflows
Improving recommendations
Enhancing search experiences
Providing intelligent insights
Personalizing user interactions

The best SaaS products use AI as an enhancement rather than adding unnecessary complexity.

Scalability Starts With Engineering Decisions

A successful SaaS product is not only defined by its initial launch. Long-term success depends on how well the platform can adapt to new users, new requirements, and changing market conditions.

Engineering teams that prioritize scalable architecture, cloud infrastructure, automation, security, and continuous improvement can build SaaS platforms that grow without constant rebuilding.

Scalability should not be an afterthought. It should be part of the product roadmap from the first line of code.

Read the complete guide:
https://convergesolution.com/blog/how-saas-product-development-companies-drive-fast-smart-startup-growth

What engineering practice has made the biggest impact on your SaaS product scalability—cloud architecture, automation, security, or observability?

Engineering Better SaaS Products Starts with Better Architecture

ConvergeSol — Wed, 29 Jul 2026 12:30:00 +0000

One of the biggest misconceptions in SaaS development is that scalability can be solved simply by adding more servers.

In reality, most scalability issues originate from architectural decisions made much earlier in the development lifecycle.

Some of the most common engineering challenges include:

Designing scalable, cloud-native architecture
Building resilient API integrations with proper versioning and fault tolerance
Optimizing database performance using indexing, caching, and read replicas
Implementing CI/CD pipelines, Infrastructure as Code (IaC), and reliable deployment strategies
Reducing Time to First Value (TTFV) through better onboarding experiences

Addressing these challenges early helps reduce technical debt, improve reliability, simplify future development, and create SaaS applications that continue to perform as users and workloads grow.

I recently explored these topics in more detail, covering practical engineering approaches and architecture best practices for building modern SaaS applications.

📖 Read the full article:
https://convergesolution.com/blog/top-challenges-in-saas-product-development-and-solutions

I'm curious—what has been the biggest technical challenge in your SaaS projects? Scalability, API integrations, database performance, DevOps, or something else?

Building Secure Financial Software: What Developers Should Look for in a Technology Partner

ConvergeSol — Wed, 22 Jul 2026 17:33:06 +0000

The financial services industry has rapidly embraced digital transformation. Whether it's digital banking, payment gateways, lending platforms, or wealth management applications, modern financial software must deliver more than functionality—it must be secure, compliant, scalable, and resilient.

From a development perspective, building financial applications comes with unique challenges. Security vulnerabilities, regulatory compliance, system availability, and high transaction volumes all influence architectural decisions from day one.

Here are the key factors every development team should consider when evaluating a financial software development partner.

🔒 Security by Design

Security should never be an afterthought. Financial applications require encrypted data storage, secure authentication, role-based access control, regular vulnerability assessments, and adherence to secure coding standards.

Building security into every phase of development reduces risk and strengthens customer trust.

📋 Compliance Matters

Financial software often needs to comply with regulations such as KYC, AML, and PCI DSS. Developers should work with teams that understand these requirements and incorporate compliance into the development lifecycle instead of treating it as a final checklist.

☁️ Build for Scalability

Financial platforms experience fluctuating workloads and growing user bases. Cloud-native architectures, microservices, containerization, and API-first development provide the flexibility needed to scale without compromising performance.

🤖 AI is Becoming Essential

Artificial Intelligence is no longer limited to chatbots. Financial organizations are using AI for fraud detection, risk analysis, intelligent automation, document processing, and customer support.

Integrating AI responsibly can improve efficiency while enhancing the overall customer experience.

🔗 API Integration is Critical

Modern financial ecosystems rely on seamless integrations with payment gateways, banking systems, CRM platforms, identity verification providers, and third-party financial services.

Well-designed APIs improve interoperability, reduce complexity, and create a better developer experience.

Final Thoughts

Choosing a financial software development company isn't just a business decision—it's a technical one. A strong technology partner understands secure software engineering, compliance, cloud architecture, AI, and long-term scalability.

As financial technology continues to evolve, organizations that prioritize security, reliability, and modern architecture will be better positioned to innovate with confidence.

📖 If you're interested in learning more, check out our complete guide:
https://convergesolution.com/blog/financial-software-development-company

Building Compliance-Ready Financial Applications with Modern SaaS Architecture

ConvergeSol — Fri, 17 Jul 2026 19:38:17 +0000

As financial applications continue to evolve, compliance can no longer be treated as a feature that's added after development. It needs to be considered from the very beginning of the Software Development Lifecycle (SDLC).

Modern engineering teams are adopting a "compliance-by-design" approach, where security, governance, and regulatory requirements are integrated into application architecture rather than addressed during audits or deployment. This approach helps reduce technical debt while improving long-term maintainability and security.

When building modern financial applications, developers should focus on:

✔ Secure Authentication & Authorization

✔ Role-Based Access Control (RBAC)

✔ Audit Logging & Activity Tracking

✔ Data Encryption (At Rest & In Transit)

✔ Secure API Development

✔ Cloud-Native Architecture

✔ Compliance Automation

✔ Identity & Access Management (IAM)

✔ Continuous Security Monitoring

✔ DevSecOps and Secure CI/CD Pipelines

Cloud-native SaaS platforms also enable centralized compliance monitoring, automated reporting, and scalable infrastructure, making it easier for engineering teams to meet regulatory requirements without slowing development cycles.

Building compliance into the application architecture from day one helps organizations improve security, simplify regulatory reporting, reduce operational risk, and accelerate digital transformation.

At ConvergeSol, we help organizations develop secure, scalable SaaS and cloud solutions with security, compliance, and long-term maintainability built into every stage of the development lifecycle.

📖 Learn how modern SaaS solutions are helping financial organizations build secure, scalable, and compliance-ready applications.

https://convergesolution.com/blog/modern-saas-solutions-for-financial-compliance

FinancialCompliance #CloudComputing #SoftwareDevelopment #CyberSecurity #SaaS #DevOps

DEV Community: ConvergeSol

.NET 10 for Enterprise Applications: What Developers Should Evaluate Before Upgrading

Why a .NET 10 Upgrade Needs More Than Compatibility Testing

1. .NET 10 Runtime Performance

2. ASP.NET Core API Performance

3. Native AOT: Where Does It Actually Make Sense?

4. System.Text.Json and Serialization

5. EF Core: Check the Database Before Blaming .NET

6. OpenTelemetry and Distributed Diagnostics

7. .NET 10 in Containers and Cloud Environments

8. Security and Dependency Compatibility

9. Don't Turn a Framework Upgrade Into an Uncontrolled Rewrite

10. Plan the Rollout, Not Just the Code Changes

How Should Developers Evaluate .NET 10?

A Practical .NET 10 Migration Sequence

Step 1: Capture the baseline

Step 2: Audit dependencies

Step 3: Upgrade in a controlled environment

Step 4: Run regression tests

Step 5: Benchmark important workloads

Step 6: Validate production readiness

Step 7: Roll out gradually

Final Thoughts

What to Remember

Why Is My ASP.NET Core API Slow? 5 Things to Check First

1. Check How Many Database Queries One Request Executes

2. Search Your Codebase for .Result and .Wait()

3. Check Whether Your API Is Waiting for Another API

4. Look at the Size of Your Response

5. Don't Optimize Until You Know Where the Time Goes

What About the Other ASP.NET Core Performance Problems?

Final takeaway

EF Core N+1 Query Problem: How to Detect, Measure, and Fix It

What Is the N+1 Query Problem?

Does EF Core Automatically Cause N+1 Queries?

Why N+1 Queries Are Easy to Miss

What Does N+1 Look Like in Production?

How to Detect N+1 Queries in EF Core

1. Enable EF Core SQL Logging

2. Count Queries Per Request

3. Inspect Generated SQL

How to Fix the N+1 Problem in EF Core

1. Use Include() When You Need Related Entities

2. Prefer Select() When You Only Need Specific Fields

3. Use Explicit Loading When You Need More Control

Include() vs Select() vs Explicit Loading

Fewer Queries Isn't Always Better

A Practical Example

How to Prevent N+1 Problems Before Production

1. Review SQL behavior

2. Test with realistic datasets

3. Monitor query counts

4. Profile slow endpoints

5. Review data-loading strategy

6. Include database behavior in performance testing

A Simple EF Core N+1 Checklist

The Real Lesson

Read the Full Analysis

dotnet #efcore #csharp #performance

What Causes Thread Pool Starvation in ASP.NET Core APIs? A Practical Guide

What Is Thread Pool Starvation in ASP.NET Core?

The Most Common Cause: Blocking Async Code

What Else Can Cause Thread Pool Starvation?

1. Synchronous I/O

2. Blocking External APIs

3. Third-Party Libraries

4. Legacy Components

5. Long-Running Work on Request Threads

How Do You Know If Thread Pool Starvation Is Happening?

How to Diagnose Thread Pool Starvation

Use dotnet-counters

Use dotnet-trace

Use Profiling and Load Testing

How Do You Fix Thread Pool Starvation?

Don't Automatically Increase ThreadPool Threads

Should You Add More Servers?

How Can You Prevent Thread Pool Starvation?

Keep I/O asynchronous

Avoid synchronous waits

Review dependencies

2. Search Your Codebase for `.Result` and `.Wait()`

Use `dotnet-counters`

Use `dotnet-trace`