Understanding ASP.NET Core Middleware: How the Pipeline Really Works

Why Middleware Is Where ASP.NET Core Actually Makes Sense

If you’ve spent any real time with ASP.NET Core, you’ve probably noticed something interesting: almost everything important happens before your controller ever runs.

Authentication, authorization, routing, exception handling, logging, performance tracking — all of it lives in middleware.

That’s why I tend to say this:

If you understand middleware, you understand how ASP.NET Core really works.

Not in theory. In practice.

What Is Middleware, Really?

At its core, middleware is just a component that:

• receives an HTTP request
• optionally does some work
• decides whether to pass the request down the pipeline
• optionally processes the response on the way back out

Each middleware component knows about only two things:

1. the current HttpContext
2. the next delegate in the pipeline

That simplicity is intentional — and it’s why the pipeline model scales so well.

One important detail that trips people up early:

Middleware executes in the order it’s registered, and responses flow back in reverse order.

That single fact explains about 80% of “why isn’t this working?” bugs I’ve debugged.

The ASP.NET Core Request–Response Pipeline

Think of the pipeline as a chain:

Request → [ Middleware A ] → [ Middleware B ] → [ Middleware C ] → Endpoint ← Response

Each middleware can:

• continue the pipeline
• short-circuit it
• modify the request
• modify the response

Once you internalize that mental model, middleware stops feeling magical and starts feeling predictable.

---

Built-in Middleware You’re Already Using

Even if you’ve never written custom middleware, you’re using it every day.

Some of the most common built-in components include:

• Routing – matches requests to endpoints
• Authentication – establishes identity
• Authorization – enforces access rules
• Static Files – serves files without hitting MVC
• Exception Handling – catches and formats unhandled errors

What matters is where they’re registered.

For example:

• authentication must run before authorization
• exception handling should be near the start of the pipeline

Order isn’t a detail here — it’s the design.

---

Writing Custom Middleware (The Right Way)

Custom middleware is where ASP.NET Core really shines.

Common use cases include:

• request/response logging
• correlation IDs
• validation
• security headers
• performance and latency tracking

A basic middleware looks like this:

public class RequestLoggingMiddleware
{
    private readonly RequestDelegate _next;

    public RequestLoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Before
        Console.WriteLine($"Incoming request: {context.Request.Path}");

        await _next(context);

        // After
        Console.WriteLine($"Response status: {context.Response.StatusCode}");
    }
}

A few things worth calling out:

• middleware should be async
• it should do the minimum work necessary
• heavy logic belongs elsewhere (services, not middleware)

In my experience, middleware works best when it’s thin and intentional.

---

Registering Middleware: Use, Run, and Branching

How you register middleware determines how the pipeline behaves.

Use

• continues the pipeline
• most common option

app.Use(async (context, next) =>
{
    // do something
    await next();
});

Run

• ends the pipeline
• no next

app.Run(context =>
{
    return context.Response.WriteAsync("Terminal middleware");
});

Map and UseWhen

• conditionally branch the pipeline

app.UseWhen(ctx => ctx.Request.Path.StartsWithSegments("/admin"), branch =>
{
    branch.UseMiddleware<AdminOnlyMiddleware>();
});

Branching is powerful — but easy to abuse. Keep branches shallow and obvious.

---

Middleware vs Filters (Interview Favorite)

This comes up constantly in interviews, and the distinction matters.

Middleware:

• runs for every request (unless branched)
• unaware of MVC
• ideal for cross-cutting concerns

Filters:

• run inside MVC
• aware of controllers and actions
• ideal for request-level behavior

If it needs to run before routing, it must be middleware.

---

Dependency Injection in Middleware

Middleware supports DI, but there’s a nuance:

• constructor injection uses singleton lifetime
• scoped services must be resolved inside InvokeAsync

public async Task InvokeAsync(HttpContext context, IMyScopedService service)
{
    await _next(context);
}

Getting this wrong can cause subtle bugs, especially under load.

---

Global Error Handling Done Right

A single, well-placed exception-handling middleware can replace dozens of try/catch blocks.

Key rules:

• register it early
• log once, consistently
• return predictable error responses

This is one of the highest ROI middleware investments you can make.

---

Performance and Async Best Practices

A few hard-earned lessons:

• always await next()
• never block threads
• avoid synchronous I/O
• keep allocations low

Middleware runs on every request. Small inefficiencies add up fast.

---

Closing Thoughts

Middleware is not just an implementation detail in ASP.NET Core.

It’s the backbone of the framework.

Once you truly understand the request pipeline — how middleware executes, how order affects behavior, and where responsibilities belong — ASP.NET Core stops feeling mysterious and starts feeling deliberate.

And that’s when you stop fighting the framework and start working with it.