All patterns
Distributed systems
Microservices
Independently deployable services around business capabilities
Each service owns a bounded context, data store, and release cycle. Teams scale delivery in parallel; operations trade simplicity for resilience, observability, and distributed coordination.
Enterprise scalehigh complexity
Architecture diagram
High-level component relationships
Key components
API gateway
Routing, auth, rate limits, aggregation
Domain services
One capability per service with owned data
Service mesh / discovery
Traffic management and mTLS (optional)
Observability stack
Tracing, metrics, centralized logging
Data flow
- Client hits gateway; request routes to owning service
- Synchronous HTTP/gRPC between services when needed
- Async events for decoupled side effects (order placed → notify)
- Each service commits to its own database
Pros
- Independent deploy, scale, and technology per service
- Team autonomy aligned to business domains
- Fault isolation when designed with bulkheads
- Easier compliance boundaries (PCI scope reduction)
Cons
- Distributed transactions and consistency are hard
- Operational overhead: K8s, CI/CD per service, on-call complexity
- Integration testing and local dev are painful without tooling
- Risk of distributed monolith if services are too chatty
When to use
- Large org with multiple autonomous teams
- Different scaling or SLA needs per capability
- Mature DevOps, SRE, and platform engineering
When to avoid
- Early startup still discovering domain boundaries
- Team lacks observability and deployment automation
- Mostly CRUD with uniform scaling needs
Real-world examples
- Netflix
- Amazon retail services
- Uber's domain services
Related technologies
KubernetesgRPCKafkaConsulIstio