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
• circuit-breaker
• distributed-tracing

The Real-World Incident That Made This Famous

The most pivotal moment in microservices history was Jeff Bezos's famous 2002 mandate at Amazon. The internal memo (later leaked by Steve Yegge's Google+ rant in 2011) stated: "All teams will henceforth expose their data and functionality through service interfaces. There will be no other form of interprocess communication allowed. Anyone who does not do this will be fired." This mandate forced Amazon's monolithic retail platform to decompose into hundreds of independent services, each owned by a small team.

The result was transformative. Amazon went from deploying once every few weeks (with everyone staying up all night for the deployment) to deploying thousands of times per day. Each team could choose their own programming language, database, and deployment schedule. But the transition was brutal. In 2003-2004, Amazon experienced frequent outages as teams struggled with distributed systems challenges they had never faced before: network timeouts, partial failures, data consistency across services, and cascading failures.

Netflix's migration from monolith to microservices (2009-2012) is equally instructive. After a major database corruption incident in 2008 that took down their DVD shipping service for three days, Netflix decided to move to the cloud and decompose into microservices. The migration took three years and involved building an entire ecosystem of tools: Eureka for service discovery, Hystrix for circuit breaking, Zuul for API gateway, and Chaos Monkey for resilience testing. Today Netflix runs over 1,000 microservices serving 200+ million subscribers. They open-sourced most of these tools, creating the foundation that the rest of the industry built upon.

How Senior Engineers Think About This

The mental model: microservices are an organizational pattern, not a technical one. Conway's Law states that systems mirror the communication structure of the organization that builds them. Microservices work when each service is owned by a small team (Amazon's "two-pizza team") that can build, deploy, and operate it independently. If you split a monolith into microservices but one team still owns all of them, you have a distributed monolith — all the complexity of microservices with none of the benefits.

Senior engineers know that the number one question is not "should we use microservices?" but "where should we draw the service boundaries?" Bad boundaries create services that constantly need to call each other for every operation, resulting in chatty communication, distributed transactions, and coupled deployments. Good boundaries follow Domain-Driven Design: each service owns a bounded context — a coherent set of business capabilities with its own data and its own language.

The honest truth about microservices: they trade code complexity for operational complexity. A monolith has complex code but simple operations (one thing to deploy, one database to manage, one log stream to read). Microservices have simpler code per service but vastly more complex operations (hundreds of deployments, dozens of databases, distributed tracing to debug requests that span 10 services). Most startups and small teams should start with a well-structured monolith and extract services only when they have a clear reason: a component that needs to scale independently, a team that needs to deploy independently, or a component that needs a different technology stack.

Common Interview Mistakes

Mistake 1: Advocating microservices for a system that does not need them. If the interviewer says "we have 5 engineers and a new product," microservices are the wrong answer. Start with a monolith. Extract services later when you have a clear scaling or organizational need.

Mistake 2: Not discussing service communication. Synchronous (HTTP/gRPC) creates tight coupling. Asynchronous (message queues) decouples services but adds complexity. Most real systems use a mix of both.

Mistake 3: Forgetting about data ownership. Each microservice should own its data. Sharing a database between services creates hidden coupling. Discuss the challenges of distributed data: no cross-service joins, eventual consistency, and the saga pattern for distributed transactions.

Mistake 4: Not mentioning operational requirements. Microservices require centralized logging, distributed tracing, service discovery, health monitoring, and automated deployment. Without these, you cannot operate microservices effectively.

Mistake 5: Ignoring the network. In a monolith, function calls are nanoseconds. In microservices, service calls are milliseconds. A request that touches 10 services accumulates latency. Discuss how to minimize call chains and use async communication where possible.

Production Checklist

• Define clear service boundaries using domain-driven design bounded contexts
• Implement centralized logging with correlation IDs that trace requests across services
• Set up distributed tracing (Jaeger, Zipkin, or OpenTelemetry) from day one
• Use a service mesh (Istio, Linkerd) or sidecar pattern for cross-cutting concerns: retries, timeouts, circuit breaking
• Implement a service registry (Consul, Eureka) for service discovery
• Use API versioning from the start to allow independent service evolution
• Implement the saga pattern for distributed transactions — avoid two-phase commit across services
• Set up health check endpoints on every service and configure automatic restart on failure
• Maintain a service dependency map and review it quarterly for circular dependencies
• Start with synchronous communication for simplicity, move to async (events/queues) when you identify bottlenecks

Read the original source | Content from System-Design-Overview

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.