Microservices vs. Monolith
18 min
Neither a monolith (one deployable codebase) nor microservices (many independently deployable services) is universally "better" — it's a genuine tradeoff. Microservices buy independent deployment and scaling per-service, at the cost of real operational complexity (network calls where function calls used to be, distributed tracing, more infrastructure to run). That cost is worth paying once a few conditions line up: a large enough team that a shared monolith becomes a bottleneck, frequent independent deploys, or components with genuinely different scaling needs.
def recommend_architecture(team_size, deploy_frequency_per_week, independent_scaling_needed):
score = 0
if team_size > 20:
score += 1
if deploy_frequency_per_week > 5:
score += 1
if independent_scaling_needed:
score += 1
return "microservices" if score >= 2 else "monolith"
This is a deliberately simplified heuristic, not a rigorous formula -- real teams weigh these factors qualitatively, often starting with a monolith and splitting out services only as specific pain points (a slow deploy pipeline, one component needing very different scaling) actually show up, rather than deciding everything upfront.
Write `recommend_architecture(team_size, deploy_frequency_per_week, independent_scaling_needed)`: award one point each if `team_size > 20`, `deploy_frequency_per_week > 5`, or `independent_scaling_needed` is true. Return `'microservices'` if the total is `2` or more, otherwise `'monolith'`.
Why does team SIZE factor into the monolith-vs-microservices decision at all — isn't this purely a technical question?
You can reason through the monolith-vs-microservices tradeoff using concrete organizational signals, not just technical ones.