Microservices vs Serverless vs Monolith: Decision Framework
Fast recall
Quick revision
Core answer
Architectural judgment — not just 'do you know what each is' but whether you can pick for a concrete context
Defaulting to microservices for every problem; ignoring serverless cold-start and Vendor lock-in costs; dismissing modular monolith as 'old-fashioned'
Discuss hybrid architectures (microservices core + serverless event handlers), operational-maturity prerequisites, and the specific economics: Lambda costs 3x more than EC2 at sustained load but is cheaper below ~15% utilization
Interview-ready guide
Interview answer
The three architectures
- Modular monolith: one deployable, strong internal module boundaries enforced by code
- Microservices: multiple independently-deployable services, each owning its data
- Serverless (FaaS): functions on managed runtime, fire on events, scale to zero, pay per invocation
Decision criteria in order of importance
- Team size and squad count
- Traffic pattern (steady vs bursty vs idle)
- Operational maturity (CI/CD, observability, on-call)
- Cost model (fixed vs per-request)
- Latency requirements (cold start matters)
- Data locality and consistency needs
When to choose modular monolith
- Team under 15 engineers, one product
- Steady predictable traffic
- CI/CD maturity early
- Strong module boundaries via Maven modules, Gradle subprojects, ArchUnit tests
- Single data model, unified domain
- Scales far beyond most teams' needs — Stack Overflow runs on a small cluster
When to choose microservices
- Three or more independent squads with different release cadences
- SLO differentiation between components — checkout at 99.99%, analytics at 99.5%
- Polyglot — ML in Python, recommendations in Go, core in Java
- Scaling differentiation — GPU nodes for images, cheap replicas for API tier
- Independent data stores per bounded context
- Observability and CI/CD already mature — prerequisites, not aspirations
When to choose serverless
- Bursty or low-duty-cycle workloads
- Event-driven glue — S3 upload triggers Lambda triggers Kinesis
- Variable scaling from 10 to 10,000 rps in 5 seconds
- Short-lived execution under 15 minutes
- Small team without infra skills
- Cost breakpoint: Lambda is ~3x EC2 at sustained load, ~0.3x below 15% utilization
- Cold start is real: 2-8 seconds for Java without mitigation; 200-500ms with SnapStart or GraalVM
When serverless is NOT a good fit
- Latency-critical user-facing APIs without provisioned concurrency
- Long-running connections like WebSockets
- Heavy in-memory state between requests
- Sustained high load above 20% duty cycle
- Avoiding vendor lock-in is critical
Rough cost math
- EC2 m5.large always-on: about $70 per month
- Lambda 512 MB at 1M requests with 200ms average: about $10 per month
- Lambda at 100M requests: about $1000 per month — more than EC2 at 24/7
- Breakpoint around 10M invocations per month for that config
Hybrid is usually right
- Microservices core for steady load on Kubernetes or Fargate
- Lambdas for event handlers, cron jobs, glue
- Monolith-as-a-service: one big Spring Boot deployable plus a few Lambdas
- Pure stances are almost always wrong
Common anti-patterns
- Defaulting to microservices for every project — overhead exceeds value below 15 engineers
- Function-per-endpoint in Lambda — hundreds of tiny functions to manage
- Ignoring cold start — user-facing p99 suffers
- Underestimating vendor lock-in — Lambda is deeply AWS-tied
- Starting microservices without CI/CD or observability — chaos multiplier
Migration triggers
- Monolith to microservices: deploy conflicts, coupling preventing velocity, SLO differentiation, team growth past 15
- Lambda to containers: duty cycle past 30%, latency SLOs not met under cold start
The pragmatic default for a new project in 2026
- Modular monolith plus a few Lambdas for event glue
- Revisit in 12 months
- Split when pain appears; don't prematurely distribute; don't prematurely serverlessize
The strategic answer
- No single architecture is right — the decision depends on team, traffic, operational maturity
- Monolith wins below 15 engineers; microservices win with SLO differentiation and squad count; serverless wins for bursty event-driven workloads
- Hybrid is the mature choice: a steady core plus serverless event handlers
- Operational maturity gates the choice; without CI/CD and observability, stick with simpler architectures
Microservices vs Serverless vs Monolith: Decision Framework
Direct Answer
Modular monolith wins below ~15 engineers, steady load, single product — lowest operational cost, strong module boundaries without the distributed-systems tax. Microservices win when team count > 3 independent squads, need for polyglot, independent scaling per service, and SLO differentiation between components. Serverless (AWS Lambda, Azure Functions) wins for bursty / idle workloads, event-driven glue, and when you want to pay only per invocation. Key criteria: team count, traffic pattern (steady vs bursty), cost model (fixed infra vs per-request), operational maturity (CI/CD, observability), latency requirements (cold start on Lambda is real), and data-locality needs. In practice, most real systems mix — microservices for the steady core, serverless for event handlers and glue.
Common Mistakes & Pitfalls
Defaulting to microservices for every problem; ignoring serverless cold-start and Vendor lock-in costs; dismissing modular monolith as 'old-fashioned'
Check your understanding
Answer these without looking back at the article.
- How does AWS Lambda SnapStart work and when does it actually fix cold start?
- What's the cost breakpoint between Lambda and EC2 for a 512MB Java workload?
- How would you enforce modular-monolith boundaries in code — what tools and patterns?
- What triggers should prompt migrating from a modular monolith to microservices?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.