🏗️Key Takeaways
- 1Monolith → Modular Monolith → SOA → Microservices is an evolution, not a hierarchy
- 2Start monolith, extract services when you hit clear scaling or organizational boundaries
- 3Serverless (FaaS) excels for event-driven, bursty workloads but has cold start and vendor lock-in
- 4Architecture choice is driven by team size, deployment frequency, and scaling requirements
Choosing an Architecture Style
Architecture styles define how you organize code, deploy services, and manage data flow. There's no universally 'best' architecture — the right choice depends on your team size, scale requirements, and operational maturity.
The most common mistake is choosing microservices for a small team or new product. Start simple, evolve when pain points emerge.
Architecture Styles Compared
| Style | Team Size | Deployment | Data | Best For |
|---|---|---|---|---|
| Monolith | 1-15 devs | Single unit | Single DB | Startups, MVPs, small teams |
| Modular Monolith | 5-30 devs | Single unit, modular code | Shared DB, separate schemas | Growing teams needing boundaries |
| SOA | 20-100 devs | Service-based | DB per service possible | Enterprise, legacy modernization |
| Microservices | 50+ devs | Independent per service | DB per service | Large orgs, high scale, independent teams |
| Serverless | Any | Per-function | Managed (DynamoDB, etc.) | Event-driven, bursty, low-ops budget |
Deep Dive: Each Style
Single deployable unit containing all application code. Simple to develop, test, and deploy initially.
Becomes painful at scale: long build times, risky deployments, teams stepping on each other, single scaling dimension.
The answer isn't 'monoliths are bad' — it's 'monoliths don't scale organizationally.' If your team is small, a monolith is the right choice.
Still a single deployment, but code is organized into strongly-bounded modules with explicit interfaces.
Each module has its own schema/tables. Modules communicate via defined APIs, not direct DB queries.
Best of both worlds: monolith simplicity for deployment + service-like boundaries for code organization. Shopify runs on a modular monolith.
Each service is independently deployable, scalable, and owned by a single team. Communicates via APIs or events.
Benefits: independent deployment, technology diversity, fault isolation, team autonomy.
Costs: distributed system complexity, network latency, data consistency, operational overhead.
You need: CI/CD, container orchestration, service discovery, observability, distributed tracing. If you don't have these, you're not ready for microservices.
Code runs in stateless functions triggered by events (HTTP requests, queue messages, schedules).
Advantages: zero server management, pay-per-invocation, auto-scaling to zero.
Disadvantages: cold starts (100ms-5s), 15-minute execution limits, vendor lock-in, harder to test locally.
Advantages
- •Multiple proven styles for different scenarios
- •Modular monolith is an excellent middle ground
- •Serverless eliminates server management
Disadvantages
- •Wrong choice creates years of technical debt
- •Microservices require mature infrastructure
- •Migration between styles is expensive
🧪 Test Your Understanding
When is a monolith the right architecture choice?