Microservices vs monoliths (trade-offs)

A monolith is one deployable application containing all features; it runs as a single process (or a few). Microservices split the system into many small services, each deployable and scalable independently, communicating over the network.

Monolith vs microservices layout

flowchart TB subgraph Monolith["Monolith"] M[Single app\nAuth + Orders + Users + ...] end subgraph Micro["Microservices"] A[Auth Service] O[Order Service] U[User Service] A --- O O --- U end

Aspect	Monolith	Microservices
Deploy	One big deploy	Deploy per service
Scaling	Scale whole app	Scale only hot services
Complexity	Simpler ops, one codebase	Distributed ops, network, discovery
Consistency	Single DB, ACID easy	Distributed data, eventual consistency
Team	One repo, coordinated releases	Teams own services, independent release

When to choose which

flowchart LR subgraph Mono["Favor monolith"] M1[Small team, early product] M2[Strong consistency needs] M3[Simple ops] end subgraph Micro["Favor microservices"] S1[Large org, many teams] S2[Different scale per domain] S3[Independent deploy required] end

Start with a monolith when the team and product are small; split into microservices when you hit scaling or organizational boundaries (team ownership, different scaling per domain). Don’t split by default — distributed systems are harder.