API Gateway Patterns in ASP.NET Core with YARP: Routing, Security, and Load Balancing

As applications evolve from monoliths into microservices, clients often need to communicate with multiple backend services. A web application might call an authentication service, a product catalog, an inventory service, an order service, and a payment gateway to complete a single business operation. Exposing each service directly to clients increases complexity, duplicates security concerns, and makes the system harder to manage.

An API Gateway solves these problems by acting as a single entry point for all client requests. Instead of communicating directly with multiple services, clients send requests to the gateway, which routes them to the appropriate backend service.

ASP.NET Core developers can build high-performance API gateways using YARP (Yet Another Reverse Proxy). Developed by Microsoft, YARP is a customizable reverse proxy built on ASP.NET Core that supports routing, load balancing, authentication, transforms, and service discovery.

In this article, you'll learn how to build a production-ready API Gateway using YARP, implement routing and security, configure load balancing, and follow best practices for scalable architectures.

Why Use an API Gateway?

Challenges Without a Gateway

Consider an e-commerce application.

Web Application
      │
      ├────────► Authentication API
      │
      ├────────► Product API
      │
      ├────────► Inventory API
      │
      ├────────► Order API
      │
      └────────► Payment API

Clients must know:

Every service URL
Authentication requirements
API versions
Network topology

As services grow, maintaining these connections becomes increasingly difficult.

Introducing an API Gateway

With an API Gateway:

Client
   │
   ▼
YARP API Gateway
   │
 ┌─┴──────────────────────┐
 ▼                        ▼
Product Service      Order Service
Inventory Service    Payment Service

Clients interact with a single endpoint while the gateway handles routing and communication with backend services.

This simplifies client development and centralizes cross-cutting concerns.

Installing YARP

Add the YARP package to your project.

dotnet add package Yarp.ReverseProxy

Why Use YARP?

YARP is built on ASP.NET Core and integrates naturally with:

Dependency Injection
Configuration
Middleware
Authentication
Logging
OpenTelemetry

Unlike standalone proxy servers, YARP allows developers to customize routing logic using familiar ASP.NET Core concepts.

Configuring the Reverse Proxy

builder.Services
    .AddReverseProxy()
    .LoadFromConfig(
        builder.Configuration.GetSection("ReverseProxy"));

Enable routing.

var app = builder.Build();

app.MapReverseProxy();

Why This Configuration?

The proxy reads routing rules from configuration instead of hardcoding them into the application.

This makes route management simpler and allows configuration updates without modifying business logic.

Defining Routes

Example configuration:

{
  "ReverseProxy": {
    "Routes": {
      "products": {
        "ClusterId": "products",
        "Match": {
          "Path": "/products/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "products": {
        "Destinations": {
          "primary": {
            "Address": "https://localhost:7001/"
          }
        }
      }
    }
  }
}

Why Separate Routes and Clusters?

Routes define how incoming requests are matched.

Clusters define where matched requests should be forwarded.

This separation allows multiple routes to reuse the same backend service while keeping routing logic flexible and maintainable.

Load Balancing

A service may have multiple instances.

Gateway
   │
 ┌─┴─────────────┐
 ▼               ▼
Product API 1   Product API 2

YARP distributes requests across available destinations using configurable load-balancing strategies.

Common strategies include:

Round Robin
Least Requests
Random
Power of Two Choices

Why Load Balance?

Load balancing improves:

Scalability
Availability
Fault tolerance
Resource utilization

Traffic is distributed across multiple instances instead of overwhelming a single server.

Securing the Gateway

Authentication should typically occur at the gateway.

builder.Services
    .AddAuthentication()
    .AddJwtBearer();

Enable authentication middleware.

app.UseAuthentication();
app.UseAuthorization();

Why Authenticate at the Gateway?

Centralizing authentication provides several benefits:

Consistent security policies
Reduced duplication
Simplified backend services
Easier auditing

Backend services can focus on business logic while trusting the gateway to validate incoming requests.

Request Transforms

Gateways often modify requests before forwarding them.

Examples include:

Adding headers
Removing headers
Rewriting paths
Forwarding user identity
Injecting correlation IDs

Transforms help backend services receive consistent request formats without requiring clients to understand internal implementation details.

End-to-End Implementation

Consider an online shopping platform.

Architecture:

Customer
     │
     ▼
YARP API Gateway
     │
 ┌───┴────────────────────────┐
 ▼                            ▼
Authentication Service    Product Service
Inventory Service         Order Service
Payment Service           Notification Service

Workflow:

A customer submits a request to the API Gateway.
The gateway authenticates the request using JWT.
Routing rules determine the appropriate backend service.
Request headers are transformed as required.
The request is forwarded to the selected service instance.
Load balancing distributes requests across healthy servers.
The backend service processes the request.
The response is returned through the gateway to the client.

This architecture centralizes routing, security, and traffic management while allowing backend services to evolve independently.

API Gateway vs Reverse Proxy

Feature	Traditional Reverse Proxy	YARP API Gateway
Request Routing	Yes	Yes
Load Balancing	Yes	Yes
Authentication Integration	Limited	Excellent
Request Transforms	Limited	Yes
ASP.NET Core Integration	No	Native
Custom Middleware	No	Yes

While both solutions forward requests, YARP provides deeper integration with the ASP.NET Core ecosystem, making it well suited for modern .NET applications.

Best Practices

Keep the gateway lightweight.
Centralize authentication and authorization.
Avoid implementing business logic in the gateway.
Enable structured logging and distributed tracing.
Configure health checks for backend services.
Use HTTPS for all client and service communication.
Monitor latency and request failures.
Apply rate limiting at the gateway.
Version APIs without exposing internal service topology.

Common Mistakes

One common mistake is placing business logic inside the API Gateway. The gateway should focus on routing, security, and cross-cutting concerns rather than implementing domain-specific functionality.

Another issue is exposing internal service URLs to clients. Clients should communicate only with the gateway, allowing backend services to change without affecting external consumers.

Developers also sometimes neglect monitoring gateway performance. Since all traffic flows through the gateway, it can become a bottleneck if resource utilization and request latency are not continuously monitored.

Testing and Validation

Before deploying an API Gateway, verify the following:

Route matching
Authentication and authorization
Load balancing behavior
Header transformations
Backend service failures
Health check integration
High-concurrency traffic
End-to-end routing validation

Testing should include both successful request flows and failure scenarios to ensure the gateway behaves predictably under production conditions.

Performance Considerations

The gateway processes every incoming request, making efficiency critical.

Consider these recommendations:

Keep middleware lightweight.
Enable response compression where appropriate.
Reuse HttpClient connections.
Monitor gateway latency.
Configure efficient load-balancing strategies.
Scale gateway instances independently of backend services.

A well-configured gateway adds minimal overhead while significantly improving overall system manageability.

Security Considerations

The API Gateway is a critical security boundary.

Follow these recommendations:

Enforce authentication before routing requests.
Apply authorization policies consistently.
Enable rate limiting to prevent abuse.
Validate incoming requests.
Protect backend services from direct public access.
Log security events for auditing.
Use HTTPS throughout the communication pipeline.
Monitor unusual traffic patterns.

Centralizing security at the gateway simplifies policy enforcement while reducing duplication across backend services.

Troubleshooting

Requests Return 404 Errors

Verify that route patterns match the incoming request path and that the corresponding cluster is configured correctly.

Backend Service Is Unreachable

Confirm destination addresses are correct and that backend services are healthy and accepting requests.

Authentication Fails

Review JWT configuration, token validation settings, and middleware ordering to ensure authentication executes before request routing.

Uneven Traffic Distribution

Check the configured load-balancing strategy and verify that all backend service instances are healthy and available.

Conclusion

An API Gateway is a foundational component of modern distributed applications, providing a single entry point for routing, security, load balancing, and traffic management. With YARP, ASP.NET Core developers can build highly customizable gateways that integrate seamlessly with the existing middleware pipeline while remaining lightweight and high-performing. By keeping the gateway focused on cross-cutting concerns and allowing backend services to handle business logic, organizations can build scalable, maintainable, and secure microservice architectures.