If you want an API that starts fast, uses less memory, and is still production-safe, this guide is for you. You will build a .NET 9 Minimal API with Native AOT for faster cold starts, a practical rate limiter to protect your backend, and OpenTelemetry traces so you can debug real issues in minutes instead of hours. By the end, you will have a deploy-ready template for modern backend services in 2026.

Why .NET 9 Minimal API is a strong choice in 2026

Teams are shipping more microservices, edge workloads, and background APIs than ever. In this environment, startup time and runtime efficiency matter. A .NET 9 Minimal API gives you a clean programming model with low overhead. Pair that with Native AOT and you can significantly reduce cold start delays. Add ASP.NET Core rate limiting and OpenTelemetry tracing, and your service is not just fast, it is resilient and observable.

If you have followed recent performance-focused posts on this blog, the same principle applies here: faster feedback and safer production behavior. For example, cache-aware builds in Docker CI can reduce iteration time dramatically (Docker CI in 2026). Reliable observability patterns also complement this API setup (Python Async API Client).

Architecture goals for this API

• Fast startup: optimize for cold starts with Native AOT.
• Controlled traffic: protect endpoints using fixed-window limits.
• Production visibility: emit traces and metrics with OpenTelemetry.
• Simple deployability: keep dependencies lean and cloud-friendly.

Step 1: Create the Minimal API project

Create a new project and add required packages:

dotnet new web -n FastApiAot
cd FastApiAot

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.OTLP
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http

Now update Program.cs with a clean baseline that includes health checks, rate limiting, and tracing:

using System.Threading.RateLimiting;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddFixedWindowLimiter("api", limiterOptions =>
    {
        limiterOptions.PermitLimit = 100;
        limiterOptions.Window = TimeSpan.FromMinutes(1);
        limiterOptions.QueueLimit = 20;
        limiterOptions.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });
});

builder.Services
    .AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("fastapi-aot"))
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddOtlpExporter();
    });

var app = builder.Build();

app.UseRateLimiter();

app.MapHealthChecks("/health");

app.MapGet("/api/time", () =>
{
    return Results.Ok(new
    {
        utc = DateTime.UtcNow,
        service = "fastapi-aot",
        version = "1.0.0"
    });
}).RequireRateLimiting("api");

app.MapGet("/api/orders/{id:guid}", (Guid id) =>
{
    // Mock payload for demo
    return Results.Ok(new
    {
        id,
        status = "processing",
        updatedAt = DateTime.UtcNow
    });
}).RequireRateLimiting("api");

app.Run();

Why this baseline works

This setup gives you immediate guardrails. Your API has a health endpoint for uptime checks, a rate limiter for burst protection, and distributed tracing for end-to-end latency analysis. If you have implemented keyset pagination APIs before, you already know predictable performance starts with predictable patterns (PostgreSQL Keyset Pagination API).

Step 2: Enable Native AOT for faster startup

Edit your .csproj file and add AOT-related properties:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>

    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
    <StripSymbols>true</StripSymbols>
  </PropertyGroup>
</Project>

Publish with:

dotnet publish -c Release -r linux-x64

Native AOT can reduce startup overhead, which is especially useful for autoscaled pods and on-demand workloads. This aligns nicely with zero-downtime deployment strategies discussed in the Kubernetes rollout guide (Argo Rollouts and SLO-Driven Rollbacks).

Step 3: Add practical production checks

Rate limiting strategy

The fixed-window policy above is a good default. For login or payment endpoints, use stricter limits and separate policies. For public read APIs, keep limits higher but monitor 429 rates. You want to block abuse without hurting normal users.

OpenTelemetry strategy

Send traces to an OTLP collector (Tempo, Jaeger, or your managed observability stack). Add service version tags per deployment. During incident triage, traces help you answer three critical questions fast: where latency started, which downstream call failed, and whether retries amplified load.

Deployment guardrails

• Keep health checks shallow (/health) and readiness checks dependency-aware.
• Use rolling or canary rollout for new versions.
• Track P95 latency, error rate, and 429 ratio on dashboards.

Common mistakes to avoid

• Skipping load tests: rate limits look fine in local testing but fail under burst traffic.
• No trace context propagation: you lose request lineage across services.
• Over-optimizing too early: start with a simple limiter and tune using real telemetry.
• Ignoring dependency behavior: your API can be fast but still fail because a downstream service is unstable.

Conclusion

A modern backend is not just about writing endpoints quickly. It is about fast startup, controlled traffic, and clear visibility when things break. A .NET 9 Minimal API with Native AOT, ASP.NET Core rate limiting, and OpenTelemetry tracing is a practical pattern you can ship today and scale confidently.

FAQ

1) Is Native AOT always better for ASP.NET Core APIs?

Not always. Native AOT is great for startup and memory-sensitive workloads, but some reflection-heavy libraries may need extra configuration. Test your specific dependency stack before committing.

2) What is a good starting rate limit for a public API?

A common baseline is 60 to 120 requests per minute per client identity, then tune with real traffic data. Watch 429 rates and user impact before tightening limits.

3) Do I need OpenTelemetry if I already have logs?

Yes, for distributed systems. Logs explain events, but traces show request flow and latency across services, which is critical during production incidents.

4) Can this approach run on Kubernetes and serverless platforms?

Yes. This pattern works well on both. Native AOT helps cold starts, and OpenTelemetry plus health checks integrate cleanly with cloud-native runtime environments.