Microservices Architecture
Decompose an application into small, independently deployable services that communicate over a network.
★★★★★5/5System topology — how multiple services are organised
Interactive visualization
LiveHow it works
Microservices architecture structures an application as a collection of loosely coupled services, each responsible for a specific business capability. Services communicate via lightweight protocols — typically HTTP/REST, gRPC, or asynchronous messaging.
Each service owns its data store, can be deployed independently, and is built around a business domain (e.g., User Service, Order Service, Payment Service). Teams can develop, deploy, and scale services independently.
The pattern introduces operational complexity: you need service discovery, distributed tracing, circuit breakers, and an API gateway. Tools like Kubernetes, Istio, and Prometheus typically form the operational backbone.
Why it matters
Microservices let large organisations scale development by allowing independent teams to own and deploy services, removing the bottleneck of a shared monolith.
✓ When to use
- →Large teams that need independent deployment cadences
- →Services with very different scaling requirements
- →Different parts of the system require different technology stacks
- →High availability requirements for specific business capabilities
✗ When NOT to use
- →Small teams (< 10 engineers) — operational overhead outweighs benefits
- →Early-stage product where domain boundaries are still unknown
- →When network latency would degrade user experience unacceptably
Trade-offs
Independent deployment and scaling per service
Distributed systems complexity (network failures, latency)
Technology heterogeneity — right tool for each job
Operational overhead: monitoring, tracing, service mesh
Fault isolation — one service failing doesn't crash others
Data consistency across services is hard (eventual consistency)
In production
700+ microservices; each team owns its service lifecycle
Two-pizza teams each own independent services (since ~2002)
Decomposed monolith into domain-specific microservices as scale grew
Industry adoption
Related principles
API Gateway
LiveSingle entry point for all clients that handles routing, authentication, rate limiting, and protocol translation.
Service Mesh
LiveOffload cross-cutting network concerns (mTLS, retries, circuit breaking, observability) to a dedicated infrastructure layer via sidecar proxies.
Circuit Breaker
LiveAutomatically stop calling a failing service to give it time to recover — preventing cascading failures across distributed systems.
Saga Pattern
LiveManage distributed transactions across services using a sequence of local transactions with compensating rollbacks on failure.