决策指南

Monolith or microservices?

Four questions about your team and your product, and a straight answer — not a list of pros and cons.

本页面尚未完全翻译为您的语言——正在显示英文版本。

Microservices have a reputation as the grown-up choice, so teams reach for them far too early. The honest default is the opposite: start as one well-organized codebase, and split off a service only when something concrete forces your hand. These questions find out whether anything actually is.

How many teams need to ship this code?

One team — everyone works in the same codebaseSeveral teams that need to release on their own schedules

How settled is the product?

Early — still finding fit, the shape changes oftenMature — the main parts are stable and well understood

Do different parts have very different load or hardware needs?

No — it all grows togetherYes — one part is heavy or spikes on its own (e.g. GPU, video, search)

How strong is your operations muscle?

Light — small team, no dedicated platform or on-call crewStrong — a real platform team, solid CI/CD and monitoring

回答所有问题以查看建议。

所有选项一览

Start with a modular monolith

One codebase, one deploy — but with clean internal boundaries between modules. It's the fastest way to build now, and it keeps the option to split a service out later, once you actually know where the seams are.

在以下情况选择它

One team, or an early-stage product still changing shape
Everything scales together and ops is a small crew
You want to move fast and keep your options open

权衡

Needs discipline to keep module boundaries from blurring
Everything deploys together — one bad change can hold up the rest
Very different scaling needs eventually push you to split a part out

Keep the monolith, split off one service

Leave the bulk as a monolith and extract only the part with a real, specific reason to be separate — the piece that scales differently or that a separate team owns. One seam, not twenty.

在以下情况选择它

One part has very different load or hardware needs
Or a specific team needs to own and deploy one area independently
And you have the ops muscle to run more than one service

权衡

Now you have a network boundary to design, version, and monitor
The temptation is to keep splitting — resist it without a new reason

Go with microservices

Several teams, a settled domain, and real platform muscle — this is the situation microservices were actually built for. Split along team and domain lines so each team can ship on its own schedule.

在以下情况选择它

Several teams that are stepping on each other in one pipeline
Stable, well-understood domain boundaries to split along
A platform team and mature CI/CD, monitoring, and on-call

权衡

Big operational cost: networking, deploys, tracing, failure handling
Distributed systems are hard — partial failures and data consistency become daily work
Wrong boundaries are expensive to move once services are live