Microservices Architecture

What Microservices Architecture Actually Means

Microservices architecture decomposes an application into small, independent services that communicate over a network. Each service owns its own data, can be deployed independently, and is focused on a single business capability. It is the opposite of a monolithic architecture where everything runs as one unit.

When to Use It (and When Not To)

Microservices enable large engineering teams to work independently, deploy frequently, scale individual components, and use the best technology for each service. However, they introduce distributed systems complexity that must be managed carefully.

The Architecture

Instead of one monolithic application handling users, orders, payments, and notifications: you split into 4 services. The User Service handles authentication and profiles. The Order Service handles order creation and status. The Payment Service handles charging customers. The Notification Service sends emails/push notifications.

They communicate via APIs (synchronous) or message queues (asynchronous). An API gateway routes external requests to the correct service.

Key Principles

• Single responsibility: Each service does one thing well — user service, payment service, notification service.
• Independent deployment: Deploy any service without affecting others. Enables CI/CD and rapid iteration.
• Own data store: Each service has its own database. No shared databases between services.
• API communication: Services communicate via REST, gRPC, or message queues. No direct database access across services.
• Eventual consistency: Since each service has its own database, cross-service consistency is eventually consistent (via events, sagas).

Who Does This Well

Netflix has 1000+ microservices handling everything from video encoding to recommendation algorithms.

Amazon decomposes their e-commerce platform into hundreds of microservices — each team owns a service end-to-end.

Uber migrated from a monolith to microservices to support independent team velocity and per-service scaling.

The Hard Parts Nobody Talks About

1. Adopting microservices too early — a small team with a simple product should start with a monolith
2. Shared databases between services — defeats the purpose of independence
3. Not investing in observability — distributed systems are hard to debug without tracing, logging, and metrics
4. Too many services — each service has operational overhead. 5 microservices for a 3-person team is too many

The Tradeoffs

• Complexity vs Flexibility: Microservices add network, deployment, and debugging complexity but enable independent scaling and deployment.
• Team autonomy vs Coordination: Each team owns a service but cross-service features require coordination.
• Performance: Network calls between services are slower than in-process function calls in a monolith.

Interview Angles

1. When should you use microservices vs a monolith?
2. How do microservices communicate?
3. What is the biggest challenge with microservices?
4. How do you handle distributed transactions across microservices?

Keep Learning

• client-server
• API Gateway
• Service Discovery
• Event-Driven vs Request-Driven
• Circuit Breaker
• distributed-tracing

Building Microservices with .NET

.NET is one of the most popular platforms for microservices, with first-class support from Microsoft:

Project Tye and Aspire (the newer approach): .NET Aspire is Microsoft's opinionated stack for building distributed applications. It provides service discovery, health checks, telemetry, and configuration — all built in:

// AppHost/Program.cs — define your distributed app
var builder = DistributedApplication.CreateBuilder(args);
var redis = builder.AddRedis("cache");
var postgres = builder.AddPostgres("db");

builder.AddProject<Projects.WebApi>("api")
    .WithReference(redis)
    .WithReference(postgres);

builder.AddProject<Projects.WorkerService>("worker")
    .WithReference(redis);

gRPC in .NET: ASP.NET Core has built-in gRPC support for high-performance service-to-service communication. Define your service in .proto files, and the tooling generates C# clients and server stubs:

// Define in proto file
service OrderService
    rpc GetOrder (GetOrderRequest) returns (OrderResponse);
    rpc StreamOrders (StreamRequest) returns (stream OrderResponse);

// Generated C# client usage
var channel = GrpcChannel.ForAddress("https://order-service:5001");
var client = new OrderService.OrderServiceClient(channel);
var order = await client.GetOrderAsync(new GetOrderRequest { Id = 123 });

Real example: Microsoft's own eShop reference application demonstrates a full microservices architecture with .NET — Catalog, Ordering, Basket, and Identity services communicating via gRPC and RabbitMQ, deployed on Kubernetes.

Original DosiBridge notes for Microservices Architecture

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Microservices Architecture is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Ownership Boundary: For Microservices Architecture, decide the ownership boundary before choosing tools; otherwise the design looks clean but fails when microservices changes.
• Blast Radius: For Microservices Architecture, decide the blast radius before choosing tools; otherwise the design looks clean but fails when microservices changes.
• Deployment Path: For Microservices Architecture, decide the deployment path before choosing tools; otherwise the design looks clean but fails when microservices changes.
• Runtime Coupling: For Microservices Architecture, decide the runtime coupling before choosing tools; otherwise the design looks clean but fails when microservices changes.
• Operational Handoff: For Microservices Architecture, decide the operational handoff before choosing tools; otherwise the design looks clean but fails when microservices changes.

Production review question

If a team adopts Microservices Architecture, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track microservices health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Microservices Architecture, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.