The .NET/C# Ecosystem for Distributed Systems: A Brownfield Manager's Reference

C# and .NET are frequently conflated, but they serve fundamentally different roles. Understanding this distinction is critical when reasoning about what you can change, what you can optimize, and what constraints your platform imposes — especially when managing a large brownfield distributed application where decades of technical decisions have accumulated.

This post provides a system-level reference for engineers who need to understand the .NET ecosystem at a platform level: the language features, runtime capabilities, framework primitives, and modern tooling that make .NET a competitive choice for microservices, event-driven architectures, and cloud-native deployments — with particular attention to how AI-assisted, spec-driven development methodologies reshape the maintenance and evolution of existing .NET codebases.

C# vs .NET: Understanding the Distinction and Interplay

C# is the Language

C# is a statically-typed, multi-paradigm programming language developed by Microsoft. It compiles to an intermediate representation (IL/MSIL) that runs on the Common Language Runtime (CLR). C# provides:

• Type system: Classes, structs, interfaces, generics, nullable reference types, records, and unions (C# 13+)
• Concurrency model: async/await, ValueTask, channels, and structured concurrency
• Metaprogramming: Attributes, source generators, reflection, and expression trees
• Pattern matching: Property patterns, recursive patterns, relational patterns, and list patterns

C# evolves independently of the runtime. You can target C# 12 features against .NET 8, for instance — the language version and runtime version are decoupled.

.NET is the Platform

.NET is the runtime and standard library. It provides:

• The CLR: The Common Language Runtime manages memory (garbage collection), just-in-time (JIT) compilation via RyuJIT, security, exception handling, and threading
• The Base Class Library (BCL): System.* namespaces providing collections, I/O, networking, cryptography, XML/JSON, threading primitives, and more
• SDK tooling: dotnet CLI for building, testing, publishing, and debugging
• Framework libraries: ASP.NET Core, Entity Framework Core, gRPC, SignalR, ML.NET, and others

Since .NET Core (launched 2016), .NET has been open-source (MIT license, hosted on GitHub), cross-platform (Windows, Linux, macOS, ARM), and unified — .NET Framework, .NET Core, and Xamarin/Mono merged into a single platform starting with .NET 5.

The Interplay

When you write async Task<IActionResult> GetItems(), C# handles the async/await state machine generation, while ASP.NET Core (a .NET framework library) provides IActionResult and the HTTP middleware pipeline. The CLR manages the thread pool, the JIT compiler optimizes the hot path, and the garbage collector handles the memory allocations. You are always working with both simultaneously.

For distributed systems, this means:

• Language features (C#) give you expressive, safe ways to write concurrent and asynchronous code
• Runtime capabilities (.NET) give you performance, reliability, and cross-platform deployment
• Framework libraries (.NET) give you battle-tested distributed systems primitives you can compose

C# Language Features for Distributed Systems

Async/Await and the Concurrency Model

C#'s async/await is the cornerstone of non-blocking I/O in distributed systems. Under the hood, the compiler transforms async methods into state machines (implementing IAsyncStateMachine), enabling non-blocking operations without thread-per-request overhead.

// Compiler generates a state machine that yields control
// to the thread pool while awaiting I/O
public async Task<Order> GetOrderAsync(int orderId)
{
    var order = await _orderRepository.GetByIdAsync(orderId);
    var items = await _itemService.GetItemsAsync(order.Id);
    return order with { Items = items };
}

Key aspects for distributed systems:

• ValueTask<T> (introduced in .NET Core 2.1): Avoids heap allocation when the result is already available synchronously. Critical in high-throughput service-to-service calls where the cache hit rate is significant.
• ConfigureAwait(false): In library code, avoids capturing and restoring the SynchronizationContext, reducing overhead and preventing deadlocks.
• IAsyncEnumerable<T>: Enables streaming/pipelining of results across service boundaries without buffering entire collections in memory.
• Channel<T> (.NET Core 2.1+): Lock-free, async producer/consumer queues ideal for event processing pipelines and back-pressure scenarios.

// Lock-free async channel for event processing
var channel = Channel.CreateBounded<OrderEvent>(new BoundedChannelOptions(1000)
{
    FullMode = BoundedChannelFullMode.Wait
});

// Producer
await channel.Writer.WriteAsync(event);

// Consumer
await foreach (var evt in channel.Reader.ReadAllAsync())
{
    await ProcessEvent(evt);
}

Structured Concurrency (C# 13 / .NET 10): TaskGroup and TaskScope provide cancellation propagation, exception aggregation, and lifecycle management for concurrent operations — eliminating common async bugs like fire-and-forget tasks and orphaned operations.

Pattern Matching

Pattern matching enables expressive, type-safe routing and transformation of data — essential in distributed systems where you receive varied payloads from multiple services.

// C# 12+ recursive patterns for message routing
return message switch
{
    { Type: "OrderCreated", Payload: { OrderId: > 0 } order }
        => HandleOrderCreated(order),
    { Type: "PaymentReceived", Payload: { Amount: > 0m } payment }
        => HandlePayment(payment),
    { Type: "InventoryReserved", Payload: var inventory }
        when inventory.Quantity > 0
        => HandleInventoryReserved(inventory),
    _ => LogAndDiscard(message)
};

Records and Immutable Data

Records provide value-based equality and immutability by default — ideal for DTOs, domain events, and message contracts in distributed systems.

// Immutable DTO with value equality
public record OrderCreated(
    Guid OrderId,
    string CustomerId,
    decimal Total,
    DateTimeOffset OccurredAt);

// Non-destructive mutation — creates a new instance
var updated = order with { Total = newTotal };

For distributed systems, records reduce bugs caused by shared mutable state and make serialization/deserialization predictable.

Primary Constructors (C# 12)

Primary constructors reduce boilerplate in classes and records, making service classes and DTOs more concise:

public class OrderService(
    IOrderRepository repository,
    IPaymentClient paymentClient,
    ILogger<OrderService> logger)
{
    public async Task<Order> CreateOrder(CreateOrderRequest request)
    {
        // Uses injected dependencies directly
        var order = await repository.CreateAsync(request);
        await paymentClient.AuthorizeAsync(order.Id, order.Total);
        return order;
    }
}

This is particularly valuable in brownfield projects where AI-assisted refactoring can systematically convert constructor injection boilerplate.

Nullable Reference Types

Introduced in C# 8, nullable reference types (string? vs string) are enforced at compile time. In distributed systems, this prevents entire classes of null-reference bugs at service boundaries where data contracts define what fields are required vs optional.

The .NET Runtime (CLR): What It Provides

Memory Management and Garbage Collection

The CLR's garbage collector is generational with three generations (Gen 0, 1, 2) and a Large Object Heap (LOH). For distributed systems:

• Gen 0: Short-lived objects (request-scoped allocations). Collected frequently, very fast.
• Gen 1: Buffer between Gen 0 and Gen 2. Rarely promoted beyond this point.
• Gen 2: Long-lived objects (cached data, singleton services). Collected infrequently, expensive.
• LOH: Objects > 85,000 bytes. Not compacted by default (though .NET 7+ can compact LOH).

Server GC mode (enabled by default for ASP.NET Core) uses one GC thread per CPU core, parallelizing collections for throughput-oriented server workloads.

Adaptive GC (.NET 9+): The runtime dynamically adjusts GC behavior based on workload patterns, reducing pause times under variable load — critical for microservices experiencing bursty traffic.

JIT Compilation (RyuJIT)

.NET uses Just-In-Time (JIT) compilation via RyuJIT, which compiles IL to native machine code at runtime. Key optimizations:

• Tiered Compilation: Methods are first compiled with a fast, conservative JIT (tier 0), then recompiled with aggressive optimizations (tier 1) after profiling data is collected. This reduces cold-start time while maintaining peak performance.
• Method Inlining: Eliminates call overhead for small, frequently-called methods.
• Devirtualization: When the runtime can determine the exact type at call site, virtual calls become direct calls.
• SIMD Vectorization: Auto-vectorization of loops operating on numeric arrays.

Native AOT (Ahead-of-Time Compilation)

Introduced in .NET 7 and significantly improved through .NET 10, Native AOT compiles .NET assemblies to native machine code at build time, eliminating the JIT entirely.

Benefits for distributed systems:

• Faster cold starts: Critical for serverless and container autoscaling scenarios
• Smaller memory footprint: No JIT compiler, no IL — just native code
• Smaller container images: No runtime DLLs needed in the image
• Predictable performance: No JIT compilation pauses during runtime

.NET 10 has significantly expanded Native AOT compatibility, with ASP.NET Core, EF Core, and most major libraries now AOT-compatible. For microservices where cold-start time and memory efficiency matter, this is transformative.

ASP.NET Core: The Web Services Framework

ASP.NET Core is the primary framework for building HTTP services in .NET. It is a complete rewrite of ASP.NET, designed from the ground up for cross-platform, high-performance web development.

The Middleware Pipeline

ASP.NET Core uses a middleware pipeline — a series of delegates that process requests and responses in order:

var builder = WebApplication.CreateBuilder(args);

// Middleware is added in order, executed in the same order for requests,
// and reverse order for responses
builder.Services.AddRouting();
builder.Services.AddAuthentication();
builder.Services.AddAuthorization();

var app = builder.Build();

app.UseHttpsRedirection();
app.UseSerilogRequestLogging();  // Custom logging middleware
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();            // Minimal API routing
app.Run();

For distributed systems, middleware is where you implement distributed tracing (OpenTelemetry integration), request/response logging and correlation, rate limiting and circuit breaking, CORS and security headers, and health checks (/health endpoints for Kubernetes liveness/readiness).

Built-in Support for Distributed Systems Patterns

• Health Checks (Microsoft.Extensions.Diagnostics.HealthChecks): Built-in health check system with custom checks for dependencies (databases, message brokers, downstream services). Integrates with Kubernetes probes.
• Rate Limiting (.NET 7+): Built-in rate limiting middleware with fixed window, sliding window, and token bucket algorithms.
• Background Services (IHostedService): Long-running background tasks integrated with the application lifecycle.
• SignalR: Real-time bidirectional communication for push notifications and live updates.
• OpenAPI/Swagger: Automatic API documentation generation.

Entity Framework Core: Data Access for Distributed Systems

EF Core is .NET's primary ORM, providing LINQ-based queries, change tracking, and migrations. For distributed systems, understanding its capabilities and limitations is essential.

Distributed Systems Considerations

DbContext Lifetime: In ASP.NET Core, DbContext should be registered as Scoped (per-request). Using it as Singleton causes concurrency issues; using it as Transient loses change-tracking benefits.

builder.Services.AddDbContext<OrderContext>(options =>
    options.UseSqlServer(connectionString, sql =>
        sql.EnableRetryOnFailure(  // Built-in resilience
            maxRetryCount: 5,
            maxRetryDelay: TimeSpan.FromSeconds(30),
            errorNumbersToAdd: null)));

Query Optimization:

• .AsNoTracking() for read-only queries (avoids change-tracking overhead)
• .AsSplitQuery() for complex joins (prevents Cartesian explosion)
• Compiled queries for frequently-executed queries (caches the expression tree translation)

// Compiled query — translates expression tree once, reuses the plan
static readonly Func<OrderContext, int, Task<Order?>> GetOrder =
    EF.CompileAsyncQuery<OrderContext, int, Order?>(
        (ctx, id) => ctx.Orders
            .Include(o => o.Items)
            .FirstOrDefault(o => o.Id == id));

Microservices and Database-per-Service: EF Core supports the database-per-service pattern recommended in microservices architecture. Each service has its own DbContext and database, preventing cross-service data coupling.

.NET Distributed Systems Primitives

gRPC

gRPC is a high-performance RPC framework built on HTTP/2 and Protocol Buffers. .NET has first-class gRPC support via Grpc.AspNetCore and Grpc.Net.Client.

gRPC in .NET provides strong typing (C# classes generated from .proto files), streaming (unary, server-streaming, client-streaming, and bidirectional), interoperability with any gRPC-compatible language, and performance (binary serialization via Protobuf is faster and smaller than JSON).

For brownfield systems, gRPC is ideal for internal service-to-service communication where latency and throughput matter. Use REST/HTTP for external-facing APIs.

SignalR

SignalR provides real-time, bidirectional communication between servers and clients. Built on WebSockets with automatic fallback to Server-Sent Events and Long Polling. Use cases include real-time dashboards and monitoring, live notifications across services, collaborative features, and event-driven UI updates.

HttpClient and Resilience

.NET's IHttpClientFactory (with Microsoft.Extensions.Http) provides managed HttpClient instances with built-in lifecycle management. Combined with Microsoft.Extensions.Resilience (Polly-based), you get retry policies with exponential backoff and jitter, circuit breakers to prevent cascading failures, timeout policies to prevent hanging requests, and bulkhead isolation to limit concurrent calls to downstream services.

builder.Services.AddResilientHttpClient("order-service", resilienceBuilder =>
{
    resilienceBuilder
        .AddRetry(new HttpRetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            Delay = TimeSpan.FromSeconds(1)
        })
        .AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
        {
            HandledEventsStatusCode = HttpStatusCode.InternalServerError,
            SamplingDuration = TimeSpan.FromSeconds(30),
            FailureRatio = 0.5
        })
        .AddTimeout(TimeSpan.FromSeconds(10));
});

Built-in DI, Configuration, and Logging

Dependency Injection

.NET has a built-in DI container (Microsoft.Extensions.DependencyInjection). It supports service lifetimes (Transient, Scoped, Singleton), constructor injection, factory methods, and open generics.

For brownfield projects, the built-in container handles most scenarios. For advanced features (property injection, named instances, decorator patterns), third-party containers like Autofac, DryIoc, or Microsoft.Extensions.DependencyInjection.Decorator integrate seamlessly via IServiceProviderFactory.

Configuration

.NET's configuration system (Microsoft.Extensions.Configuration) is provider-based and hierarchical. Supported providers: JSON files, XML files, environment variables, command-line arguments, Azure Key Vault, Consul, etcd, user secrets (development), and more.

For distributed systems, configuration should support environment-specific overrides, secret management, hot-reload for runtime configuration updates, and centralized configuration for multi-instance deployments.

Logging

.NET's logging abstraction (Microsoft.Extensions.Logging) provides a structured, provider-based logging system with structured logging ({PropertyName} placeholders enable queryable log fields), multiple providers (Console, Debug, EventLog, Azure App Insights, Serilog, NLog), log levels (Trace through Critical), filtering, and Activity.Current integration for distributed tracing.

For brownfield systems, migrating from raw Console.WriteLine or custom logging to structured logging is a high-value modernization step — it enables observability, alerting, and debugging at scale.

Container Support and Docker/Kubernetes Integration

Docker

.NET has first-class Docker support. The dotnet SDK includes Docker-related templates and the .NET runtime is available as official Docker images.

# Multi-stage build for production images
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src
COPY ["OrderService/OrderService.csproj", "OrderService/"]
RUN dotnet restore "OrderService/OrderService.csproj"
COPY . .
WORKDIR "/src/OrderService"
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "OrderService.dll"]

.NET 8+ supports multi-arch images (AMD64, ARM64) out of the box, enabling deployment to both x86 and ARM-based cloud infrastructure.

Native AOT Container Images

With Native AOT, .NET container images can be extremely small — a scratch-based image with a Native AOT .NET app can be under 30MB, compared to 200MB+ for a standard .NET container. This matters in Kubernetes where you scale to hundreds of pods.

.NET Aspire

.NET Aspire (formerly Project Marble) is Microsoft's cloud-native application stack for building observable, production-ready distributed applications. It provides a local development dashboard for distributed apps, resource orchestration for containers/databases/services, built-in integrations (Redis, PostgreSQL, RabbitMQ, Service Bus), distributed tracing via OpenTelemetry, and service discovery.

For brownfield projects, Aspire provides a structured migration path — you can gradually wrap existing services in Aspire's orchestration layer.

.NET 8/9/10: Modern Features for Distributed Systems

.NET 8 (LTS, November 2023)

• Native AOT improvements: Better compatibility with ASP.NET Core and EF Core
• Performance: Up to 2x faster LINQ, improved JIT optimizations, smaller binary sizes
• Collections: CollectionsMarshal for low-level collection manipulation
• Observability: OpenTelemetry integration in the base libraries

.NET 9 (STS, November 2024)

• Adaptive GC: Runtime dynamically adjusts GC behavior based on workload
• Improved SIMD: Better auto-vectorization and hardware intrinsics
• System.Linq.AsyncEnumerable: Async LINQ in the BCL (no more third-party dependency)
• AI integrations: Extensions.AI namespace for AI service abstractions

.NET 10 (LTS, November 2025)

• Native AOT maturity: Near-complete framework compatibility, including ASP.NET Core and EF Core
• Structured Concurrency: TaskGroup and TaskScope for safe concurrent programming
• C# 13: List patterns, improved pattern matching, ref fields, and more
• Cloud-native: Enhanced Kubernetes and service mesh integration
• AI-native: Deeper AI integration with Extensions.AI and ML.NET 3.0

The LTS/STS release cadence means .NET 8 and .NET 10 are the target runtimes for production distributed systems, with .NET 9 available for teams wanting the latest features.

Microsoft's Microservices Architecture Guide

Microsoft publishes a comprehensive Microservices Architecture Guide with a reference implementation called eShop. This is the definitive resource for .NET microservices patterns.

Key Architectural Patterns

• Bounded Contexts and Domain-Driven Design: Each microservice owns a bounded context with its own domain model, database, and API. The eShop reference implements this with services like Catalog, Basket, Ordering, and Identity.
• CQRS (Command Query Responsibility Segregation): Separates read and write operations. The eShop reference uses EF Core for writes (commands) and read-optimized queries for reads.
• Eventual Consistency: Services communicate through events rather than synchronous calls for cross-service operations.
• API Gateway: A single entry point for client requests, handling routing, composition, and cross-cutting concerns. Implemented with YARP (Yet Another Reverse Proxy) in .NET.
• Resilience Patterns: Circuit breaker, retry with exponential backoff, bulkhead isolation, and timeout policies.
• Distributed Tracing: OpenTelemetry integration provides end-to-end request tracing across service boundaries.

eShop Reference Application

The eShop repository is a production-quality reference implementation demonstrating multiple microservices communicating via gRPC and HTTP, event-driven architecture with message brokers, Docker and Kubernetes deployment, CI/CD pipelines, observability (tracing, metrics, logging), AuthN/AuthZ with IdentityServer, and shopping cart, catalog, ordering, and payment flows.

For brownfield projects, eShop serves as a pattern library — you don't copy it wholesale, but you extract the patterns that fit your context.

Brownfield Context: AI-Assisted, Spec-Driven Development

The Brownfield Challenge

Large existing .NET distributed applications face specific challenges:

• Technical debt: Accumulated over years of development
• Framework version fragmentation: Services running on different .NET versions
• Inconsistent patterns: Different teams used different approaches
• Limited test coverage: Legacy code often lacks automated tests
• Coupled services: Services that should be independent share databases or direct dependencies

AI-Assisted Development

AI code assistants (GitHub Copilot, Cursor, Claude, etc.) are transforming brownfield modernization:

• Code Understanding: AI can analyze large codebases and explain architecture, identify patterns, and surface hidden dependencies — accelerating onboarding and system understanding.
• Refactoring at Scale: AI can systematically apply refactoring patterns across large codebases — migrating from async void to async Task, converting synchronous I/O to async, adding nullability annotations, extracting interfaces for testability, and modernizing language features.
• Test Generation: AI can generate unit tests and integration tests for existing code, improving coverage and creating safety nets for refactoring.
• Documentation: AI can generate API documentation, architecture diagrams, and runbooks from existing code.

Spec-Driven Methodology

Spec-driven development treats specifications as the primary artifact:

1. API Contracts First: Define OpenAPI/Swagger specs before implementation
2. Domain Events First: Define event schemas before implementing event handlers
3. Database Schema First: Define migration scripts before implementing business logic
4. Test Specifications First: Write test scenarios before implementation

AI amplifies this approach by generating boilerplate, filling in implementation details, and ensuring consistency between specs and code. With AI, you can write specifications, have AI generate implementation scaffolding, review and iterate on the generated code, use AI to generate tests from specifications, and use AI to generate migration plans for legacy code.

Practical Modernization Strategy

For a brownfield .NET distributed system:

1. Inventory and Assess: Map existing services, dependencies, and technology versions
2. Standardize: Target a single .NET LTS version (8 or 10)
3. Add Observability: Implement distributed tracing, structured logging, and health checks
4. Containerize: Dockerize services for consistent deployment
5. Decouple: Apply the Strangler Fig pattern — gradually extract functionality into new services
6. Automate: CI/CD pipelines, infrastructure as code, automated testing
7. Document: Architecture decision records, API documentation, runbooks

AI tools accelerate each step by automating the repetitive work and surfacing insights about the existing codebase.

Summary: The .NET Distributed Systems Toolkit

The .NET ecosystem provides a comprehensive toolkit for building and maintaining distributed systems:

For the engineer managing a large brownfield .NET distributed application, the platform provides both the primitives to build new services and the tooling to evolve existing ones. The combination of language expressiveness, runtime performance, framework completeness, and modern AI-assisted workflows makes .NET a compelling choice for distributed systems in 2025 and beyond.