Two more styles worth knowing: serverless (functions that scale to zero and bill per use) and service-oriented architecture (microservices’ enterprise ancestor).
Why: serverless (functions-as-a-service) runs your code in response to events with no servers to manage, scaling automatically from zero and billing only for actual execution — ideal for spiky, event-driven, or low-baseline workloads. When: use it for glue, event handlers, and unpredictable traffic; be wary for steady high-throughput or latency-sensitive work (cold starts). Where: it maximizes operational simplicity and cost-efficiency at the price of runtime limits and vendor lock-in.
SERVERLESS (FaaS): event ──► your function runs ──► scales automatically ──►
scales to ZERO when idle, bills per execution.
+ no servers to manage; auto-scaling; pay-per-use (great for spiky load)
- cold starts (latency), execution time/memory limits, vendor lock-in,
harder local testing
Best for: event handlers, glue, unpredictable/low-baseline traffic.
Poor fit: steady high-throughput or tight-latency services.Why: service-oriented architecture predates microservices and shares the idea of building from services, but classically centered on a shared Enterprise Service Bus (ESB) and enterprise-wide reuse — heavier and more centralized than microservices’ "smart endpoints, dumb pipes." When: you will meet SOA in large enterprises; understand it to modernize toward microservices. Where: the key contrast is centralization (SOA’s ESB) vs. decentralization (microservices).
SOA vs MICROSERVICES (both build from services, but differ in philosophy):
SOA shared Enterprise Service Bus (ESB), enterprise-wide reuse,
centralized, often shared databases -> "smart pipes"
MICROSERVICES decentralized, dumb pipes + smart endpoints, each service
owns its data, independent deploys -> "dumb pipes"
Microservices are, in spirit, SOA done fine-grained and decentralized.Why: the styles are not a ladder to climb but a menu to choose from based on the system’s forces (scale, team size, workload shape, operational maturity) — most real systems even mix them. When: default to a modular monolith; reach for microservices when scale/teams demand it, serverless for event-driven/spiky pieces, and combine as needed. Where: the architect’s value is matching the style to the actual constraints, not chasing the newest option.
Pick by the forces on THIS system (mixing is normal):
small team / early product -> modular monolith
independent scaling + many teams -> microservices (once you can fund it)
spiky / event-driven pieces -> serverless functions
large legacy enterprise -> SOA, modernizing toward microservices
Not a maturity ladder — a menu. Match the style to the constraints.