Monolith vs microservices

A monolith is one deployable application containing all the business logic. Microservices split that logic into separately deployed services that communicate over the network, each usually owning its own data.

#What microservices buy

• Independent deployment. Teams ship their service without coordinating a release with everyone else.
• Independent scaling of hot components.
• Fault isolation, if designed for it: a crashing recommendations service needn't crash checkout.
• Technology freedom per service.

#What they cost

• Every call is a network call that can fail, time out or succeed twice, so you need timeouts, retries and idempotency everywhere.
• No transactions across services. Consistency across them needs sagas and outboxes.
• Operational load: service discovery, tracing across services, versioned APIs, many pipelines and dashboards.
• Harder debugging and testing, because behaviour emerges from many processes.

#The modular monolith

Most of the benefits of good boundaries come from modules, not from network hops. A modular monolith keeps one deployable but enforces boundaries inside it: each module owns its tables, exposes a narrow interface, and doesn't reach into others' data. It's fast to build and easy to operate, and a well-separated module can be extracted into a service later if a real need appears.

#When to split

Split a service out when there's a concrete reason: a team that needs to deploy independently, a component with very different scaling or reliability needs, or a security boundary. "Microservices are best practice" isn't a reason. Splitting along the wrong boundaries produces a distributed monolith — all the costs of both. See when not to add infrastructure.