High-Throughput Microservices with .NET 10, Dapper & Clean Architecture: Scaling to 10k+ Req/Sec

The Hidden Cost of ORM Overhead at Scale

Entity Framework Core (EF Core) is undeniably one of the most productive Object-Relational Mappers in software development. For standard CRUD operations and admin portals, it saves hundreds of engineering hours. However, when building high-velocity platforms—such as payment gateways, high-frequency digital marketplaces, or real-time inventory telemetry—heavy change tracking, complex expression-tree compilations, and dynamic SQL generation create subtle performance bottlenecks.

Under traffic bursts exceeding 5,000 to 10,000 requests per second, excessive memory allocations trigger aggressive .NET Garbage Collection (GC) pauses, spiking p99 tail latencies from 15ms to over 350ms.

At DivyamStack, we employ a hybrid data architecture: utilizing EF Core for structured entity migrations and domain logic, while deploying Dapper Micro-ORM across mission-critical read/write pipelines where raw throughput is paramount.

---

Clean Architecture Without the Enterprise Bloat

Many software teams misunderstand Clean Architecture, burying simple endpoints under five abstract layers and dozens of mapping files. A high-throughput service must stay lightweight:

┌─────────────────────────────────────────────────────────┐
│                  Presentation Layer                     │
│           (ASP.NET Core 10 Minimal APIs)                │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                   Application Layer                     │
│         (MediatR / CQRS Handlers & FluentValidation)    │
└───────────────┬─────────────────────────┬───────────────┘
                │                         │
                ▼                         ▼
┌───────────────────────────────┐ ┌───────────────────────────────┐
│         Write Pipeline        │ │         Read Pipeline         │
│  (EF Core Unit of Work with   │ │  (Dapper Micro-ORM Direct     │
│   Optimistic Concurrency)     │ │   SQL Server Stored Procs)    │
└───────────────┬───────────────┘ └───────────────┬───────────────┘
                │                                 │
                └────────────────┬────────────────┘
                                 ▼
┌─────────────────────────────────────────────────────────┐
│              Microsoft SQL Server Database              │
│       (Connection Pooling, In-Memory OLTP, Indexes)     │
└─────────────────────────────────────────────────────────┘

---

High-Velocity Data Access with Dapper & Minimal APIs

Here is how we implement a sub-10ms stock reservation endpoint in .NET 10 using Minimal APIs, Dapper, and SQL Server table-valued parameters:

using System.Data;
using Dapper;
using Microsoft.Data.SqlClient;

var builder = WebApplication.CreateSlimBuilder(args);
builder.Services.AddScoped<IDbConnection>(_ => 
    new SqlConnection(builder.Configuration.GetConnectionString("DefaultConnection")));

var app = builder.Build();

// High-throughput stock reservation endpoint
app.MapPost("/api/inventory/reserve", async (
    ReserveStockRequest request, 
    IDbConnection db, 
    CancellationToken ct) =>
{
    const string sql = @"
        UPDATE Warehouses.StockItems 
        SET AvailableQuantity = AvailableQuantity - @Quantity,
            ReservedQuantity = ReservedQuantity + @Quantity,
            RowVersion = RowVersion + 1
        WHERE SkuId = @SkuId 
          AND WarehouseId = @WarehouseId 
          AND AvailableQuantity >= @Quantity;

        SELECT @@ROWCOUNT;";

    var rowsAffected = await db.ExecuteScalarAsync<int>(
        new CommandDefinition(sql, request, cancellationToken: ct));

    return rowsAffected > 0 
        ? Results.Ok(new { Success = true, Message = "Stock reserved successfully." })
        : Results.Conflict(new { Success = false, Message = "Insufficient inventory or concurrent modification." });
});

app.Run();

public record ReserveStockRequest(string SkuId, string WarehouseId, int Quantity);

Why This Architecture Excels:

1. Zero Change Tracker Allocations: Dapper maps raw database buffers directly into C# records without allocating internal tracking dictionaries.
2. Minimal APIs Engine: Eliminates MVC controller reflection and pipeline filters, allowing the ASP.NET Core Kestrel server to process HTTP requests at native hardware speeds.
3. Optimistic Version Guarding: By updating RowVersion and checking @@ROWCOUNT, we protect against concurrent race conditions without locking entire database tables.

---

Three Core Principles for Sub-25ms P99 Latency

1. Connection Pool Warming & Non-Blocking Async

Never open SQL connections synchronously. Always ensure SqlConnection instances are acquired and returned to the pool immediately using non-blocking asynchronous calls (await db.QueryAsync()).

2. Covering Indexes on Filter Columns

Ensure your SQL Server indexes contain all columns requested by high-frequency queries. By eliminating costly Key Lookups, SQL Server satisfies queries entirely within RAM cache.

3. Native AOT Compilation in .NET 10

By enabling Ahead-Of-Time (AOT) compilation in your .csproj file, .NET compiles your code into native machine instructions at build time. This slashes cold startup times to under 30 milliseconds and reduces container memory footprints by over 60%.

---

Summary

Scaling microservices to 10,000+ requests per second does not require rewriting your stack in Rust or Go. By combining the enterprise reliability of C# .NET 10, the raw query velocity of Dapper, and disciplined Clean Architecture, you can build cloud-native backends that deliver lightning-fast response times at minimal infrastructure cost.

Need to modernize your legacy .NET monolith or optimize enterprise database performance? Connect with the DivyamStack engineering team.