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 — one deployable unit
Monolith — UI + API + logic + data + workers
Database
Everything ships together — simple to build and test, but you scale all of it at once.
🔬

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
Microservices — each service owns its data
User Service→ its own database
Product Service→ its own database
Order Service→ its own database
Payment Service→ its own database
Each service deploys, scales and can be written in a different language independently.
🔌

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
API gateway — one entry point, many services
Client
API Gateway
/usersUser Service
/productsProduct Service
/ordersOrder Service
/paymentPayment 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
Service mesh — a sidecar proxy beside every service
Service A + EnvoySidecar proxy
Service B + EnvoySidecar proxy
All service-to-service traffic flows through the proxies — mTLS, tracing and 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.

🌍From the Book & Beyond

📖

Case Study — The In-Car Information System (Fig 18.1)

Figure 18.1 is Sommerville's flagship service example: a service-based in-car information system. Five in-car modules (user interface, locator, transmitter, receiver, radio) send the car's GPS position to an external mobile information service, which uses a service discovery service to find and bind local weather, road traffic, and facilities services — then a translator service converts the aggregated stream into the driver's own language. The punchline: no provider is hard-wired at deployment. As the car crosses a border, the system discovers and binds to new local services at runtime. That late, dynamic binding is the core promise of service-oriented architecture.

⚡

2026 Perspective — The Microservices Backlash

The pendulum swung. In 2023, Amazon Prime Video published a case study describing how it merged its distributed video-monitoring microservices back into a monolith, reporting infrastructure cost savings of around 90% — a wake-up call from the company that popularized services. By 2026 the pragmatic default is the modular monolith: enforce service-style boundaries inside one deployable, and only extract a true microservice when scaling or team ownership genuinely demands it. Microservices didn't die; teams just stopped paying the distributed-systems tax — network calls, eventual consistency, operational sprawl — for problems a single process could solve.

🧠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