How I Improved API Throughput by 326 and Reduced Latency by 99.7% in a .NET Backend

Shane Htet Aung — Wed, 29 Apr 2026 12:24:27 +0000

When I seeded my backend with 600,000 car records and 1,000,000 posts to simulate real traffic, my API nearly fell over. 54% of requests were failing. The p95 latency on the car listing endpoint was 30 seconds. Throughput was sitting at a painful 2 req/s.

Eight weeks later: 807 req/s, 79ms p95 latency, 0.26% error rate.

This is the story of how I got there.

What I Was Building

GearUp is a Facebook Marketplace-style platform for cars. The feature set is fairly complex:

KYC verification flow — users upload passport/national ID documents, admins review and approve them, which upgrades a user's role to "Dealer"
Car listings — dealers upload VINs, license plates, and car details for admin approval
Posts & social feed — dealers advertise their approved cars through posts; customers browse, like, and leave nested comments
Appointment booking — customers schedule viewings with dealers
Reviews — customers rate dealers after a visit
Admin dashboard — for managing KYC approvals, car approvals, and platform oversight

The stack: ASP.NET Core, PostgreSQL, EF Core, Redis, Docker, Clean Architecture.

The two endpoints that mattered most for scale were /api/v1/cars and /api/v1/feed — high-read, high-data endpoints that every user hits constantly.

The Baseline: It Was Bad

I used k6 to load test with 100 Virtual Users (VUs) in a staged ramp pattern to simulate realistic traffic.

Here's what I saw before any optimization:

Endpoint	Throughput	p95 Latency	Error Rate
`GET /cars`	~2 req/s	~30s	54.68% (759/1388 requests failed)
`GET /feed`	~2.47 req/s	~22.86s	High

PostgreSQL was throwing connection timeout errors. The database couldn't keep up.

The k6 output was brutal:

http_req_failed: 54.68% — 759 out of 1388

Over half of requests were just dying. This wasn't a slow API — it was a broken one under any meaningful load.

Diagnosing the Problems

I started by reading the actual query logs and EF Core output. Three categories of problems emerged immediately.

1. N+1 Queries Everywhere

The feed endpoint was loading posts, then for each post making a separate query to fetch the associated car, another to fetch the author, another to fetch like counts. With 1M posts, that meant the DB was getting hammered with thousands of round trips per single API call.

EF Core makes this easy to accidentally do:

// This looks innocent but fires N+1 queries
var posts = await _context.Posts.ToListAsync();
foreach (var post in posts)
{
    var car = await _context.Cars.FindAsync(post.CarId); // ← separate query per post
}

2. No Indexes on Frequently Filtered Columns

The cars table had 600K rows. Queries were filtering by make, model, year, status, and sorting by created_at — none of which had indexes. Every query was doing a full sequential scan across 600K rows.

Same for the posts table. No index on dealer_id, car_id, or created_at.

3. Returning Everything

The queries were pulling entire entity objects including columns that the API response never used — large text fields, metadata, internal flags. This meant more data travelling from DB → app server on every request, for no reason.

The Fixes

Fix 1: Eliminate N+1 with Projection Queries

Instead of loading entities and navigating relationships lazily, I switched to projection-based queries — writing the shape of the response directly in the query using Select().

const int pageSize = 10;

            IQueryable<Post> query = _db.Posts.AsNoTracking().Where(p => !p.IsDeleted && p.Visibility == PostVisibility.Public)
                .OrderByDescending(p => p.CreatedAt).ThenByDescending(p => p.Id);

            if (c is not null)
            {
                query = query.Where(p => p.CreatedAt < c.CreatedAt || (p.CreatedAt == c.CreatedAt && p.Id.CompareTo(c.Id) < 0) ) ;
            }

            var posts = await query
                .Take(pageSize + 1)
                .Select(p => new PostProjection
                {
                    Id = p.Id,
                    Caption = p.Caption,
                    Content = p.Content,
                    Visibility = p.Visibility,
                    UserId = p.UserId,
                    CarId = p.CarId,
                    CreatedAt = p.CreatedAt,
                    UpdatedAt = p.UpdatedAt,
                    LikeCount = p.LikeCount,
                    CommentCount = p.CommentCount,
                    ViewCount = p.ViewCount
                })
                .ToListAsync(cancellationToken);

This collapses what was dozens of queries into one SQL statement with joins and aggregation done at the database level.

Fix 2: Add Targeted Indexes

I added indexes on every column used in WHERE, ORDER BY, and JOIN conditions:

-- Cars table
   builder.HasIndex(c => new
            {
                c.IsDeleted,
                c.ValidationStatus,
                c.Status,
                c.CreatedAt,
                c.Id
            });

            builder.HasIndex(c => new
            {
                c.DealerId,
                c.IsDeleted,
                c.ValidationStatus,
                c.CreatedAt,
                c.Id
            });

            builder.HasIndex(c => new
            {
                c.IsDeleted,
                c.ValidationStatus,
                c.Status,
                c.Color,
                c.CreatedAt,
                c.Id
            });

            builder.HasIndex(c => c.VIN).IsUnique();
            builder.HasIndex(c => new
            {
                c.ValidationStatus,
                c.Status,
                c.Price,
                c.CreatedAt,
                c.Id
            });

-- Posts table  
 builder.HasIndex(p => new { p.IsDeleted, p.Visibility, p.CreatedAt, p.Id });
            builder.HasIndex(p => new { p.IsDeleted, p.UserId, p.CreatedAt, p.Id });

The composite index on (status, created_at DESC) was particularly impactful for the feed query, which always filters active posts sorted by recency.

Fix 3: Redis Caching for Hot Data

The car listings endpoint was heavily read-heavy — most users are browsing, not posting. I added Redis caching for paginated car results and feed pages with a short TTL:

 var cacheKey = await BuildCarCacheKeyAsync("all", Guid.Empty, cursorString);
            var cachedCars = await _cacheService.GetAsync<CursorPageResult<CarListDto>>(cacheKey);
            if (cachedCars != null)
            {
                return Result<CursorPageResult<CarListDto>>.Success(cachedCars, "Cars fetched successfully", 200);
            }

            var cars = await _carRepository.GetAllCarsAsync(cursor, cancellationToken);
            await _cacheService.SetAsync(cacheKey, cars, CarListCacheTtl);

For a marketplace where listings don't change every second, 30 seconds of cache is perfectly acceptable and dramatically reduces DB load.

Fix 4: Cursor-Based Pagination Instead of OFFSET

This one is subtle but important at scale.

Most APIs default to offset pagination: SKIP 50000 TAKE 20. It feels intuitive, but under the hood PostgreSQL still has to scan and discard the first 50,000 rows to get to the ones you want. At 600K records, deep pages become progressively slower — and with concurrent users all paginating at different offsets, it compounds fast.

I switched to cursor-based pagination, where instead of a page number you pass a cursor pointing to the last item you saw. The query then uses a WHERE clause to start from that exact position:

if (cursor is not null)
{
    query = query.Where(c => c.CreatedAt < cursor.CreatedAt ||
        (c.CreatedAt == cursor.CreatedAt && c.Id.CompareTo(cursor.Id) < 0));
}

This is an index seek, not a scan — PostgreSQL jumps directly to the right position regardless of how deep into the dataset you are. Page 1 and page 10,000 have identical performance.

The cursor itself is a base64-encoded JSON object carrying the sort values needed to resume the query:

public sealed class Cursor
{
    public DateTime CreatedAt { get; init; }
    public Guid Id { get; init; }
    public double? Price { get; init; }

    public static string Encode(Cursor c)
    {
        string json = JsonSerializer.Serialize(c);
        byte[] jsonByte = Encoding.UTF8.GetBytes(json);
        return Convert.ToBase64String(jsonByte);
    }

    public static bool TryDecode(string encodedCursor, out Cursor? result)
    {
        result = null;
        if (string.IsNullOrEmpty(encodedCursor)) return false;
        try
        {
            var bytes = Convert.FromBase64String(encodedCursor);
            var json = Encoding.UTF8.GetString(bytes);
            result = JsonSerializer.Deserialize<Cursor>(json);
            return result != null;
        }
        catch (FormatException) { return false; }
        catch (JsonException) { return false; }
    }
}

The response returns a NextCursor string the client passes back on the next request — clean, stateless, and scales to any dataset size:

return new CursorPageResult<CarListDto>
{
    Items = cars.Take(PageSize).ToList(),
    NextCursor = nextCursor,
    HasMore = hasMore
};

The tradeoff: you lose the ability to jump to an arbitrary page number. For a feed or infinite-scroll car listing, that's a non-issue — and the performance gain is worth it.

Fix 5: EF Core Connection Pooling + Retry Policies

The connection timeout issue was partly from EF Core creating too many connections. I configured AddDbContextPool with retry-on-failure:

  services.AddDbContextPool<GearUpDbContext>(
                options =>
                    options.UseNpgsql(
                        connectionString,
                        npgsqlOptions =>
                        {
                            npgsqlOptions.EnableRetryOnFailure(
                                maxRetryCount: MaxRetryCount,
                                maxRetryDelay: MaxRetryDelay,
                                errorCodesToAdd: null);
                            npgsqlOptions.CommandTimeout(DbCommandTimeoutSeconds);
                        }),
                poolSize: DbContextPoolSize);

The Results

After applying all four fixes and re-running the same k6 load tests (100 VUs, same staged ramp pattern):

Endpoint	Before	After	Improvement
`GET /cars` throughput	2 req/s	807 req/s	326×
`GET /cars` p95 latency	30s	79ms	99.7% reduction
`GET /cars` error rate	54.68%	0.26%	Near zero
`GET /feed` throughput	2.47 req/s	200 req/s	~80×
`GET /feed` p95 latency	22.86s	150ms	99.3% reduction
`GET /feed` max latency	—	300ms	Stable under load

The PostgreSQL connection timeout errors disappeared entirely. The API went from collapsing under 100 users to handling the load comfortably with headroom to spare.

What I Learned

1. Measure before you optimize. I could have guessed the problem was "slow queries" and spent days tweaking things randomly. k6 with staged traffic patterns showed me exactly where the breaking point was and what the error looked like at scale.

2. N+1 is the most common silent killer. EF Core's lazy loading makes it trivially easy to write code that looks clean but fires hundreds of DB queries per request. Projection queries should be the default for any read endpoint serving lists.

3. Indexes are free performance. Adding the right indexes to a 600K row table took minutes and gave enormous gains. If you haven't checked your query plans on large tables, do it now.

4. Cache what changes slowly. Not everything needs to be real-time. Car listings that update a few times a day can be cached for 30 seconds without anyone noticing — and it cuts DB load dramatically.

5. Load test with realistic data. Testing with 100 rows in dev and 600K rows in production is how you get surprised. Seed your local/staging environment to production-like scale early.

The Stack

For reference, the full tech stack behind GearUp:

Runtime: ASP.NET Core (.NET 9)
ORM: EF Core with PostgreSQL (Npgsql)
Caching: Redis
Load Testing: k6
Observability: OpenTelemetry + Serilog
Infrastructure: Docker Compose, Render
Architecture: Clean Architecture (Domain / Application / Infrastructure / Presentation)

The full source is on GitHub if you want to dig into the implementation: github.com/Rahull-Adk/GearUp

I'm Shane, a backend engineer specializing in high-performance .NET systems. Currently studying Computer Science at Assumption University of Thailand. Find me on LinkedIn.

DEV Community: Shane Htet Aung