Module 5 — Architecture

Monolith vs Microservices

Two architectural styles. Neither is inherently better—choose based on your needs.

1The Restaurant Analogy

💡 Simple Analogy
Monolith: One big restaurant where kitchen, bar, and dining all share space. Easy to coordinate, but if the kitchen catches fire, everything shuts down.

Microservices: Food court with separate vendors. Kitchen fire at one stall? Others keep serving. But coordinating a meal across stalls is harder.

2Visual Comparison

Monolith

UI
Business Logic
Data Access

Single deployable unit

Microservices

Users
Orders
Payments
Inventory

Independent services

3Detailed Comparison

AspectMonolithMicroservices
DeploymentDeploy entire appDeploy services independently
ScalingScale entire appScale specific services
Tech StackSingle stackDifferent stacks per service
Team SizeBetter for small teamsBetter for large orgs
ComplexitySimple locally, complex at scaleComplex initially, manageable at scale
FailuresOne bug can crash allIsolated failures

4When to Choose

Start with Monolith When

  • • Small team (< 10 developers)
  • • New product, unclear requirements
  • • Need to move fast
  • • Domain not well understood
  • • Limited DevOps expertise

Consider Microservices When

  • • Large org with multiple teams
  • • Different parts scale differently
  • • Need independent deployments
  • • Clear domain boundaries
  • • Strong DevOps culture
Common Wisdom

"Start with a monolith, extract microservices when you understand your domain boundaries." Premature microservices is a common cause of project failure.

5Microservices Challenges

Network Latency
Inter-service calls add latency vs in-process calls
Distributed Debugging
Tracing requests across services is complex
Data Consistency
No ACID across services, eventual consistency
Operational Overhead
Each service needs CI/CD, monitoring, logging
Testing
Integration testing across services is harder

6Key Takeaways

1Monolith: single deployable unit. Simple but doesn't scale organizationally.
2Microservices: independent services. Complex but scales with teams.
3Start with monolith unless you have strong reasons not to.
4Microservices add distributed systems complexity.
5Decision should be based on team size and org structure, not just tech.
6In interviews: show you understand trade-offs of both, not just hype.