DEV Community: Chethan Ramaswamy

Entity Framework Core Performance Optimization: A Practical Guide for .NET Developers

Chethan Ramaswamy — Sat, 26 Sep 2026 13:55:27 +0000

Entity Framework Core Performance Optimization: A Practical Guide for .NET Developers

Entity Framework Core (EF Core) simplifies database development by allowing .NET developers to work with strongly typed C# objects and LINQ instead of writing SQL for every database operation.

However, the convenience of an ORM can sometimes hide expensive operations.

A LINQ query that looks simple in C# can result in:

Unnecessary database round trips
Large result sets
Excessive change tracking
N+1 queries
Expensive joins
Unnecessary columns being retrieved
Poor pagination performance
Excessive memory usage

The goal of performance optimization is not to avoid EF Core. It is to understand how EF Core translates and executes queries and then design those queries appropriately.

Good EF Core performance comes from minimizing unnecessary database work, data transfer, object materialization, and application-side processing.

This article walks through the most important EF Core performance considerations, from query execution and related-data loading to CRUD operations, DbContext, diagnostics, and practical optimization patterns.

Contents Snapshot

1. Understanding Entity Framework Core Performance
- How EF Core executes queries
- LINQ-to-SQL translation
- Where EF Core performance bottlenecks occur
2. Common EF Core Performance Problems
- Loading unnecessary data
- Excessive entity tracking
- N+1 queries
- Lazy loading
- Excessive Include()
- Premature query execution
3. Optimizing EF Core Queries
- Projection with Select()
- DTO-based queries
- AsNoTracking()
- Filtering and sorting
- Avoiding client-side processing
- Inspecting generated SQL
4. Managing Related Data
- Include() and ThenInclude()
- Eager loading
- Explicit loading
- Lazy loading
- AsSplitQuery() vs single queries
5. Pagination and Large Data Sets
- Skip() and Take()
- Keyset pagination
- Efficient querying of large tables
6. Insert, Update, and Delete Performance
- SaveChangesAsync()
- Batch operations
- ExecuteUpdateAsync()
- ExecuteDeleteAsync()
- Handling large data operations
7. DbContext Performance
- DbContext lifetime
- Change tracking
- Connection management
- Async database operations
- Context pooling
8. EF Core Performance Patterns and Anti-Patterns
- Common mistakes
- Recommended patterns
- When to use or avoid specific EF Core features
9. Measuring and Diagnosing EF Core Performance
- Logging
- Generated SQL
- Query timing
- Profiling
- Identifying slow queries
10. Practical EF Core Performance Checklist
- Query checklist
- Tracking checklist
- Loading checklist
- Write-operation checklist
- Production checklist
11. Key Takeaways

1. Understanding Entity Framework Core Performance

Before optimizing EF Core, it is important to understand what happens when a query is executed.

Consider this simple query:

var customers = await dbContext.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

At a high level, the execution flow looks like this:

C# LINQ Query
      |
      v
EF Core
      |
      v
Expression Translation
      |
      v
Generated SQL
      |
      v
Database
      |
      v
Result Set
      |
      v
EF Core Materialization
      |
      v
C# Objects

Several stages can contribute to the overall execution time.

How EF Core Executes Queries

When an IQueryable is built, EF Core does not immediately execute the query.

For example:

var query = dbContext.Customers
    .Where(x => x.IsActive)
    .OrderBy(x => x.Name);

At this point, the query has been composed but not necessarily executed.

Execution occurs when a terminal operation is called:

var customers = await query.ToListAsync();

Other examples include:

await query.FirstAsync();
await query.SingleAsync();
await query.CountAsync();
await query.AnyAsync();

This distinction is important because adding filters and projections before query execution allows EF Core to translate more of the work into SQL.

LINQ-to-SQL Translation

Consider:

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

Conceptually, EF Core translates the LINQ expression into SQL similar to:

SELECT
    Id,
    Name
FROM Customers
WHERE IsActive = 1;

The exact SQL depends on the EF Core version, provider, model configuration, and query.

This means developers should understand both sides:

LINQ
  |
  v
EF Core Translation
  |
  v
SQL
  |
  v
Database Execution

A query that looks efficient in C# is not necessarily efficient after translation.

Where EF Core Performance Bottlenecks Occur

Potential bottlenecks include:

Query translation
Database execution
Network transfer
Entity materialization
Change tracking
Application-side processing
Excessive database round trips
Large result sets

Therefore:

Do not optimize EF Core based only on how the C# code looks. Measure what the application and database actually do.

2. Common EF Core Performance Problems

Loading Unnecessary Data

One of the most common problems is retrieving more data than the application needs.

Consider:

var customers = await dbContext.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

Suppose the Customer entity contains:

Id
Name
Email
Phone
Address
ProfileImage
Preferences
Audit fields

If the API only needs:

Id
Name
Email

loading the entire entity is unnecessary.

This can increase:

Database I/O
Network traffic
Memory usage
Entity materialization
Serialization cost

Projection is usually a better approach for read-only API scenarios.

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

Only the required fields are requested by the query.

Excessive Entity Tracking

EF Core uses change tracking to detect modifications to entities.

This is useful when updating data:

var customer = await dbContext.Customers
    .FirstAsync(x => x.Id == customerId);

customer.Name = "John";

await dbContext.SaveChangesAsync();

EF Core tracks the customer and can determine what changed.

For read-only scenarios, tracking may not be necessary.

var customers = await dbContext.Customers
    .AsNoTracking()
    .Where(x => x.IsActive)
    .ToListAsync();

AsNoTracking() tells EF Core not to track the returned entities for changes.

This can reduce tracking overhead for appropriate read-heavy workloads.

However, it should not be added blindly everywhere.

Ask:

Does this query need to modify the returned entities?

If the answer is no, no-tracking may be appropriate.

The N+1 Query Problem

The N+1 query problem occurs when an application executes one query to retrieve a collection and then performs additional queries for each item.

Consider:

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

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

Depending on the relationship-loading configuration, this can result in:

1 query  -> Orders

N queries -> Customers

If there are 5,000 orders, the application could potentially perform thousands of additional database operations.

Even when individual queries are fast, the combined overhead can become significant.

Better Approach

Projection can retrieve the required related data as part of the query:

var orders = await dbContext.Orders
    .Select(x => new OrderDto
    {
        Id = x.Id,
        Amount = x.Amount,
        CustomerName = x.Customer.Name
    })
    .ToListAsync();

The important principle is:

Minimize unnecessary database round trips.

Lazy Loading

Lazy loading retrieves related data when a navigation property is accessed.

For example:

var order = await dbContext.Orders
    .FirstAsync(x => x.Id == orderId);

var customerName = order.Customer.Name;

With lazy loading enabled, accessing Customer can trigger another database query.

This can be convenient, but it can also hide database operations inside ordinary property access.

For example:

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

What looks like a simple loop may result in many database calls.

Practical Consideration

Lazy loading can be useful in some scenarios, but it should be used carefully in performance-sensitive applications.

For API workloads, explicit query shaping and projection often make database access easier to understand and control.

Excessive `Include()`

Include() is useful when related entities are genuinely required.

For example:

var orders = await dbContext.Orders
    .Include(x => x.Customer)
    .ToListAsync();

However, adding many relationships to a query can result in complex SQL and large result sets.

For example:

var orders = await dbContext.Orders
    .Include(x => x.Customer)
    .Include(x => x.Items)
    .Include(x => x.Payments)
    .Include(x => x.Shipments)
    .ToListAsync();

This may result in a large query and repeated data across joined rows.

If the API only needs selected fields, projection is often clearer:

var orders = await dbContext.Orders
    .Select(x => new OrderSummaryDto
    {
        Id = x.Id,
        Amount = x.Amount,
        CustomerName = x.Customer.Name,
        ItemCount = x.Items.Count()
    })
    .ToListAsync();

Use Include() when you actually need entity graphs.

Use projection when you need a specific result shape.

Premature Query Execution

Consider:

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

var activeCustomers = customers
    .Where(x => x.IsActive)
    .ToList();

The entire customer table is loaded into memory before filtering.

A better approach is:

var activeCustomers = await dbContext.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

Now the filtering happens in the database.

A useful rule is:

Keep the query as IQueryable while composing database operations, and execute it only when you actually need the results.

3. Optimizing EF Core Queries

Projection with `Select()`

Projection is one of the most useful EF Core optimization techniques.

Instead of retrieving complete entities:

var products = await dbContext.Products
    .Where(x => x.IsActive)
    .ToListAsync();

project only the required fields:

var products = await dbContext.Products
    .Where(x => x.IsActive)
    .Select(x => new ProductDto
    {
        Id = x.Id,
        Name = x.Name,
        Price = x.Price
    })
    .ToListAsync();

This reduces the amount of data transferred from the database.

It can also reduce application memory consumption and object materialization.

Why Projection Matters

Consider an entity with 30 columns.

If an API requires only 4 columns:

Entity
  |
  +-- 30 columns
  |
  v
Database
  |
  v
Application

Projection changes this to:

Entity
  |
  +-- 4 required columns
  |
  v
Database
  |
  v
Application

This becomes increasingly important as data volume grows.

DTO-Based Queries

Using DTOs also creates a clear boundary between persistence models and API contracts.

Example:

public sealed class CustomerDto
{
    public int Id { get; init; }
    public string Name { get; init; } = string.Empty;
    public string Email { get; init; } = string.Empty;
}

Query:

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

This approach has several advantages:

Explicit data requirements
Smaller result sets
Reduced coupling
Clear API contracts
Less unnecessary entity materialization

`AsNoTracking()`

For read-only queries:

var products = await dbContext.Products
    .AsNoTracking()
    .Where(x => x.IsActive)
    .ToListAsync();

Use tracking when you need to modify the entity:

var product = await dbContext.Products
    .FirstAsync(x => x.Id == productId);

product.Price = 100;

await dbContext.SaveChangesAsync();

Use no-tracking when the result is simply being read:

GET API
  |
  v
Query database
  |
  v
Return response

The choice should be based on the query's behavior, not applied as a blanket rule.

Filtering and Sorting

Filtering should generally happen in the database rather than after materialization.

Avoid:

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

var result = customers
    .Where(x => x.Country == "India")
    .OrderBy(x => x.Name)
    .ToList();

Prefer:

var result = await dbContext.Customers
    .Where(x => x.Country == "India")
    .OrderBy(x => x.Name)
    .ToListAsync();

This allows the database to perform the filtering and sorting.

For large datasets, database-side operations are generally preferable to loading unnecessary rows into application memory.

Avoiding Client-Side Processing

A common performance problem occurs when developers unintentionally move processing from the database into application memory.

For example:

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

var result = customers
    .Where(x => x.Name.StartsWith("A"))
    .ToList();

Instead:

var result = await dbContext.Customers
    .Where(x => x.Name.StartsWith("A"))
    .ToListAsync();

The database can process the filtering before returning the result.

The general pattern is:

Avoid:

Database
   |
   v
Large result set
   |
   v
Application filtering


Prefer:

Database
   |
   +-- Filter
   +-- Sort
   +-- Project
   |
   v
Small result set
   |
   v
Application

Inspecting Generated SQL

Do not assume that a LINQ query generates the SQL you expect.

EF Core provides ToQueryString() for inspecting the SQL representation of a query.

var query = dbContext.Customers
    .Where(x => x.IsActive)
    .Select(x => new CustomerDto
    {
        Id = x.Id,
        Name = x.Name
    });

var sql = query.ToQueryString();

Console.WriteLine(sql);

This is useful when diagnosing:

Unexpected joins
Missing filters
Excessive columns
Complex queries
Unexpected query shapes

For production diagnosis, application logging and database monitoring should also be used rather than relying only on ToQueryString().

4. Managing Related Data

Relationships are one of the areas where EF Core can generate unexpected database work.

Consider:

Order
 |
 +-- Customer
 |
 +-- OrderItems
 |
 +-- Payments

The correct loading strategy depends on what the application actually needs.

`Include()` and `ThenInclude()`

Include() loads related data.

var orders = await dbContext.Orders
    .Include(x => x.Customer)
    .ToListAsync();

For nested relationships:

var orders = await dbContext.Orders
    .Include(x => x.Customer)
        .ThenInclude(x => x.Address)
    .ToListAsync();

Use this when the related entities are actually required.

Avoid adding Include() simply because the relationship exists.

Eager Loading

Eager loading retrieves related data as part of the query.

Example:

var orders = await dbContext.Orders
    .Include(x => x.Customer)
    .ToListAsync();

Advantages:

Explicit
Easy to understand
Avoids some hidden database calls

Potential downside:

Large entity graphs can produce complex queries and large result sets

For read-only APIs, projection can often provide a more precise result shape.

Explicit Loading

Explicit loading allows the application to deliberately load related data.

For example:

var order = await dbContext.Orders
    .FirstAsync(x => x.Id == orderId);

await dbContext.Entry(order)
    .Reference(x => x.Customer)
    .LoadAsync();

This gives the application explicit control over when related data is loaded.

It can be useful when the related data is conditionally required.

However, repeated explicit loading inside loops can still create N+1 behavior.

Lazy Loading

Lazy loading loads related entities when they are accessed.

Although convenient, it can make database activity less visible in application code.

For example:

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

The loop does not visibly contain a database query, but accessing Customer can trigger one when lazy loading is enabled.

For performance-sensitive applications, make database access explicit whenever practical.

`AsSplitQuery()` vs Single Queries

Consider a query with multiple collection relationships:

var orders = await dbContext.Orders
    .Include(x => x.Items)
    .Include(x => x.Payments)
    .ToListAsync();

A single-query approach can produce large joins.

EF Core supports split queries:

var orders = await dbContext.Orders
    .Include(x => x.Items)
    .Include(x => x.Payments)
    .AsSplitQuery()
    .ToListAsync();

Conceptually:

Single Query

Orders
  |
  +-- Items
  |
  +-- Payments

versus:

Split Query

Query 1 -> Orders
Query 2 -> Items
Query 3 -> Payments

Split queries can reduce some join-related duplication, but they also mean multiple database round trips.

Therefore:

Choose between single and split queries based on the actual query shape and measured performance.

5. Pagination and Large Data Sets

Returning thousands or millions of rows from an API is rarely appropriate.

Pagination limits the amount of data processed and returned.

`Skip()` and `Take()`

A common approach is:

var customers = await dbContext.Customers
    .OrderBy(x => x.Id)
    .Skip(page * pageSize)
    .Take(pageSize)
    .ToListAsync();

For example:

Page size = 50
Page      = 2

The query retrieves the next 50 records after the previous 100 records.

This approach is simple and useful for many applications.

However, very large offsets can become increasingly expensive because the database may need to process rows that are skipped.

Keyset Pagination

For large datasets, keyset pagination can be an alternative.

Suppose the last item from the previous page has:

Id = 50000

The next query can be:

var customers = await dbContext.Customers
    .Where(x => x.Id > lastCustomerId)
    .OrderBy(x => x.Id)
    .Take(50)
    .ToListAsync();

Conceptually:

Previous page
     |
     v
Last Id = 50000
     |
     v
WHERE Id > 50000
     |
     v
Take 50

This approach is especially useful for large, sequential datasets.

When to Consider Keyset Pagination

Keyset pagination is useful when:

The dataset is large
Users navigate sequentially
A stable ordering key exists
Very deep pages are expected

Offset pagination can still be appropriate when users need direct access to arbitrary pages.

6. Insert, Update, and Delete Performance

EF Core performance is not limited to queries.

Write operations can also become expensive when large numbers of entities are involved.

`SaveChangesAsync()`

Avoid calling SaveChangesAsync() inside every iteration.

Inefficient

foreach (var customer in customers)
{
    customer.IsActive = false;

    await dbContext.SaveChangesAsync();
}

This can create many database round trips.

Better

foreach (var customer in customers)
{
    customer.IsActive = false;
}

await dbContext.SaveChangesAsync();

This reduces the number of explicit save operations.

However, for very large datasets, loading and tracking every entity can still be expensive.

That is where set-based operations become useful.

Batch Operations

When processing large numbers of entities, consider the size of the batch.

For example:

1,000,000 records
      |
      v
Process in manageable batches
      |
      +-- Batch 1
      +-- Batch 2
      +-- Batch 3
      +-- ...

Batching can help control:

Memory consumption
Transaction size
Change tracker size
Execution time
Database pressure

The appropriate batch size depends on the workload and should be validated through testing.

`ExecuteUpdateAsync()`

For operations that can be expressed as a set-based update, ExecuteUpdateAsync() can avoid loading entities into memory.

For example:

await dbContext.Customers
    .Where(x => !x.IsActive)
    .ExecuteUpdateAsync(setters =>
        setters.SetProperty(
            x => x.IsArchived,
            true));

Conceptually, the operation becomes:

Application
     |
     v
UPDATE statement
     |
     v
Database

rather than:

Database
     |
     v
Load entities
     |
     v
Application
     |
     v
Track entities
     |
     v
Modify entities
     |
     v
Save changes

For large set-based updates, this can substantially reduce application-side work.

`ExecuteDeleteAsync()`

Similarly, records can be deleted directly without loading every entity.

await dbContext.Customers
    .Where(x => x.IsInactive)
    .ExecuteDeleteAsync();

This is useful when the business operation is simply:

Delete all records matching condition

rather than:

Load each entity
  |
  v
Run application logic
  |
  v
Delete entities

Before using set-based operations, consider whether entity-level business rules, events, auditing, or other application logic need to run.

Handling Large Data Operations

For very large workloads, consider:

Batching
Set-based operations
Appropriate transaction boundaries
Memory consumption
Database throughput
Error recovery
Idempotency
Retry behavior

The right strategy depends on whether the operation is:

User-driven
Scheduled
Background processing
Bulk migration
Data correction
Real-time processing

7. DbContext Performance

DbContext is central to EF Core applications.

Understanding its lifecycle and behavior is important for performance and correctness.

DbContext Lifetime

In ASP.NET Core applications, a common configuration is:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

This typically creates a scoped DbContext.

The conceptual request lifecycle is:

HTTP Request
     |
     v
DbContext
     |
     +-- Query
     +-- Query
     +-- Update
     |
     v
SaveChanges
     |
     v
Request Complete
     |
     v
DbContext Disposed

Avoid using a single DbContext instance across unrelated concurrent requests.

DbContext is not designed for concurrent operations on the same instance.

Change Tracking

The change tracker maintains information about entities being tracked.

For example:

var customer = await dbContext.Customers
    .FirstAsync(x => x.Id == customerId);

customer.Name = "Updated Name";

await dbContext.SaveChangesAsync();

EF Core can determine that Name changed.

However, tracking thousands of entities can increase memory and processing overhead.

For read-heavy workloads, no-tracking queries can reduce this overhead:

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

The right approach depends on the workload.

Connection Management

EF Core relies on the underlying database provider for connection management and pooling.

A simplified flow is:

Application
     |
     v
EF Core
     |
     v
Connection Pool
     |
     v
Database

Potential problems include:

Connection pool exhaustion
Long-running database operations
Excessive concurrency
Connections held longer than necessary

If an application experiences database timeouts, investigate whether the problem is:

Connection acquisition
        |
        or
        v
Query execution
        |
        or
        v
Database resource contention

Do not assume all database timeout problems have the same root cause.

Async Database Operations

Use asynchronous database APIs in ASP.NET Core applications:

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

Similarly:

await dbContext.SaveChangesAsync();

Asynchronous I/O allows the application to avoid blocking request threads while waiting for database operations.

The benefit is particularly relevant for applications handling many concurrent requests.

Context Pooling

For some workloads, EF Core supports context pooling.

For example:

builder.Services.AddDbContextPool<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

Pooling allows EF Core to reuse DbContext instances rather than creating a new instance each time.

However, pooled contexts require careful consideration of state that might be stored on the context or related services.

Context pooling is an optimization that should be measured rather than enabled simply because it exists.

8. EF Core Performance Patterns and Anti-Patterns

Understanding what not to do is just as important as understanding the recommended patterns.

Common Mistakes

Loading Everything

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

followed by application-side filtering.

Prefer database-side filtering:

var customers = await dbContext.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

Returning Entities Directly From APIs

Returning EF entities directly can expose persistence models to API consumers.

Prefer DTOs:

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

Calling `SaveChangesAsync()` Repeatedly

Avoid:

foreach (var item in items)
{
    dbContext.Update(item);
    await dbContext.SaveChangesAsync();
}

Prefer a suitable batching or set-based strategy.

Using Lazy Loading Without Understanding Its Cost

Lazy loading can make database calls invisible in application code.

Be particularly careful with loops and large collections.

Adding `Include()` Everywhere

Include() is not a replacement for query design.

Ask:

Do I really need the complete related entity?

If the answer is no, projection may be more appropriate.

Recommended Patterns

For read-heavy API endpoints:

var result = await dbContext.Customers
    .AsNoTracking()
    .Where(x => x.IsActive)
    .Select(x => new CustomerDto
    {
        Id = x.Id,
        Name = x.Name,
        Email = x.Email
    })
    .ToListAsync();

This combines several useful principles:

Database-side filtering
Projection
Reduced tracking
Explicit result shape

For large updates:

await dbContext.Customers
    .Where(x => !x.IsActive)
    .ExecuteUpdateAsync(setters =>
        setters.SetProperty(
            x => x.IsArchived,
            true));

For large result sets:

var result = await dbContext.Customers
    .Where(x => x.Id > lastCustomerId)
    .OrderBy(x => x.Id)
    .Take(50)
    .ToListAsync();

When to Use or Avoid Specific EF Core Features

Feature	Useful When	Be Careful When
`AsNoTracking()`	Read-only queries	Entities need to be updated through the context
`Include()`	Related entities are required	Many large collection relationships are included
`AsSplitQuery()`	Large relationship graphs	Additional database round trips matter
Lazy loading	Convenience is important	Query count must be predictable
Projection	APIs need specific fields	Complex result shapes require careful testing
`ExecuteUpdateAsync()`	Large set-based updates	Entity-level business logic must execute
`ExecuteDeleteAsync()`	Large set-based deletes	Per-entity processing is required
Context pooling	High-throughput workloads	Context-specific mutable state is used

The important point is that there is no single EF Core feature that makes every application faster.

9. Measuring and Diagnosing EF Core Performance

Performance optimization should start with measurement.

Do not optimize based solely on assumptions.

Logging

EF Core can provide database-related logging that helps identify queries and execution behavior.

For example:

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options
        .UseSqlServer(connectionString)
        .EnableDetailedErrors();
});

Be careful when enabling detailed logging in production because sensitive information can potentially appear in logs depending on the configuration.

Generated SQL

For a specific query:

var query = dbContext.Customers
    .Where(x => x.IsActive)
    .Select(x => new CustomerDto
    {
        Id = x.Id,
        Name = x.Name
    });

var sql = query.ToQueryString();

Inspecting generated SQL can reveal unexpected behavior.

For example:

Expected:

SELECT Id, Name
FROM Customers
WHERE IsActive = 1


Unexpected:

SELECT many columns
FROM Customers
JOIN ...
JOIN ...
JOIN ...

This can lead to further investigation.

Query Timing

Measure actual execution time rather than assuming a query is slow.

For example:

var stopwatch = Stopwatch.StartNew();

var customers = await dbContext.Customers
    .AsNoTracking()
    .Where(x => x.IsActive)
    .ToListAsync();

stopwatch.Stop();

Console.WriteLine(
    $"Query completed in {stopwatch.ElapsedMilliseconds} ms");

For production applications, use structured logging and telemetry instead of ad-hoc console output.

Profiling

For a production-grade application, consider observing:

HTTP Request
      |
      v
Application Code
      |
      v
EF Core
      |
      v
Database Dependency

Useful measurements include:

API latency
Database query duration
Number of database calls
Result-set size
Error rate
Request throughput
Memory usage
Connection utilization

The objective is to identify where the time is actually being spent.

Identifying Slow Queries

A useful troubleshooting process is:

Slow API
   |
   v
Measure API latency
   |
   v
Identify database dependency
   |
   v
Identify slow query
   |
   v
Inspect generated SQL
   |
   v
Analyze execution
   |
   v
Optimize EF Core query
   |
   v
Measure again

If the database query itself is efficient but the API is still slow, investigate other parts of the request pipeline.

10. Practical EF Core Performance Checklist

Query Checklist

[ ] Are only required columns being selected?
[ ] Is filtering performed in the database?
[ ] Is projection used where appropriate?
[ ] Are queries executed only when needed?
[ ] Are N+1 queries eliminated?
[ ] Is generated SQL understood?
[ ] Are large result sets paginated?

Tracking Checklist

[ ] Does the query actually require change tracking?
[ ] Is AsNoTracking() used for appropriate read-only queries?
[ ] Is the number of tracked entities reasonable?
[ ] Are long-lived DbContext instances avoided?

Loading Checklist

[ ] Is Include() used only when required?
[ ] Are large relationship graphs avoided?
[ ] Is lazy loading being used intentionally?
[ ] Could projection replace entity loading?
[ ] Should AsSplitQuery() be considered for the query shape?

Write-Operation Checklist

[ ] Is SaveChangesAsync() being called unnecessarily inside loops?
[ ] Can the operation be performed in batches?
[ ] Can ExecuteUpdateAsync() be used?
[ ] Can ExecuteDeleteAsync() be used?
[ ] Are transaction boundaries appropriate?
[ ] Is application-level business logic required for each entity?

Production Checklist

[ ] Is query performance measured?
[ ] Are database calls observable?
[ ] Are slow queries identifiable?
[ ] Are application logs configured appropriately?
[ ] Are connection issues monitored?
[ ] Are realistic datasets used for performance testing?
[ ] Are performance changes validated before and after deployment?

11. Key Takeaways

Entity Framework Core provides powerful abstractions for working with relational databases, but those abstractions do not remove the need to understand database access patterns.

The most important principles are:

Understand how LINQ becomes SQL.
Retrieve only the data the application actually needs.
Use projection for precise read models.
Use AsNoTracking() for appropriate read-only workloads.
Avoid N+1 queries.
Use Include() carefully.
Understand the trade-offs of lazy loading.
Keep filtering and sorting in the database where appropriate.
Avoid premature query execution.
Use appropriate pagination for large datasets.
Avoid unnecessary SaveChangesAsync() calls.
Consider set-based operations for large updates and deletes.
Manage DbContext lifetime correctly.
Use asynchronous database operations.
Measure performance instead of relying on assumptions.

A useful mental model is:

                EF Core Performance
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
      Query          Tracking       Loading
        |              |              |
        v              v              v
   Projection      NoTracking       Include
   Filtering       Context         Lazy Load
   Pagination      Lifetime        Split Query
        |              |              |
        +--------------+--------------+
                       |
                       v
                 Database Work
                       |
                       v
                 Measure & Tune

Conclusion

EF Core performance optimization is not about applying every available optimization.

It is about understanding the workload and choosing the simplest approach that avoids unnecessary work.

When an EF Core query becomes slow, start with a few fundamental questions:

What data do I actually need?

How many database calls am I making?

Is EF Core tracking entities unnecessarily?

What SQL is actually being generated?

Can the operation be performed efficiently at the database level?

Once these questions become part of the development and code-review process, many EF Core performance issues can be identified before they become production problems.

The best optimization is often not a complicated EF Core technique. It is simply doing less unnecessary work.

dotnet #csharp #efcore #entityframework #aspnetcore #performance #softwarearchitecture #programming

SOLID Principles in C#: A Practical Guide with Real-World Examples and Design Patterns

Chethan Ramaswamy — Sat, 26 Sep 2026 09:30:35 +0000

📑 Contents

What Does SOLID Mean?
SOLID Is Not the Same as Design Patterns
1. Single Responsibility Principle — SRP
- The Simple Explanation
- A Common Problem
- Refactoring the Design
- Design Patterns and Techniques That Can Support SRP
- Common SRP Mistake
2. Open/Closed Principle — OCP
- The Simple Explanation
- A Common Problem
- Applying the Strategy Pattern
- Strategy Pattern and OCP
- Factory Pattern and OCP
3. Liskov Substitution Principle — LSP
- The Simple Explanation
- The Classic Example
- A Better Design
- LSP in Enterprise Applications
- LSP and Composition
- Common LSP Warning Signs
4. Interface Segregation Principle — ISP
- The Simple Explanation
- A Common Problem
- Split the Interface
- ISP in an Enterprise Service
- Patterns That Can Support ISP
- Common ISP Mistake
5. Dependency Inversion Principle — DIP
- The Simple Explanation
- A Common Problem
- Introduce an Abstraction
Dependency Inversion vs Dependency Injection
- Dependency Inversion Principle
- Dependency Injection
SOLID and Design Patterns — The Practical Connection
SOLID Does Not Mean "More Interfaces"
SOLID Does Not Mean "Create More Classes"
SOLID Does Not Mean "Remove Every if/else"
SOLID Does Not Mean "Use Every Design Pattern"
A Real-World Example: Notification System
- Introduce an Abstraction
How to Identify SOLID Issues During Code Review
- SRP Questions
- OCP Questions
- LSP Questions
- ISP Questions
- DIP Questions
A Practical SOLID Refactoring Workflow
- Step 1 — Identify What Changes
- Step 2 — Identify the Coupling
- Step 3 — Identify the Responsibility
- Step 4 — Introduce an Abstraction When It Adds Value
- Step 5 — Choose a Pattern If It Fits
- Step 6 — Keep the Design Simple
SOLID in a Typical .NET Application
SOLID vs Design Patterns
When Should You Not Apply SOLID Aggressively?
A Simple SOLID Mental Model
SOLID Design Pattern Quick Reference
Common SOLID Misconceptions
- Misconception 1: "SOLID means more interfaces."
- Misconception 2: "SOLID means every class should have one method."
- Misconception 3: "SOLID means no if/else statements."
- Misconception 4: "DIP and Dependency Injection are the same."
- Misconception 5: "Every SOLID problem requires a design pattern."
- Misconception 6: "Inheritance is always better than composition."
- Misconception 7: "Following SOLID guarantees good architecture."
The Most Important Lesson
Final Takeaways
Practical SOLID Checklist

SOLID is one of the most discussed topics in object-oriented programming.

Most developers have heard of the five principles:

S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

But knowing what the letters stand for is very different from knowing how to apply them.

A developer may remember that SRP means "a class should have one reason to change" but still struggle to identify an SRP violation in a real application.

Similarly, developers often learn design patterns such as Strategy, Factory, Adapter, Decorator, and Repository, but may not understand how these patterns relate to SOLID.

This article takes a practical approach.

Instead of simply memorizing definitions, we will look at:

The problem each SOLID principle tries to solve
How that problem appears in real applications
How to recognize the problem
How to refactor the design
Which design patterns or techniques can help
Common misconceptions
How the principles work together

The examples use C# and .NET, but the underlying concepts apply to object-oriented software in general.

What Does SOLID Mean?

SOLID is an acronym for five object-oriented design principles:

Principle	Meaning	Practical Question
S	Single Responsibility Principle	Does this class have more than one reason to change?
O	Open/Closed Principle	Can I add new behavior without repeatedly modifying stable code?
L	Liskov Substitution Principle	Can a derived type safely replace its base type?
I	Interface Segregation Principle	Are implementations forced to depend on methods they do not need?
D	Dependency Inversion Principle	Does my business logic depend directly on implementation details?

A simple way to remember them:

S → Keep responsibilities focused

O → Make changing behavior extensible

L → Make inheritance behaviorally trustworthy

I → Keep interfaces focused

D → Depend on abstractions

SOLID should not be treated as five rules that must be applied mechanically.

The goal is not to create more interfaces, classes, or abstractions.

The goal is to create software that is easier to:

Understand
Change
Test
Extend
Maintain

SOLID Is Not the Same as Design Patterns

This distinction is important.

SOLID principles are design principles.

Design patterns are reusable approaches to recurring software design problems.

For example:

Design Problem
      ↓
Identify the underlying design principle
      ↓
Consider possible design approaches
      ↓
Choose a suitable pattern or technique
      ↓
Keep the solution as simple as possible

A design pattern does not automatically make code SOLID.

Likewise, SOLID does not require the use of design patterns.

Use SOLID to guide your design decisions. Use a design pattern when it provides a practical solution to the problem you actually have.

Also, not every pattern discussed in this article is a Gang of Four (GoF) design pattern. For example, Repository and Dependency Injection are commonly used design or architectural techniques in modern enterprise applications, but they are not GoF patterns.

1. Single Responsibility Principle — SRP

The Simple Explanation

The Single Responsibility Principle states:

A class should have one reason to change.

This is often misunderstood as:

"A class should contain only one method."

That is not what SRP means.

A class can contain multiple methods and still have a single responsibility.

The better question is:

Do the responsibilities in this class change for different reasons?

A Common Problem

Imagine an e-commerce application with this class:

public class OrderService
{
    public void CreateOrder(Order order)
    {
        // Save order to database
    }

    public void ProcessPayment(Order order)
    {
        // Process payment
    }

    public void SendConfirmationEmail(Order order)
    {
        // Send email
    }

    public byte[] GenerateInvoice(Order order)
    {
        // Generate PDF invoice
        return [];
    }
}

At first glance, this may look convenient.

Everything related to an order is in one place.

But this class actually contains several responsibilities:

OrderService
    |
    +-- Order persistence
    |
    +-- Payment processing
    |
    +-- Email communication
    |
    +-- Invoice generation

Now consider the following changes:

The database technology changes.
The payment provider changes.
The email provider changes.
The invoice format changes.

These changes are driven by different concerns.

If all of them require modifying OrderService, the class has multiple reasons to change.

That is a warning sign for SRP.

Refactoring the Design

We can separate the responsibilities:

public interface IOrderRepository
{
    Task SaveAsync(Order order);
}

public interface IPaymentService
{
    Task ProcessAsync(Order order);
}

public interface INotificationService
{
    Task SendOrderConfirmationAsync(Order order);
}

public interface IInvoiceService
{
    Task<byte[]> GenerateAsync(Order order);
}

The application service can then coordinate the workflow:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly IPaymentService _paymentService;
    private readonly INotificationService _notificationService;

    public OrderService(
        IOrderRepository orderRepository,
        IPaymentService paymentService,
        INotificationService notificationService)
    {
        _orderRepository = orderRepository;
        _paymentService = paymentService;
        _notificationService = notificationService;
    }

    public async Task CreateOrderAsync(Order order)
    {
        await _orderRepository.SaveAsync(order);
        await _paymentService.ProcessAsync(order);
        await _notificationService.SendOrderConfirmationAsync(order);
    }
}

Now the responsibilities are clearer:

OrderService
     |
     +── IOrderRepository
     +── IPaymentService
     +── INotificationService

OrderService coordinates the workflow instead of implementing every technical detail itself.

Design Patterns and Techniques That Can Support SRP

SRP does not require a particular design pattern.

However, several patterns or techniques can help separate responsibilities:

Pattern / Technique	How it can help
Facade	Provides a simplified interface over multiple components
Strategy	Separates interchangeable business algorithms
Command	Encapsulates an operation
Decorator	Separates cross-cutting behavior
Mediator	Separates request handling responsibilities
Repository	Separates persistence concerns from business logic

These are not "SRP patterns."

They are approaches that can help create a design with better separation of responsibilities.

Common SRP Mistake

A common misunderstanding is:

"Every class must do only one thing."

That can lead to unnecessary fragmentation.

For example, creating a separate class for every small method may produce a system with too many abstractions and dependencies.

Instead, ask:

Do these responsibilities change independently?

If they do, separating them may make the design easier to maintain.

If they do not, keeping them together may be perfectly reasonable.

2. Open/Closed Principle — OCP

The Simple Explanation

The Open/Closed Principle states:

Software entities should be open for extension but closed for modification.

A practical interpretation is:

Design areas of expected variation so that new behavior can be added without repeatedly changing stable, already-tested code.

This does not mean existing code can never be modified.

Requirements change, bugs need fixing, and designs evolve.

The principle is about avoiding unnecessary modification of stable code every time a new variation is introduced.

A Common Problem

Consider payment processing:

public class PaymentService
{
    public void Process(string paymentType, decimal amount)
    {
        if (paymentType == "CreditCard")
        {
            // Credit card payment
        }
        else if (paymentType == "PayPal")
        {
            // PayPal payment
        }
        else if (paymentType == "UPI")
        {
            // UPI payment
        }
    }
}

Today we support:

Credit Card
PayPal
UPI

Tomorrow we might add:

Bank Transfer
Apple Pay
Google Pay

If the conditional keeps growing, every new payment method requires modifying the same class.

The problem is not that if or switch statements are inherently bad.

The problem is that independently changing behavior is becoming tightly coupled to one piece of code.

Applying the Strategy Pattern

We can introduce an abstraction:

public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

Then create separate implementations:

public class CreditCardPayment : IPaymentStrategy
{
    public void Pay(decimal amount)
    {
        // Process credit card payment
    }
}

public class UpiPayment : IPaymentStrategy
{
    public void Pay(decimal amount)
    {
        // Process UPI payment
    }
}

The service depends on the abstraction:

public class PaymentService
{
    private readonly IPaymentStrategy _paymentStrategy;

    public PaymentService(IPaymentStrategy paymentStrategy)
    {
        _paymentStrategy = paymentStrategy;
    }

    public void Process(decimal amount)
    {
        _paymentStrategy.Pay(amount);
    }
}

Now a new payment method can be introduced:

public class BankTransferPayment : IPaymentStrategy
{
    public void Pay(decimal amount)
    {
        // Process bank transfer
    }
}

The existing payment implementations do not need to change.

Strategy Pattern and OCP

This is one of the clearest relationships between SOLID and design patterns:

Problem
   ↓
Multiple interchangeable behaviors
   ↓
Identify the variation
   ↓
Encapsulate each behavior
   ↓
Strategy Pattern
   ↓
Add new strategies without changing existing strategies

The Strategy Pattern is particularly useful when several algorithms or business rules implement the same conceptual operation.

Factory Pattern and OCP

A Factory can be useful when object creation is itself a concern.

For example:

public interface IPaymentProcessor
{
    void Process(decimal amount);
}

Implementations:

IPaymentProcessor
       |
       +---- CreditCardProcessor
       +---- UpiProcessor
       +---- BankTransferProcessor

A simple factory might select an implementation:

public class PaymentProcessorFactory
{
    public IPaymentProcessor Create(string type)
    {
        return type switch
        {
            "CreditCard" => new CreditCardProcessor(),
            "UPI" => new UpiProcessor(),
            "BankTransfer" => new BankTransferProcessor(),
            _ => throw new ArgumentException("Unsupported payment type")
        };
    }
}

However, notice something important.

The factory itself must change when a new payment type is added.

Therefore, this factory is not automatically an example of a completely closed-for-modification design.

It can still be a useful solution if the creation logic is intentionally centralized and the trade-off is acceptable.

In larger .NET applications, dependency injection, keyed services, configuration-driven registration, or other approaches may sometimes provide a better fit.

The lesson is:

Do not use a pattern simply because its name appears in a SOLID discussion. Evaluate the actual design trade-off.

3. Liskov Substitution Principle — LSP

The Simple Explanation

The Liskov Substitution Principle states that:

A derived type should be usable wherever its base type is expected without violating the expectations of the consuming code.

In simpler terms:

If B is a subtype of A, replacing an A with a B should not unexpectedly break the program's correctness or behavioral assumptions.

LSP is less about syntax and more about behavioral contracts.

The Classic Example

Consider:

public class Bird
{
    public virtual void Fly()
    {
        Console.WriteLine("Flying");
    }
}

Now imagine:

public class Penguin : Bird
{
    public override void Fly()
    {
        throw new NotSupportedException();
    }
}

We have created a problem.

The base class exposes Fly() as a behavior that consumers can call.

But Penguin cannot provide that behavior.

This code becomes problematic:

Bird bird = new Penguin();

bird.Fly();

The derived type cannot safely satisfy the expectations created by the base abstraction.

A Better Design

The problem is the abstraction.

Not every bird needs to support flying.

We can separate the concepts:

public abstract class Bird
{
    public abstract void Move();
}

Then define flying separately:

public interface IFlyingBird
{
    void Fly();
}

An eagle can implement it:

public class Eagle : Bird, IFlyingBird
{
    public override void Move()
    {
        Fly();
    }

    public void Fly()
    {
        Console.WriteLine("Eagle is flying");
    }
}

A penguin does not need to implement IFlyingBird:

public class Penguin : Bird
{
    public override void Move()
    {
        Console.WriteLine("Penguin is walking");
    }
}

The abstraction now better represents the actual capabilities of the types.

LSP in Enterprise Applications

The Bird/Penguin example is useful for understanding the principle, but enterprise applications often encounter LSP problems in more subtle ways.

Consider a payment processor:

public abstract class PaymentProcessor
{
    public abstract void Process(decimal amount);
    public abstract void Refund(decimal amount);
}

Suppose an implementation does not support refunds:

public class SomePaymentProcessor : PaymentProcessor
{
    public override void Process(decimal amount)
    {
        // Process payment
    }

    public override void Refund(decimal amount)
    {
        throw new NotSupportedException();
    }
}

If consumers of PaymentProcessor reasonably expect every implementation to support refunds, the abstraction is too broad.

A better design may separate the capabilities:

public interface IPaymentProcessor
{
    void Process(decimal amount);
}

public interface IRefundProcessor
{
    void Refund(decimal amount);
}

An implementation can then support the capabilities it actually provides.

This example also connects naturally to the Interface Segregation Principle.

LSP and Composition

A useful way to avoid problematic inheritance is to consider composition.

Instead of creating a complex hierarchy:

BaseProcessor
     |
     +-- ProcessorA
     +-- ProcessorB
     +-- ProcessorC

consider whether behavior can be composed:

Processor
    |
    +-- Strategy
    +-- Validator
    +-- Formatter

Composition is not a replacement for inheritance in every situation, but it can reduce problems caused by incorrect inheritance relationships.

Common LSP Warning Signs

Look carefully when you see:

throw new NotSupportedException();

inside an overridden method.

This is not automatically an LSP violation.

Sometimes an unsupported operation is legitimate.

But it should trigger a design question:

Does the base abstraction promise behavior that this implementation cannot provide?

Other warning signs include:

Derived classes disabling base behavior
Derived classes significantly changing the meaning of base methods
Consumers checking concrete subtypes before using them
Large type-checking blocks
Frequent is checks against derived types
Special-case handling for particular subclasses

4. Interface Segregation Principle — ISP

The Simple Explanation

The Interface Segregation Principle states:

Clients should not be forced to depend on methods they do not use.

In simpler terms:

Prefer focused interfaces that represent meaningful capabilities over large interfaces containing unrelated operations.

A Common Problem

Consider an employee management system:

public interface IEmployee
{
    void Work();
    void Eat();
    void AttendMeeting();
    void WriteCode();
    void ManageTeam();
}

Now imagine a developer:

public class Developer : IEmployee
{
    public void Work()
    {
    }

    public void Eat()
    {
    }

    public void AttendMeeting()
    {
    }

    public void WriteCode()
    {
    }

    public void ManageTeam()
    {
        throw new NotSupportedException();
    }
}

The developer is forced to implement ManageTeam() even though that capability is not part of the developer's responsibility.

This is a sign of a fat interface.

Split the Interface

Instead, define smaller, cohesive interfaces:

public interface IWorker
{
    void Work();
}

public interface IDeveloper
{
    void WriteCode();
}

public interface IManager
{
    void ManageTeam();
}

Now:

public class Developer : IWorker, IDeveloper
{
    public void Work()
    {
    }

    public void WriteCode()
    {
    }
}

And:

public class EngineeringManager : IWorker, IManager
{
    public void Work()
    {
    }

    public void ManageTeam()
    {
    }
}

Each class depends only on the capabilities it needs.

ISP in an Enterprise Service

Imagine a large customer service interface:

public interface ICustomerService
{
    Customer GetCustomer(int id);
    void CreateCustomer(Customer customer);
    void UpdateCustomer(Customer customer);
    void DeleteCustomer(int id);
    void SendMarketingEmail(int id);
    void ExportCustomers();
}

Different consumers may need completely different capabilities.

Instead, we could separate them:

public interface ICustomerReader
{
    Customer GetCustomer(int id);
}

public interface ICustomerWriter
{
    void CreateCustomer(Customer customer);
    void UpdateCustomer(Customer customer);
    void DeleteCustomer(int id);
}

public interface ICustomerExporter
{
    void ExportCustomers();
}

This creates smaller contracts that can be consumed independently.

Patterns That Can Support ISP

Some patterns can complement interface segregation:

Adapter — exposes the interface a client actually needs
Facade — provides a focused interface over a more complex subsystem
Proxy — can provide a focused boundary around another component

Again, the pattern does not implement ISP automatically.

The important design decision is to ensure clients are not forced to depend on irrelevant operations.

Common ISP Mistake

Do not interpret ISP as:

"Every interface should contain exactly one method."

That is not the principle.

An interface can contain several methods when they represent one cohesive capability.

For example:

public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(int id);
    Task AddAsync(Order order);
    Task UpdateAsync(Order order);
}

These operations may form a cohesive persistence contract.

The goal is cohesion, not an arbitrary number of methods.

5. Dependency Inversion Principle — DIP

The Simple Explanation

The Dependency Inversion Principle states:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

It also states:

Abstractions should not depend on details. Details should depend on abstractions.

In simpler terms:

Business logic should not be tightly coupled to infrastructure details.

A Common Problem

Consider:

public class OrderService
{
    private readonly SqlOrderRepository _repository;

    public OrderService()
    {
        _repository = new SqlOrderRepository();
    }

    public void CreateOrder(Order order)
    {
        _repository.Save(order);
    }
}

OrderService directly creates SqlOrderRepository.

The business service now knows:

Which persistence implementation is being used
How the repository is created
That the repository is backed by SQL Server

This creates tight coupling.

Introduce an Abstraction

Define:

public interface IOrderRepository
{
    void Save(Order order);
}

The infrastructure implementation can be:

public class SqlOrderRepository : IOrderRepository
{
    public void Save(Order order)
    {
        // Save to SQL Server
    }
}

Now the service depends on the abstraction:

public class OrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public void CreateOrder(Order order)
    {
        _repository.Save(order);
    }
}

The dependency direction becomes:

Before:

OrderService
     |
     ↓
SqlOrderRepository


After:

OrderService
     |
     ↓
IOrderRepository
     ↑
     |
SqlOrderRepository

The high-level business logic no longer needs to know the concrete persistence implementation.

Dependency Inversion vs Dependency Injection

These concepts are closely related but are not the same thing.

Dependency Inversion Principle

DIP is a design principle.

It describes how high-level and low-level components should depend on abstractions.

Dependency Injection

Dependency Injection is a technique for providing dependencies to a class from outside the class.

For example:

public OrderService(IOrderRepository repository)
{
    _repository = repository;
}

This is constructor injection.

In ASP.NET Core, the built-in dependency injection container can register the implementation:

builder.Services.AddScoped<IOrderRepository, SqlOrderRepository>();
builder.Services.AddScoped<OrderService>();

The framework can then provide SqlOrderRepository when OrderService is created.

So the relationship is:

DIP
 ↓
Design principle

Dependency Injection
 ↓
Implementation technique

Dependency Injection is one common way to implement a design that follows DIP.

SOLID and Design Patterns — The Practical Connection

Now let's connect the principles with patterns and techniques that can help address related design problems.

SOLID Principle	Patterns / Techniques That May Help	Typical Design Problem
SRP	Command, Strategy, Decorator, Facade, Repository	Too many independent responsibilities
OCP	Strategy, Decorator, Template Method, Factory	New behavior repeatedly requires modifying existing code
LSP	Strategy, Adapter, Composition	Incorrect or overly restrictive inheritance
ISP	Adapter, Facade, Proxy	Clients depend on unnecessary operations
DIP	Dependency Injection, Adapter, Repository, Factory	Business logic depends directly on implementation details

This is not a strict one-to-one mapping.

A pattern can support multiple SOLID principles, and a SOLID principle can be applied without using a design pattern.

For example:

Strategy
   ↓
Can support OCP
   ↓
Can also help SRP
   ↓
May also improve testability

Likewise:

Adapter
   ↓
Can help isolate an external dependency
   ↓
Can support DIP
   ↓
Can expose a focused interface
   ↓
Can support ISP

The correct approach is to start with the design problem, not the pattern name.

SOLID Does Not Mean "More Interfaces"

One of the biggest misconceptions about SOLID is:

"If I create interfaces everywhere, my code is SOLID."

Not necessarily.

Consider:

public interface IUserService
{
    void CreateUser();
}

public class UserService : IUserService
{
    public void CreateUser()
    {
    }
}

If the interface provides no meaningful abstraction or architectural boundary, it may simply add indirection.

Instead, ask:

Where do I actually need an abstraction?

Useful boundaries often include:

External systems
Infrastructure
Business strategies
Multiple implementations
Testing boundaries
Plugin-style architectures
Components that are expected to vary independently

Abstraction has a cost.

Use it where it provides a meaningful benefit.

SOLID Does Not Mean "Create More Classes"

Another common mistake is over-fragmentation.

For example:

OrderService
OrderValidator
OrderCalculator
OrderMapper
OrderLogger
OrderFormatter
OrderHelper
OrderUtility
OrderManager
OrderProcessor
OrderHandler

Having many classes does not automatically mean the design is better.

A highly fragmented design can introduce:

More dependencies
More files
More abstractions
More cognitive overhead
More difficult debugging
More complex dependency graphs

The objective is appropriate separation, not maximum separation.

SOLID Does Not Mean "Remove Every if/else"

Another misconception is:

"SOLID means removing every if/else statement."

That's not true.

This can be perfectly reasonable:

if (order.Total > 1000)
{
    ApplyDiscount(order);
}

The question is whether the conditional represents a stable rule or whether it is continuously growing with independently changing behavior.

For example:

if (paymentType == "CreditCard")
{
}
else if (paymentType == "UPI")
{
}
else if (paymentType == "PayPal")
{
}
else if (paymentType == "BankTransfer")
{
}

If this list continuously grows and each branch represents an independent behavior, the Strategy Pattern may be worth considering.

The pattern should be introduced because it improves the design, not simply because an if statement exists.

SOLID Does Not Mean "Use Every Design Pattern"

Design patterns are tools.

Using them everywhere can create unnecessary complexity.

For example, a simple calculation does not need:

Abstract Factory
      ↓
Factory Method
      ↓
Strategy
      ↓
Decorator
      ↓
Mediator

when this may be sufficient:

public decimal CalculateTax(decimal amount)
{
    return amount * 0.18m;
}

A good engineer knows not only how to apply patterns, but also when not to apply them.

A Real-World Example: Notification System

Let's bring several SOLID principles together using a notification system.

Suppose an application needs to send:

Email
SMS
Push notifications

A simple implementation might look like this:

public class NotificationService
{
    public void Send(string type, string recipient, string message)
    {
        if (type == "Email")
        {
            // Send email
        }
        else if (type == "SMS")
        {
            // Send SMS
        }
        else if (type == "Push")
        {
            // Send push notification
        }
    }
}

It works.

But what happens when we add:

WhatsApp
Microsoft Teams
Slack

The class keeps growing.

Introduce an Abstraction

public interface INotificationSender
{
    Task SendAsync(string recipient, string message);
}

Email:

public class EmailNotificationSender : INotificationSender
{
    public Task SendAsync(string recipient, string message)
    {
        // Send email
        return Task.CompletedTask;
    }
}

SMS:

public class SmsNotificationSender : INotificationSender
{
    public Task SendAsync(string recipient, string message)
    {
        // Send SMS
        return Task.CompletedTask;
    }
}

Push:

public class PushNotificationSender : INotificationSender
{
    public Task SendAsync(string recipient, string message)
    {
        // Send push notification
        return Task.CompletedTask;
    }
}

The application service can work with the abstraction:

public class NotificationService
{
    private readonly INotificationSender _sender;

    public NotificationService(INotificationSender sender)
    {
        _sender = sender;
    }

    public Task SendAsync(string recipient, string message)
    {
        return _sender.SendAsync(recipient, message);
    }
}

The resulting design is:

NotificationService
        |
        ↓
INotificationSender
        ↑
        |
  +-----+-----+------+
  |           |      |
Email        SMS    Push

Several principles are represented here.

SRP

Each sender is responsible for one notification mechanism.

OCP

A new notification mechanism can be introduced as another implementation without changing the existing senders.

LSP

Each implementation should honor the behavioral contract defined by INotificationSender.

ISP

The interface contains only the operation needed by notification senders.

DIP

NotificationService depends on INotificationSender, not directly on an email, SMS, or push provider.

This is a good example of how SOLID principles can work together rather than being treated as five isolated rules.

How to Identify SOLID Issues During Code Review

Instead of checking the five principles mechanically, ask practical questions.

SRP Questions

Does this class have unrelated responsibilities?
Would different concerns cause different changes to this class?
Does the class interact with too many unrelated technologies?
Is the class becoming a "God class"?

OCP Questions

Does adding a new behavior require modifying existing logic?
Is a conditional structure continuously growing?
Are new business rules repeatedly being added to the same class?
Can the changing behavior be isolated?

LSP Questions

Does a subclass throw NotSupportedException for inherited behavior?
Does a subclass change the expected meaning of a base method?
Do consumers need to check the concrete subtype before using it?
Is inheritance actually representing the required behavioral relationship?

ISP Questions

Are implementations forced to implement irrelevant methods?
Is the interface becoming very large?
Do different consumers use completely different subsets of the interface?
Can the contract be divided into meaningful capabilities?

DIP Questions

Does business logic directly instantiate infrastructure classes?
Does a service depend directly on a database provider?
Does business logic know about external SDK implementation details?
Can an infrastructure implementation be replaced without changing business logic?

A Practical SOLID Refactoring Workflow

You do not need to redesign an entire application whenever you discover a SOLID issue.

A practical workflow is:

Step 1 — Identify What Changes

Ask:

What is likely to change independently?

Examples:

Payment provider
Notification channel
Database
Pricing algorithm
Authentication mechanism
File storage provider

Step 2 — Identify the Coupling

Ask:

Which component knows too much about this changing behavior?

Step 3 — Identify the Responsibility

Ask:

Can this behavior be separated without making the design unnecessarily complex?

Step 4 — Introduce an Abstraction When It Adds Value

For example:

public interface IPaymentProcessor
{
    Task ProcessAsync(decimal amount);
}

Step 5 — Choose a Pattern If It Fits

For example:

Multiple interchangeable algorithms
        ↓
Strategy Pattern

External system has an incompatible API
        ↓
Adapter Pattern

Object creation is complex or needs encapsulation
        ↓
Factory Pattern

Step 6 — Keep the Design Simple

Do not introduce five abstractions when one abstraction solves the problem.

SOLID in a Typical .NET Application

A typical enterprise application may have a structure similar to:

                 API Controller
                       |
                       ↓
              Application Service
                       |
          +------------+------------+
          |            |            |
          ↓            ↓            ↓
     Repository     Payment     Notification
          |         Strategy       Service
          ↓            |
      Database      +--+--+
                    |     |
                  Card   UPI

This does not mean every .NET application should have exactly this structure.

It simply demonstrates how the principles can work together.

SRP

Components have focused responsibilities.

OCP

New payment strategies can be introduced without modifying existing payment strategies.

LSP

Payment implementations should honor the abstraction's behavioral contract.

ISP

Consumers can depend on focused interfaces.

DIP

Application-level code depends on abstractions rather than infrastructure implementations.

SOLID vs Design Patterns

SOLID Principles	Design Patterns
Design principles	Reusable design approaches
Help guide design decisions	Help solve recurring design problems
More abstract	More concrete
Help identify desirable design characteristics	Provide implementation techniques
Can be applied without design patterns	Can be used independently of SOLID
Focus on maintainability and flexibility	Focus on recurring structural or behavioral problems

A useful mental model is:

SOLID tells you what characteristics to aim for. Design patterns provide techniques that may help you achieve those characteristics.

When Should You Not Apply SOLID Aggressively?

SOLID is valuable, but context matters.

For a small application with a simple and stable requirement:

Simple problem
     ↓
Simple implementation

may be better than:

Simple problem
     ↓
Multiple interfaces
     ↓
Multiple factories
     ↓
Multiple strategies
     ↓
Complex dependency graph

For a larger application with:

Multiple teams
Frequent requirement changes
External integrations
Complex business rules
Long-term maintenance
Significant automated testing requirements

appropriate abstractions can provide greater value.

The right design depends on:

Complexity
Change frequency
Number of implementations
Team size
Testing requirements
Expected lifetime of the software
Operational requirements

SOLID is a design guide, not a requirement to maximize abstraction.

A Simple SOLID Mental Model

When reviewing a class, ask these five questions:

1. S — Does this class have too many independent reasons to change?

2. O — Do I repeatedly modify this code whenever a new behavior is introduced?

3. L — Can every implementation genuinely honor the behavioral contract
       of its abstraction?

4. I — Is the interface asking implementations to support things they
       don't need?

5. D — Does my business logic depend directly on infrastructure or
       concrete implementations?

These questions are often more useful during code reviews than simply memorizing five definitions.

SOLID Design Pattern Quick Reference

Principle	Common Design Smell	Possible Refactoring	Patterns / Techniques That May Help
SRP	One class has unrelated responsibilities	Extract cohesive responsibilities	Command, Strategy, Decorator, Facade, Repository
OCP	New behavior repeatedly requires modifying existing code	Encapsulate variation behind abstractions	Strategy, Decorator, Template Method, Factory
LSP	Derived type cannot honor the base contract	Redesign the abstraction or prefer composition	Strategy, Adapter, Composition
ISP	Large interface with irrelevant methods	Split into cohesive capabilities	Adapter, Facade, Proxy
DIP	Business logic directly depends on infrastructure	Introduce appropriate abstractions	Dependency Injection, Adapter, Repository, Factory

This table is a practical association, not a strict rule.

There is no requirement that a particular SOLID principle must always be implemented using a particular pattern.

Common SOLID Misconceptions

Misconception 1: "SOLID means more interfaces."

Reality: Interfaces are useful when they represent meaningful abstractions or boundaries.

Misconception 2: "SOLID means every class should have one method."

Reality: SRP is about reasons to change, not method count.

Misconception 3: "SOLID means no if/else statements."

Reality: Conditional logic is perfectly valid. The question is whether independently changing behavior is becoming tightly coupled.

Misconception 4: "DIP and Dependency Injection are the same."

Reality: DIP is a design principle. Dependency Injection is one technique that can help implement it.

Misconception 5: "Every SOLID problem requires a design pattern."

Reality: Sometimes a simple refactoring is the best solution.

Misconception 6: "Inheritance is always better than composition."

Reality: Inheritance is useful when the subtype genuinely satisfies the behavioral contract of the base abstraction. Composition can be preferable when behavior needs to vary independently.

Misconception 7: "Following SOLID guarantees good architecture."

Reality: SOLID addresses important object-oriented design concerns, but good architecture also requires consideration of performance, security, reliability, scalability, maintainability, operational complexity, and business requirements.

The Most Important Lesson

When developers learn SOLID, it is tempting to memorize statements such as:

SRP → One responsibility

OCP → Open for extension, closed for modification

LSP → Subtypes must be substitutable

ISP → Small interfaces

DIP → Depend on abstractions

These definitions are useful, but they are only the starting point.

A more useful engineering mindset is:

What is changing?
       ↓
What is coupled to that change?
       ↓
Is the responsibility cohesive?
       ↓
Is the abstraction meaningful?
       ↓
Can the dependency be inverted?
       ↓
Would a design pattern simplify the solution?
       ↓
Is the resulting design actually easier to maintain?

That is where SOLID becomes practical.

Final Takeaways

SOLID is not about writing more code.

It is about making change easier to manage.

The five principles can be summarized as:

SRP
→ Keep responsibilities focused.

OCP
→ Isolate expected variation so new behavior can be added with
  minimal modification to stable code.

LSP
→ Make abstractions behaviorally trustworthy.

ISP
→ Keep contracts focused on meaningful capabilities.

DIP
→ Keep high-level business logic independent from implementation details.

Design patterns and techniques can support these principles:

SRP → Command, Strategy, Decorator, Facade, Repository

OCP → Strategy, Decorator, Template Method, Factory

LSP → Strategy, Adapter, Composition

ISP → Adapter, Facade, Proxy

DIP → Dependency Injection, Adapter, Repository, Factory

But there is an even more important lesson:

Don't start with a design pattern. Start with the problem.

Ask:

What is changing?
What is tightly coupled to that change?
Can the responsibility be separated?
Is an abstraction actually useful?
Would a design pattern simplify the solution?
Does the resulting design reduce complexity rather than increase it?

Good software design is not about following SOLID mechanically.

It is about creating a codebase where responsibilities are clear, dependencies are manageable, expected changes are easier to accommodate, and complexity is kept under control.

The best SOLID design is not the one with the most abstractions.

It is the one that makes the important changes easier without introducing unnecessary complexity.

Practical SOLID Checklist

Before committing a significant design change, ask:

□ Does each component have a clear and cohesive responsibility?

□ Can expected variations be added without repeatedly changing stable code?

□ Can implementations safely honor the contracts of their abstractions?

□ Are interfaces focused on meaningful capabilities?

□ Does business logic avoid unnecessary dependencies on infrastructure details?

□ Am I introducing an abstraction because I need it, rather than because
  SOLID tells me to?

□ Am I using a design pattern because it solves a real problem?

□ Has the solution become simpler or more maintainable?

□ Have I avoided unnecessary layers and abstractions?

If the answer to these questions is clear, you are applying SOLID as an engineering principle, rather than simply memorizing its definitions.

programming

csharp

dotnet

solid

designpatterns

softwarearchitecture

RAG Explained: A Beginner's Guide to Retrieval-Augmented Generation

Chethan Ramaswamy — Sat, 26 Sep 2026 06:31:04 +0000

📑 Contents

Imagine You Have 10,000 Company Documents
So, What Is RAG?
A Simple Real-World Example
How Does RAG Actually Work?
- Stage 1: Prepare the Knowledge
- Step 1: Collect Your Documents
- Step 2: Break Large Documents into Smaller Pieces
- Step 3: Create Embeddings
- Step 4: Store the Information
- Stage 2: Answer the User's Question
- Step 5: The User Asks a Question
- Step 6: Give the Information to the AI
The Complete RAG Flow
- Preparing the knowledge
- Answering a question
Is RAG Just Search?
RAG vs Fine-Tuning
Where Can We Use RAG?
- Developer Assistant
- HR Assistant
- Customer Support
- Enterprise Knowledge Assistant
Does RAG Make AI 100% Accurate?
What Does RAG Look Like with .NET and Azure?
The 5 Things You Need to Remember
Your Turn
Key Takeaway

If you've started learning Generative AI, you've probably come across terms like:

LLM. Embeddings. Vector Search. RAG.

At first, these terms can sound complicated.

But the basic idea behind RAG is actually quite simple.

Let's understand it with a real-world example. 👇

🤔 Imagine You Have 10,000 Company Documents

Imagine your company has thousands of documents:

HR policies
Travel policies
Product documentation
Technical guides
Customer FAQs
Security guidelines

Now an employee asks:

"How much can I claim for a hotel during business travel?"

Would you expect a general AI model to know your company's specific policy?

Probably not.

The information is inside your company's documents.

This is where RAG becomes useful.

💡 So, What Is RAG?

RAG stands for Retrieval-Augmented Generation.

Think of RAG like this:

Find the right information first, then ask the AI to answer using that information.

That's the basic idea.

A simplified flow looks like this:

User asks a question
        ↓
Find relevant information
        ↓
Give that information to the AI
        ↓
AI generates an answer

Let's see how this works.

🏨 A Simple Real-World Example

Suppose your company's travel policy says:

Employees can claim hotel expenses up to ₹5,000 per night when traveling for business.

An employee asks:

"What is the hotel reimbursement limit?"

A RAG application can:

Search the company's travel policy.
Find the relevant information.
Provide that information to the AI.
Generate an answer.

The AI can then respond:

"According to the travel policy, employees can claim hotel expenses up to ₹5,000 per night."

Notice what happened?

The AI didn't need to already know your company's travel policy.

The application retrieved the relevant information first.

That's the basic idea behind RAG.

🔍 How Does RAG Actually Work?

Let's break it down into a few simple steps.

Don't worry — we'll keep the technical jargon to a minimum.

A basic RAG application can be understood in two stages:

Prepare the knowledge
Answer the user's question

Let's look at both.

📚 Stage 1: Prepare the Knowledge

Before users can ask questions, we need to prepare the documents so that relevant information can be found quickly.

📄 Step 1: Collect Your Documents

Your knowledge could come from many places:

📄 PDF files
📝 Word documents
🌐 Websites
🗄️ Databases
☁️ Cloud storage
📚 Knowledge bases

For example:

Company Knowledge
       │
       ├── HR Policy.pdf
       ├── Travel Policy.pdf
       ├── Security Policy.pdf
       └── Product Manual.pdf

These documents become the knowledge source for our AI application.

✂️ Step 2: Break Large Documents into Smaller Pieces

Imagine you have a 100-page travel policy.

We don't want to send all 100 pages to the AI every time someone asks a question.

Instead, we divide the document into smaller pieces called chunks.

Travel Policy
      │
      ├── Chunk 1
      ├── Chunk 2
      ├── Chunk 3
      ├── Chunk 4
      └── ...

Why?

Because when someone asks a question, we usually need only the small section related to that question.

For example:

Question:

"What is the hotel reimbursement limit?"

The system might retrieve:

Chunk 27:

"Employees can claim hotel expenses
up to ₹5,000 per night..."

That's much more useful than sending the entire document to the AI.

💡 Think of it this way

Imagine giving a student a 500-page textbook and asking:

"Find the paragraph about hotel reimbursement."

It would take time to search through the entire book.

Instead, if we already know the relevant page, we can go directly there.

Chunking helps us create those smaller searchable pieces of information.

🧠 Step 3: Create Embeddings

Here's our first technical concept:

Embeddings.

Embeddings are numerical representations of text that help systems measure semantic similarity.

Embeddings help a system find information based on semantic similarity, rather than only matching exact words.

For example:

User asks:

"How much can I claim for a hotel?"

The document says:

"Hotel accommodation expenses are limited to ₹5,000 per night."

The words aren't exactly the same.

But the meaning is related.

Embeddings help the system identify this semantic similarity.

You can think of it like this:

Text
 ↓
Embedding Model
 ↓
Numerical Vector
 ↓
Compare with other vectors
 ↓
Find semantically similar content

You don't need to understand the mathematics behind embeddings to start learning RAG.

The important thing to remember is:

Embeddings help a system find information based on semantic similarity, rather than only matching exact words.

🗂️ Step 4: Store the Information

Now we need somewhere to store our document chunks and their embeddings.

This is where vector databases and vector search systems come in.

Some popular options include:

Azure AI Search
PostgreSQL + pgvector
Pinecone
Qdrant
Weaviate

Think of this as a smart search system for your documents.

Conceptually:

Document Chunk
      +
Embedding
      +
Metadata
      ↓
Vector Search

Metadata can contain information such as:

Document: TravelPolicy.pdf
Department: Finance
Year: 2026
DocumentType: Policy

This additional information can help the application filter and organize the data.

🔎 Stage 2: Answer the User's Question

Now our knowledge has been prepared.

Let's see what happens when a user asks a question.

🔎 Step 5: The User Asks a Question

The employee asks:

"What is the hotel reimbursement limit?"

The application converts the question into an embedding and uses it to search the knowledge base.

The search might return several results:

Result 1:
Employees can claim hotel expenses
up to ₹5,000 per night.

Result 2:
Business travel expenses must be
submitted within 30 days.

Result 3:
International travel requires
manager approval.

The application identifies the information that is most relevant to the question.

🤖 Step 6: Give the Information to the AI

Now we have two important pieces:

Question:

What is the hotel reimbursement limit?

Relevant information:

Employees can claim hotel expenses up to ₹5,000 per night.

The application provides the question and retrieved context to the LLM.

Conceptually:

User Question
      +
Retrieved Context
      ↓
Prompt
      ↓
LLM
      ↓
Generated Answer

The LLM can then generate:

"Employees can claim hotel expenses up to ₹5,000 per night."

And that's the Generation part of Retrieval-Augmented Generation.

🧩 The Complete RAG Flow

Now let's separate the process into two simple flows.

Preparing the knowledge

Documents
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector Search Index

Answering a question

User Question
      ↓
Question Embedding
      ↓
Search the Knowledge Base
      ↓
Relevant Chunks
      ↓
Question + Retrieved Context
      ↓
LLM
      ↓
Final Answer

This is the heart of a RAG application.

Retrieve relevant information → provide it as context → generate an answer.

🔍 Is RAG Just Search?

Not exactly.

Traditional search might work like this:

Question
   ↓
Search
   ↓
List of Documents

You then need to open the documents and find the answer yourself.

RAG goes one step further:

Question
   ↓
Search Relevant Information
   ↓
Provide Context to AI
   ↓
Generate Answer

So you can think of RAG as:

Search + AI

Traditional search helps you find information.

A RAG application helps an AI system retrieve relevant information and generate an answer using that information.

🆚 RAG vs Fine-Tuning

This is another question beginners often have:

"Why not fine-tune the model instead?"

RAG and fine-tuning solve different problems.

RAG	Fine-Tuning
Retrieves external information at query time	Further trains the model
Useful when knowledge changes frequently	Useful for specialized behavior or tasks
Documents can be updated independently	Requires a training process
Commonly used for knowledge-based applications	Commonly used for specialized model behavior

A simple way to remember it:

RAG → Give the AI relevant information.

Fine-tuning → Adapt the AI for a specific behavior or task.

For example, if your company's HR policy changes next month, you can update the knowledge source used by a RAG application without retraining the language model.

🌎 Where Can We Use RAG?

RAG isn't limited to company policies.

It can be used in many real-world applications.

👨‍💻 Developer Assistant

A developer asks:

"How does our authentication service work?"

The RAG application searches the company's technical documentation and provides relevant context to the LLM.

🏢 HR Assistant

An employee asks:

"How many vacation days can I carry forward?"

The application searches HR policies and generates an answer based on the retrieved information.

🛠️ Customer Support

A customer asks:

"How do I reset my device?"

The application can search product documentation and provide step-by-step guidance.

📚 Enterprise Knowledge Assistant

An employee asks:

"What is the process for raising a purchase request?"

The application searches company procedures and generates a response.

The common pattern is:

Company Knowledge
       ↓
      RAG
       ↓
      LLM
       ↓
  AI Assistant

⚠️ Does RAG Make AI 100% Accurate?

No.

This is important to understand.

RAG can provide the AI with relevant information, but it does not guarantee a perfect answer.

For example, if the retrieval system finds the wrong information, the LLM may generate an incorrect response based on that context.

There can also be problems if:

The source document contains incorrect information.
Important information was not retrieved.
The retrieved context is incomplete.
The prompt doesn't clearly guide the model.
The model misunderstands the retrieved context.

That's why production RAG systems need good:

Document processing
Search and retrieval
Security
Prompt design
Evaluation
Monitoring

So don't think of RAG as a magic solution.

Instead, think of it as a way to ground an AI application with relevant external information.

☁️ What Does RAG Look Like with .NET and Azure?

If you're a .NET developer, a simple enterprise RAG architecture could look like this:

                 User
                   ↓
              .NET Web API
                   ↓
             Azure AI Search
                   ↓
             Relevant Chunks
                   ↓
             Prompt + Context
                   ↓
             Azure OpenAI
                   ↓
              AI Response

Your .NET application can orchestrate the process:

Receive the user's question.
Search for relevant information.
Retrieve the relevant chunks.
Build the prompt with the retrieved context.
Send the request to the AI model.
Return the response.

This makes RAG particularly interesting for developers working with .NET and Azure.

🎯 The 5 Things You Need to Remember

If you're completely new to RAG, remember these five concepts:

Documents

Where your knowledge lives.
Chunks

Smaller pieces of your documents.
Embeddings

Numerical representations that help systems measure semantic similarity.
Retrieval

Finding information relevant to the user's question.
Generation

The LLM uses the retrieved information to generate the answer.

Put them together:

Documents
    ↓
Chunks
    ↓
Embeddings
    ↓
Search
    ↓
Relevant Context
    ↓
LLM
    ↓
Answer

That's Retrieval-Augmented Generation.

💬 Your Turn

Have you tried building a RAG application?

What would you like to build with RAG?

👨‍💻 Developer assistant
📄 Document chatbot
🏢 Enterprise knowledge assistant
🛠️ Customer support assistant
🤖 Something else

Share your idea in the comments. 👇

📌 Key Takeaway

If you remember just one sentence from this article, remember this:

A RAG application retrieves relevant information from a knowledge source and provides it to an LLM so it can generate a more informed response.

And that's the foundation of many modern Generative AI applications.

Designing a Scalable Notification System using .NET, Azure Service Bus, MediatR, and SignalR

Chethan Ramaswamy — Tue, 31 Mar 2026 19:35:49 +0000

📌 What We'll Cover

Why I'm Writing This
The Problem with the "Simple" Approach
A Better Approach: Event-Driven Notifications
High-Level Architecture
Where MediatR Fits
Why Azure Service Bus?
- Loose Coupling
- Retry and Failure Handling
- Independent Scaling
- Future Integrations
Topics and Subscriptions
SignalR for Real-Time Notifications
SignalR at Scale
End-to-End Flow
- Step 1 — User Performs an Action
- Step 2 — API Receives the Request
- Step 3 — Command Handler Processes the Business Operation
- Step 4 — Outbox Processor Publishes the Event
- Step 5 — Consumers Process the Event
- Step 6 — Real-Time Update Reaches the Client
One Important Production Consideration: The Outbox Pattern
Handling Duplicate Messages
Trade-Offs
Where This Architecture Works Well
- E-commerce
- Banking
- Monitoring Platforms
- Enterprise Applications
Key Design Principles
- MediatR
- Azure Service Bus
- Azure Service Bus Topics and Subscriptions
- SignalR
- Azure SignalR Service
- Outbox Pattern
- Idempotent Consumers
- Dead-Letter Handling
Final Thoughts

Why I'm Writing This

“Send a notification when something happens.”

It sounds simple.

But in a real application, notifications can quickly become more complicated than expected.

You may need to support:

Real-time UI notifications
Email and SMS
Multiple consumers
Retries and failure handling
High traffic
Future integrations
Loose coupling between business logic and notification processing

The challenge is not simply how to send a notification.

The real question is:

How do we design notifications so they don't become tightly coupled to the core business flow?

This article walks through one approach using .NET, MediatR, Azure Service Bus, SignalR, and the Outbox Pattern.

The Problem with the "Simple" Approach

A common implementation starts with something like:

API
  ↓
Save to Database
  ↓
Send Email
  ↓
Send Notification

It works.

At least initially.

But as the application grows, problems start appearing.

Every feature begins calling notification logic directly:

OrderService → NotificationService
PaymentService → NotificationService
UserService → NotificationService

Then new requirements arrive:

Add SMS
Add push notifications
Add in-app notifications
Add analytics
Add audit events

The notification service gradually becomes tightly coupled to multiple parts of the application.

Another problem is failure handling.

What happens if the email provider is temporarily unavailable?

Should the order creation fail?

Usually, the answer is no.

The business operation and notification delivery have different reliability requirements.

A Better Approach: Event-Driven Notifications

The basic idea is:

Business Action
      ↓
Domain/Application Event
      ↓
Outbox
      ↓
Message Broker
      ↓
Notification Consumers
      ↓
Email / UI / SMS / Push / etc.

The business operation completes without waiting for every notification channel to finish.

This creates a much cleaner boundary between:

"Something happened"

and

"What should we do because it happened?"

High-Level Architecture

The production-oriented architecture looks like this:

                         ┌──────────────────┐
                         │      Client      │
                         └────────┬─────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │   .NET Web API   │
                         └────────┬─────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │     MediatR      │
                         │ Command Handler  │
                         └────────┬─────────┘
                                  │
                                  ▼
                     ┌──────────────────────────┐
                     │    Database Transaction  │
                     │                          │
                     │  ┌────────┐ ┌─────────┐ │
                     │  │ Order  │ │ Outbox  │ │
                     │  └────────┘ └─────────┘ │
                     └────────────┬─────────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │ Outbox Processor │
                         └────────┬─────────┘
                                  │
                                  ▼
                     ┌────────────────────────┐
                     │  Azure Service Bus     │
                     │        Topic           │
                     └────────────┬───────────┘
                                  │
                   ┌──────────────┼──────────────┐
                   │              │              │
                   ▼              ▼              ▼
             ┌──────────┐   ┌───────────┐  ┌──────────┐
             │  Email   │   │  SignalR  │  │  Audit   │
             │ Consumer │   │  Consumer │  │ Consumer │
             └──────────┘   └─────┬─────┘  └──────────┘
                                  │
                                  ▼
                     ┌────────────────────────┐
                     │ Azure SignalR Service  │
                     └────────────┬───────────┘
                                  │
                                  ▼
                           ┌─────────────┐
                           │   Clients   │
                           │Browser/Mobile│
                           └─────────────┘

The important principle is that each component has a specific responsibility.

The Outbox is part of the primary architecture, not an afterthought.

Where MediatR Fits

MediatR sits primarily inside the application layer.

Instead of having a controller directly coordinate business operations:

Controller
    ↓
Service
    ↓
Database

we can use a request/handler model:

Controller
    ↓
MediatR
    ↓
Command Handler
    ↓
Business Logic
    ↓
Database

For example:

public record CreateOrderCommand(
    int CustomerId,
    decimal Amount
) : IRequest<int>;

The handler processes the command:

public class CreateOrderHandler
    : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(
        CreateOrderCommand request,
        CancellationToken cancellationToken)
    {
        // Validate business rules
        // Create order
        // Save order

        return orderId;
    }
}

MediatR also provides a clean place for application-level cross-cutting concerns such as:

Validation
Logging
Performance measurement
Authorization
Transaction behavior

The important point is:

MediatR is not the message broker.

It helps with in-process application decoupling.

Azure Service Bus handles distributed messaging between processes or services.

That distinction becomes important as the system grows.

Why Azure Service Bus?

After the business operation is committed, an event such as OrderCreated needs to be delivered to downstream consumers.

With the Outbox Pattern, the event is first persisted as part of the same database transaction and is then published asynchronously.

For example:

{
  "eventType": "OrderCreated",
  "orderId": 12345,
  "customerId": 1001
}

The resulting flow becomes:

Order Service
     ↓
Outbox
     ↓
Outbox Processor
     ↓
Azure Service Bus
     ↓
Notification Consumers

Azure Service Bus provides the messaging infrastructure between the producer and consumers.

Instead of:

Order Service
     ↓
Notification Service

we have:

Order Service
     ↓
Outbox
     ↓
Azure Service Bus
     ↓
Notification Consumers

This provides several benefits.

1. Loose Coupling

The producer doesn't need to know which consumers exist.

Today:

OrderCreated
    ↓
Email

Tomorrow:

OrderCreated
    ↓
Email
SMS
Analytics
Audit
Push Notification

The order-processing logic doesn't need to change simply because another consumer was added.

2. Retry and Failure Handling

Azure Service Bus provides messaging and delivery mechanisms, while retry behavior is typically implemented through the Service Bus client and consumer/application logic.

Transient failures can therefore be handled without making the original business transaction depend on downstream notification delivery.

Messages that repeatedly fail processing can also be moved to a dead-letter queue for investigation or later recovery.

The exact retry strategy should be designed at the consumer level based on the type of failure.

For example:

Message
   ↓
Consumer
   ↓
Processing succeeds?
   ├── Yes → Complete message
   │
   └── No
       ↓
   Retry / Redelivery
       ↓
   Repeated failure?
       └── Dead-letter

3. Independent Scaling

The notification consumers can scale independently from the API.

For example:

API instances
     ↓
Outbox Processor
     ↓
Service Bus
     ↓
Notification Workers

If notification volume increases significantly, the consumer side can be scaled independently.

4. Future Integrations

The same event can potentially be consumed by additional systems without modifying the original producer.

This is particularly useful in larger enterprise environments.

Topics and Subscriptions

For multiple consumers, an Azure Service Bus Topic with multiple Subscriptions is a natural fit.

For example:

                  OrderCreated Event
                         │
                         ▼
                ┌─────────────────┐
                │ Azure Service   │
                │ Bus Topic       │
                └────────┬────────┘
                         │
             ┌───────────┼───────────┐
             │           │           │
             ▼           ▼           ▼
        Email Sub    SignalR Sub   Audit Sub
             │           │           │
             ▼           ▼           ▼
          Email       SignalR       Audit

Each subscription can receive its own copy of the message.

This keeps consumers independent.

It also means that one consumer can fail or be delayed without preventing another subscription from processing its own copy of the event.

SignalR for Real-Time Notifications

For browser-based real-time notifications, polling can introduce unnecessary latency and traffic.

SignalR allows the server to push messages to connected clients.

For example:

OrderCreated Event
        ↓
SignalR Consumer
        ↓
SignalR Hub
        ↓
Azure SignalR Service
        ↓
Connected Client

The client can receive something like:

"Order #12345 has been created successfully."

This works particularly well for:

Dashboards
Order tracking
Monitoring systems
Alerts
Chat-like applications
In-app notifications

A SignalR connection can also be associated with a user or group, allowing notifications to be targeted appropriately.

SignalR at Scale

A single SignalR server is straightforward.

The challenge appears when the application is deployed across multiple instances.

For example:

                       ┌──────────────────────┐
                       │   Azure SignalR      │
                       │      Service         │
                       └──────────┬───────────┘
                                  │
                    ┌─────────────┼─────────────┐
                    │             │             │
                    ▼             ▼             ▼
               API Instance   API Instance   API Instance

For Azure-hosted applications, Azure SignalR Service can provide the scale-out layer for SignalR connections.

This allows application instances to remain focused on application processing while Azure SignalR Service manages persistent client connections.

The exact deployment model depends on application scale, hosting model, and operational requirements.

End-to-End Flow

Let's put everything together.

Step 1 — User performs an action

The user creates an order.

Client → POST /orders

Step 2 — API receives the request

The controller sends a command through MediatR.

Controller
    ↓
CreateOrderCommand
    ↓
MediatR

Step 3 — Command handler processes the business operation

The handler validates the request and creates the order.

The order and the corresponding outbox event are persisted in the same database transaction.

Database Transaction
       │
       ├── Order
       │
       └── Outbox Event

This is important because it prevents the application from successfully committing the order while completely losing the event because of a separate publish operation.

Step 4 — Outbox processor publishes the event

A background process reads unpublished events from the outbox and publishes them to Azure Service Bus.

Database
   ↓
Outbox Processor
   ↓
Azure Service Bus Topic

The business transaction does not wait for the downstream consumers to finish.

Step 5 — Consumers process the event

Different consumers can react independently.

                 OrderCreated
                      ↓
              Azure Service Bus
                 /     |      \
                /      |       \
               ▼       ▼        ▼
            Email   SignalR    Audit

Step 6 — Real-time update reaches the client

The SignalR consumer sends an update to the appropriate connected client.

Service Bus
     ↓
SignalR Consumer
     ↓
SignalR Hub
     ↓
Azure SignalR Service
     ↓
Browser / Mobile

The key principle is:

Order creation should not depend on notification delivery succeeding.

One Important Production Consideration: The Outbox Pattern

There is a subtle issue with a simpler implementation.

Consider this sequence:

1. Save Order
2. Publish OrderCreated

What happens if step 1 succeeds but step 2 fails?

The order exists in the database, but the event was never published.

This is a classic dual-write problem.

For production systems where reliable event publishing is important, an Outbox Pattern can help.

Instead of:

Save Order
     ↓
Publish Event

we persist both the business data and the outgoing event in the same database transaction:

Database Transaction
       │
       ├── Order
       │
       └── Outbox Event

A background worker then reads the outbox and publishes events to Service Bus:

Database
   ↓
Outbox Processor
   ↓
Azure Service Bus
   ↓
Consumers

This separates the critical business transaction from downstream message delivery while preserving the event that needs to be published.

Handling Duplicate Messages

Messaging systems should generally be designed with the assumption that a message can potentially be delivered more than once.

Azure Service Bus commonly uses at-least-once delivery semantics with Peek-Lock processing, so consumers should be designed to handle duplicate delivery safely.

That means consumers should ideally be idempotent.

For example:

Message ID: 8f23...

The consumer can maintain a record of processed message IDs.

If the same message arrives again:

Message
   ↓
Already processed?
   ├── Yes → Ignore / safely return
   └── No  → Process

This becomes especially important when processing operations such as:

Sending emails
Updating notification state
Creating records
Calling external APIs

Azure Service Bus also provides duplicate detection capabilities, but duplicate detection should not be treated as a replacement for idempotent consumer design.

Trade-Offs

This architecture is not free.

You are introducing additional infrastructure:

Azure Service Bus
Outbox storage
Background consumers
SignalR / Azure SignalR Service
Monitoring
Retry handling
Dead-letter handling
Distributed tracing

There is also eventual consistency.

For example:

Order Created
      ↓
Outbox Event
      ↓
Event Published
      ↓
Consumer Processes Event
      ↓
Notification Appears

The notification might appear milliseconds or seconds after the business operation.

But that trade-off can be worthwhile when the system needs:

Scalability
Resilience
Independent consumers
Extensibility
Loose coupling

The architecture should still be evaluated against the actual requirements.

A small application with one notification channel may not need all of these components.

Where This Architecture Works Well

This pattern can be useful in systems such as:

E-commerce

OrderPlaced
    ↓
Email
Inventory
Payment
Shipping
Customer Notification

Banking

TransactionCompleted
    ↓
SMS
Email
Mobile Push
Audit
Fraud Monitoring

Monitoring Platforms

AlertRaised
    ↓
Dashboard
Email
SMS
Incident Management

Enterprise Applications

Any system where a business event may need to trigger multiple independent downstream actions can benefit from this approach.

Key Design Principles

The technology is important, but the architectural principles matter more.

MediatR

Use it for in-process application decoupling.

Azure Service Bus

Use it for asynchronous communication between distributed components.

Azure Service Bus Topics and Subscriptions

Use them when multiple independent consumers need to react to the same event.

SignalR

Use it for real-time communication with connected clients.

Azure SignalR Service

Consider it when SignalR needs to scale across multiple application instances in Azure.

Outbox Pattern

Use it when you need stronger guarantees between database state and event publishing.

Idempotent Consumers

Design consumers so duplicate messages don't create unintended side effects.

Dead-Letter Handling

Treat repeatedly failed messages as operational data that needs monitoring, investigation, and potentially controlled replay.

Final Thoughts

Notifications are easy to implement when a system is small.

They become much more interesting when the application needs to scale, support multiple channels, handle failures, and evolve over time.

A useful separation is:

Business Logic
      ↓
Database Transaction
      ↓
Outbox Event
      ↓
Message Broker
      ↓
Independent Consumers
      ↓
Notification Channels

With this approach, the core business operation doesn't need to know whether the notification is delivered through email, SignalR, SMS, push notifications, or a future integration.

The result is an architecture that is more decoupled, scalable, resilient, and easier to evolve.

And perhaps the most important lesson:

Don't let notification delivery become part of your critical business transaction unless it truly needs to be.

If you've implemented a similar architecture, I'd be interested in hearing how you handled retries, ordering, duplicate messages, dead-letter queues, and the outbox problem.

dotnet #azure #systemdesign #microservices #softwarearchitecture #azureservicebus #signalr #mediatr #eventdrivenarchitecture

DEV Community: Chethan Ramaswamy

Entity Framework Core Performance Optimization: A Practical Guide for .NET Developers

Entity Framework Core Performance Optimization: A Practical Guide for .NET Developers

Contents Snapshot

1. Understanding Entity Framework Core Performance

How EF Core Executes Queries

LINQ-to-SQL Translation

Where EF Core Performance Bottlenecks Occur

2. Common EF Core Performance Problems

Loading Unnecessary Data

Excessive Entity Tracking

The N+1 Query Problem

Better Approach

Lazy Loading

Practical Consideration

Excessive Include()

Premature Query Execution

3. Optimizing EF Core Queries

Projection with Select()

Why Projection Matters

DTO-Based Queries

AsNoTracking()

Filtering and Sorting

Avoiding Client-Side Processing

Inspecting Generated SQL

4. Managing Related Data

Include() and ThenInclude()

Eager Loading

Explicit Loading

Lazy Loading

AsSplitQuery() vs Single Queries

5. Pagination and Large Data Sets

Skip() and Take()

Keyset Pagination

When to Consider Keyset Pagination

6. Insert, Update, and Delete Performance

SaveChangesAsync()

Inefficient

Better

Batch Operations

ExecuteUpdateAsync()

ExecuteDeleteAsync()

Handling Large Data Operations

7. DbContext Performance

DbContext Lifetime

Change Tracking

Connection Management

Async Database Operations

Context Pooling

8. EF Core Performance Patterns and Anti-Patterns

Common Mistakes

Loading Everything

Returning Entities Directly From APIs

Calling SaveChangesAsync() Repeatedly

Using Lazy Loading Without Understanding Its Cost

Adding Include() Everywhere

Recommended Patterns

When to Use or Avoid Specific EF Core Features

9. Measuring and Diagnosing EF Core Performance

Logging

Generated SQL

Query Timing

Profiling

Identifying Slow Queries

10. Practical EF Core Performance Checklist

Query Checklist

Tracking Checklist

Loading Checklist

Write-Operation Checklist

Production Checklist

11. Key Takeaways

Conclusion

Tags

dotnet #csharp #efcore #entityframework #aspnetcore #performance #softwarearchitecture #programming

SOLID Principles in C#: A Practical Guide with Real-World Examples and Design Patterns

📑 Contents

What Does SOLID Mean?

SOLID Is Not the Same as Design Patterns

1. Single Responsibility Principle — SRP

The Simple Explanation

Excessive `Include()`

Projection with `Select()`

`AsNoTracking()`

`Include()` and `ThenInclude()`

`AsSplitQuery()` vs Single Queries

`Skip()` and `Take()`

`SaveChangesAsync()`

`ExecuteUpdateAsync()`

`ExecuteDeleteAsync()`

Calling `SaveChangesAsync()` Repeatedly

Adding `Include()` Everywhere