Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Sections
Related Guides
Distributed Systems Patterns
High-Level Design
API Gateway Design: Auth, Rate Limiting, Routing, and BFF Patterns
High-Level Design
Message Queues & Streaming: Kafka, Delivery Semantics, and Consumer Groups
High-Level Design
Distributed Locks: Redlock, ZooKeeper, Fencing Tokens & Exactly-Once Guarantees
High-Level Design
Load Balancer Design: L4/L7 Routing, Health Checks, and Failover
High-Level Design
Microservices Architecture: Decomposition, Service Mesh, Circuit Breakers & Saga Pattern
When and how to decompose a monolith into microservices — and the distributed systems complexity that follows. Covers domain-driven decomposition, the strangler fig migration pattern, service discovery, API gateway, circuit breakers (Hystrix/Resilience4j), service mesh (Istio), and the saga pattern for distributed transactions.
Monolith vs Microservices: The Real Tradeoff
The most common mistake in microservices interviews is treating decomposition as an architectural default. It isn't. Microservices are a solution to specific scale and organizational problems — not a best practice to apply universally.
A monolith with a clean internal architecture scales to hundreds of engineers and billions of requests per day. Shopify ran on a Rails monolith to $175B GMV. Stack Overflow serves millions of developers on a tiny server fleet with a monolithic ASP.NET app. StackOverflow serves 1.3 billion page views per month with 9 web servers.
Microservices introduce: network latency on every cross-service call (add 1–10ms per hop), operational complexity (N services = N deployment pipelines, N monitoring stacks, N on-call rotations), distributed transaction complexity (saga pattern instead of ACID), and service discovery overhead.
When microservices are justified:
- Organizational: teams need to deploy independently without coordinating with 10 other teams
- Scale: specific subsystems need to scale independently (checkout service vs. catalog browse)
- Technology: different services genuinely benefit from different tech stacks (ML inference in Python, payments in Go)
- Fault isolation: one service's failure must not cascade to core functionality