Roadmap › 1. .NET › Step 27

Microservices & System Design with .NET

Monolith vs modular monolith vs microservices, service boundaries (DDD), REST/gRPC and messaging, API gateways, data per service, sagas and the outbox pattern, resilience, observability, caching, scaling and the system-design interview round.

What it is & where it is used

Microservices is an architectural style where an application is built as a set of small, independently deployable services, each owning one business capability and its own data, communicating over the network (HTTP/gRPC or messages).

Style	What it is	Good for
Monolith	One deployable unit, one database	Small teams, early products — simple to build, test and deploy
Modular monolith	One deployable, but strict internal modules (own schema, public interfaces)	Most business apps; easy to split later
Microservices	Many deployables, each with its own data and pipeline	Large organisations, parts with very different scaling/release needs

System design is the interview round where you design a whole system (requirements → APIs → data → components → scaling → trade-offs). Microservice concepts (queues, caches, gateways, consistency) are the vocabulary of that round.

In .NET the common toolset is: ASP.NET Core (REST/minimal APIs), gRPC, YARP (reverse proxy / gateway), MassTransit or NServiceBus over RabbitMQ / Azure Service Bus, Polly / Microsoft.Extensions.Http.Resilience, OpenTelemetry, Docker, Kubernetes/AKS or Azure Container Apps, and .NET Aspire for local orchestration and observability.

Versions & history

Year	Milestone
2011–2014	"Microservices" term popularised (James Lewis, Martin Fowler — article 2014)
2015–2017	Netflix OSS, Docker and Kubernetes make the style mainstream
2017	Microsoft eShopOnContainers reference app and the ".NET Microservices: Architecture for Containerized .NET Applications" guide
2019	gRPC support in ASP.NET Core 3.0
2021	YARP 1.0 reverse proxy
2023	.NET 8: `Microsoft.Extensions.Http.Resilience` (built on Polly v8); .NET Aspire preview
2024	.NET Aspire 8.0 GA (May 2024) — orchestration, service discovery, OpenTelemetry dashboard
2025	.NET 10 and Aspire 9.x/13 — Aspire grows into a general app-host for distributed apps

Industry trend to mention: many teams moved back to modular monoliths after over-splitting (e.g. the Amazon Prime Video monitoring case study, 2023). Interviewers like candidates who choose microservices for a reason, not by default.

Lifecycle

Life of a request in a microservice system:

Client → API gateway (YARP / Azure API Management): TLS, auth token validation, routing, rate limiting.
Gateway → service A over HTTP/gRPC (service discovery finds an instance).
Service A reads/writes its own database.
Service A publishes an event (OrderPlaced) via the outbox to a message broker.
Services B and C consume the event asynchronously and update their own data.
Every hop carries a trace id (W3C traceparent) so one distributed trace shows the whole flow.

Life of a service: identify boundary (bounded context) → define contract (API/events) → build + tests → container image → CI/CD → deploy (rolling/blue-green/canary) → monitor (logs, metrics, traces, alerts) → evolve contract with versioning.

Tools used to develop

Communication: ASP.NET Core Web API / minimal APIs, gRPC, SignalR, YARP, Azure API Management, Ocelot (older).
Messaging: RabbitMQ, Azure Service Bus, Kafka / Azure Event Hubs, MassTransit, NServiceBus, Wolverine.
Resilience: Polly, Microsoft.Extensions.Http.Resilience (retry, circuit breaker, timeout, hedging).
Observability: OpenTelemetry, .NET Aspire dashboard, Application Insights, Prometheus + Grafana, Jaeger/Zipkin, Seq.
Hosting: Docker, Kubernetes / AKS, Azure Container Apps, Dapr (sidecar building blocks).
Data & cache: SQL Server / Azure SQL, Cosmos DB, PostgreSQL, Redis.
Design: C4 model diagrams, Event Storming for DDD boundaries.