Guías de decisión

Monolith or microservices?

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

Esta página aún no está totalmente traducida a tu idioma — mostrando la versión en inglés.

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

Responde todas las preguntas para ver tu recomendación.

Todas las opciones de un vistazo

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.

Elige esto cuando

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

Compensaciones

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.

Elige esto cuando

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

Compensaciones

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.

Elige esto cuando

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

Compensaciones

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