What is the difference between a monolith and microservices?

A monolith is one codebase built and deployed as a single unit, usually with one shared database. Microservices split the system into small services that each own one capability and its data. They are deployed independently and talk over the network. You trade the simplicity of one unit for independent deployment and scaling.

Choose a monolith for early products, small teams and domains that are still changing. It is faster to build, test, debug and deploy, and refactoring across features is cheap. Most teams should start here and split only when real pain appears, such as slow releases or conflicting scaling needs.

They make sense for large organisations with many teams and clear, stable domain boundaries. Each team can then deploy without coordinating with the others. They also help when parts of the system have very different scaling, reliability or compliance needs. You also need mature CI/CD, monitoring and on-call practices to run them well.

You gain independent deployment, per-service scaling, fault isolation and team autonomy. You pay with network latency, partial failures, distributed data and eventual consistency. You also need much more operational tooling, such as service discovery, tracing and centralised logging. The overall system is harder to reason about and to test end to end.

A monolith scales as a whole: you run more copies of the entire app, even if only one feature is hot. Microservices let you scale only the busy service, for example search or video processing. A monolith can still scale horizontally behind a load balancer. Per-service scaling mainly saves resources when load is very uneven.

I would pick a monolith, ideally a well-structured modular one. Four engineers cannot afford the operational overhead of many services. The domain will also change a lot, and moving code inside one codebase is cheap. Keeping clean module boundaries leaves the option to extract services later if needed.

Owning its data lets a service change its schema and deploy without breaking other services. It also enforces a clear boundary: other services must use its API or events, not its tables. The cost is that joins and transactions across services become hard. You must then use patterns like sagas, events and read models.

A modular monolith is a single deployable app split internally into well-isolated modules with clear interfaces. Each module often has its own schema or tables. You keep the simple deployment and in-process calls of a monolith while getting cleaner boundaries. It is often the best middle ground and an easy starting point for later extraction.

You put a routing layer, such as a proxy or API gateway, in front of the monolith. You then build new functionality, or extract an existing capability, as a separate service. Traffic for that capability is routed to the new service, piece by piece. Over time the monolith shrinks, avoiding a risky big-bang rewrite.

A distributed monolith is split into services that are still tightly coupled. They share a database, need to be deployed together, or make long chains of synchronous calls. You get all the network and operational costs of microservices but none of the independence. It usually comes from splitting along technical layers instead of business capabilities.