Card 07/ 10
Choosing a Style for a Team and a Product
Team size, rate of change and scale point to the style.
Choosing an architectural style depends less on the product's scale than on the team: how many people, how many teams, and how often the product changes shape. Most products are best started as a monolith with clear modules, and moved to separate services one part at a time when a specific pressure makes it worth the cost.
| Axis | Monolith | Microservices | Event-driven | Serverless |
|---|---|---|---|---|
| Teams it suits | One to a few | Many, each owning a service | Many, with many reactions | Small, with event-shaped work |
| Deploys | All together | Each service alone | Each service alone | Each function alone |
| Cost to run | Lowest | High: many services to watch | High: flows are hard to trace | Low when idle; high at steady load |
| Main risk | Teams block each other | Network calls and split data | Duplicates, ordering, visibility | Cold starts and limits |
When One small team, a product still changing every day
, chooseWhen Many teams blocked on one release, with clear boundaries between their parts
, chooseWhen Many services must react to the same things happening
, chooseWhen Short jobs triggered by events, with long idle periods
, choose
Otherwise Start with a modular monolith, and organise code inside it in layers.
Two cases that look nothing alike. A two-person startup that changes its product daily gains nothing from services: every change would cross them, and the operations would eat their week. A monolith fits. And Prime Video's stream-monitoring tool, built by a large company with every resource, moved from functions and services into one process, because its steps passed so much data that the network cost more than the work. In both, the deciding question was the same: what the division costs against what it buys.
The tempting mistake. Choosing microservices so that the product "can scale later". A monolith scales out by running more copies, and the scaling that microservices add, per part, matters only when parts need very different capacity.
So start with the simplest style the team can run, and divide it further only for a pressure you can name.
← → move through sections and cards