Monolith vs Microservices

A monolith deploys as one unit; microservices split the same capabilities into independently deployable services.

Intermediate 5 min Architecture
Same capabilities · different boundaries
  • Monolith
  • Services
  • Data
MONOLITH — ONE DEPLOYABLE UNITMICROSERVICES — MANY DEPLOYABLE UNITSONE CODEBASE · ONE ARTIFACTCalls between layers are in-process — fast and reliableOne shared databaseJoins are easy — and the schema is shared by everythingDEPLOYOne release, all of itA one-line billing fix ships with everything elseSCALEThe whole thing grows togetherBusy checkout? Run another full copy.DEPLOYRelease unitMONOLITHOne artifact for it allMICROSERVICESOne service at a timeSCALEWhat growsMONOLITHA copy of the whole appMICROSERVICESOnly the busy serviceFAILUREBlast radiusMONOLITHA bad change hits it allMICROSERVICESContained; calls can failSERVICEOrdersBaskets and checkoutorders dbowns its dataSERVICEBillingInvoices and paymentsbilling dbowns its dataSERVICEUsersAccounts and profilesusers dbowns its dataAPINetwork calls: latency, retries, partial failureDEPLOYEach service ships on its ownMore pipelines, environments and versions to runSCALEOnly what is busySix copies of orders, one of billing
The same capabilities drawn two ways: one application released and scaled as a block, or several services released and scaled on their own — paying for that independence with network calls and more moving parts to operate.

Hover a side or a comparison row to isolate it; click any component for a short explanation.

Common misconception

“"Microservices are always the modern, better choice."”

They trade simplicity for independence. A small team with one product usually ships faster with a well-structured monolith; splitting helps when separate teams need to release separately.

Next conceptWhat is a CDN?A content delivery network serves copies of your content from locations close to the user.