Infrastructure Decisions · judgement tool

When should I split into microservices?

Team size, deploy contention and genuine independent-scaling needs decide it — for most small teams the honest answer is 'not yet', and this tool says so. Every factor tagged by provenance; the monolith-first default is labeled our judgement.

A judgement tool, not a tool ranking · thresholds are StackSays rules, not industry standards · official facts verified 2026-07-17 · share the URL to share your answers

How to read this: every factor below is tagged by where it comes from — official fact official/documented · calculation math on your inputs · StackSays rule our decision logic · StackSays estimate our judgement. The verdict cut-points are StackSays rules, not an industry threshold — there is no universal traffic number for these decisions.

Your situation

The recommendation updates as you answer. Share the URL to share it.

Engineering team sizehow many engineers ship this systemTeams blocked by shared deploysone team's release blocks another'sParts need very different scalinge.g. a GPU worker vs a web APIGenuinely different runtimes neededdifferent languages/stacks for real reasonsThe monolith is genuinely hard to changemeasured pain, not anticipated

Recommendation

Not yet

Based on the factors you set — 0 pushing toward adopting, 1 against.

Why it might be premature

-22 Small team → stay monolith — For a 1–3 person team, a monolith is almost always right — microservices add distributed-systems failure modes, deploy orchestration and latency you don't need (our strong judgement)StackSays estimate

When to reassess

Revisit when the team grows past ~10, deploy contention becomes a weekly problem, or one component genuinely needs to scale/run differently — not because microservices are fashionable.

Minimal implementation

Don't 'go microservices'. Extract the ONE component with a real independent-scaling or runtime need into a single separate service. Keep the rest a monolith.

Risk of not doing it

For most teams, nothing — a well-structured monolith scales far further than assumed. Premature splitting is the more common and more expensive mistake.

Cost & complexity once adopted

High: network failure modes, distributed transactions, deploy orchestration, observability across services, and latency between calls. This is why the default here leans 'Not yet'.

This is a judgement tool, not a leaderboard. The StackSays rule and StackSays estimate factors are StackSays logic and opinion; the official fact factors link to official sources below. No industry-standard threshold is implied — the answer is driven by the conditions you set.

Official facts cited

Source	Verified
AWS microservices tradeoffs & operational complexity (official)	2026-07-17

Only the factors tagged “official fact” rest on these sources; rules and estimates are StackSays logic and are labeled as such.

Next decision

Where should background jobs run? →Which hosting should I use? →