Phase 4 of 5  ·  Modern Engineering
Week 17 / 20   ·   Ch 18

Microservices
Architecture

"When to choose microservices (and when NOT to)"

📚 Ch 18 — Service-Oriented SE🔬 Microservices⚖️ Monolith vs. Microservices⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🏢

Monolithic Architecture

Single deployable unit containing all application logic. Simple to develop, test, and deploy initially.
⌄

When to Use

MVPs, small teams, early-stage products, unclear domain boundaries.

Real-World Example

Stack Overflow: monolith serving 1.3 billion page views/month on a handful of servers. Still a monolith in 2024.

✓ Advantages

  • Simple to develop and debug
  • Single deployment
  • No network latency between components
  • Easy to test end-to-end

⚠ Watch Out

  • Scaling = scale everything
  • Long build/deploy times as it grows
  • Team coordination at scale
┌──────────────────────────────┐ │ Monolith │ │ UI + API + Business Logic │ │ + Data Access + Workers │ └──────────────┬───────────────┘ ↓ [Database]
🔬

Microservices

Application as suite of small, independent services. Each owns its data. Communicates via API.
⌄

When to Use

Large teams, clear domain boundaries, need independent scaling and deployment.

Real-World Example

Netflix: 700+ microservices. Amazon: 'Two-pizza teams' — service owned by team that can be fed with 2 pizzas.

✓ Advantages

  • Independent deployment
  • Independent scaling
  • Technology diversity
  • Small, focused teams

⚠ Watch Out

  • Network latency everywhere
  • Distributed transaction complexity
  • Operational overhead (k8s, service mesh)
  • Testing is hard
[User Service] → DB1 [Product Service] → DB2 [Order Service] → DB3 [Payment Service] → DB4 → Each service: independent deploy, scale, language
🔌

API Design for Services

REST, gRPC, GraphQL — the interface between microservices. Must be designed for evolution.
⌄

When to Use

Designing inter-service communication — your API is your contract.

Real-World Example

Netflix API gateway: single entry point for all 700+ services. Clients don't know internal structure.

✓ Advantages

  • Decoupled teams
  • API versioning enables gradual migration
  • Clear contracts

⚠ Watch Out

  • API changes must be backward-compatible
  • Versioning management overhead
Client → [API Gateway] ├→ /users → User Service ├→ /products → Product Service ├→ /orders → Order Service └→ /payment → Payment Service
🌐

Service Mesh

Infrastructure layer handling service-to-service communication — load balancing, service discovery, mTLS, observability.
⌄

When to Use

Large microservices systems where operational concerns (security, observability) are consistent across all services.

Real-World Example

Istio, Linkerd, Consul Connect. Used by Lyft, Google, IBM at scale.

✓ Advantages

  • Consistent security (mTLS) across all services
  • Centralized observability
  • Traffic management

⚠ Watch Out

  • Significant operational complexity
  • Performance overhead of sidecar proxies
Every service gets a sidecar proxy: [Service A] + [Envoy Proxy] [Service B] + [Envoy Proxy] → All service-to-service traffic goes through proxies → mTLS, tracing, retries handled automatically

📋Quick Reference

θ Ch 18 Cheat Sheet — Microservices Architecture
Monolith
Single deployable unit. Simple. Scale by running multiple copies. Start here.
Microservice
Independent service, owns its data, deployed separately. For scale + team independence.
When to split
When: team coordination pain, specific scaling bottleneck, clear domain boundary. NOT because it's 'modern'.
API Gateway
Single entry point routing to all services. Handles auth, rate limiting, SSL termination.
Service Mesh
Sidecar proxies handling service-to-service comms. mTLS, observability, traffic management.
Strangler Fig
Migration pattern: gradually replace monolith with services, one slice at a time.
Martin Fowler
'Don't consider microservices unless you have a system too complex to manage as a monolith.'
θ
Sommerville's Key Points — Ch 18
Author's own summary from the end of the chapter.
  • 1Monolith: single deployable unit. Simple to develop, complex to scale.
  • 2Microservices: small, independent services communicating via APIs.
  • 3Microservices advantages: independent deployment, scaling, team ownership.
  • 4Microservices challenges: distributed transactions, operational complexity, testing.
  • 5Start monolithic, split when pain is real (Fowler's advice).
  • 6API design is critical — microservice APIs are public contracts.
  • 7Service mesh handles cross-cutting concerns: security, observability, traffic management.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
Name 3 advantages and 3 disadvantages of microservices over a monolith.
Advantages: 1. Independent deployment — one service update doesn't require full system release. 2. Independent scaling — scale only the service under load, not everything. 3. Team autonomy — each team owns a service end-to-end. Disadvantages: 1. Network complexity — every call is a potential failure. 2. Distributed transactions — no ACID across services. 3. Operational overhead — need k8s, service mesh, distributed tracing, CI/CD per service.
Q2
Apply
What is the Strangler Fig pattern?
A migration pattern for moving from monolith to microservices. Like a strangler fig vine that grows around a tree: gradually move functionality to services while the monolith continues running. Each new feature goes to a service, old features migrated one at a time, until the monolith is strangled. Avoids big-bang rewrites.
Q3
Analyze
When does it make sense to remain a monolith?
When: team is small (<15 engineers). Domain boundaries are unclear. System is in early stages. Traffic doesn't require independent scaling. Operational complexity of microservices outweighs benefits. Stack Overflow is the classic example: monolith serving billions of requests with a tiny ops team.
Up Next → Week 18
Project Management
Why great engineers fail as managers — and what it actually takes
Continue → Week 18