Monolith vs Microservices

A monolithic architecture packages all application logic -- user management, order processing, inventory, payments -- into a single deployable unit sharing one database. This approach dominates early-stage products for good reason: a single codebase is easy to develop, test end-to-end, refactor across module boundaries, and deploy. Transactions spanning multiple business domains are simple ACID operations rather than distributed sagas. For teams under 20-30 engineers working on a product that fits within a single bounded context, a well-structured monolith is often the optimal architecture.

Microservices decompose that monolith into a collection of small, independently deployable services, each owning its own data store and communicating via well-defined APIs or asynchronous messaging. Each service maps to a specific business capability -- a payment service, an inventory service, a recommendation service -- and can be developed, deployed, and scaled independently. This enables teams to choose the best technology for each service, deploy multiple times per day without coordinating with other teams, and scale only the components that are under load.

However, microservices are not free. They trade the in-process complexity of a monolith for the distributed-system complexity of network calls, eventual consistency, service discovery, distributed tracing, and cascading failures. A function call that was a 1-microsecond in-process invocation becomes a 1-millisecond network round trip with failure modes that did not exist before. Testing becomes harder because integration tests must span multiple services and databases. Operational overhead grows linearly with the number of services -- each one needs its own CI/CD pipeline, monitoring dashboards, alerting rules, and on-call rotation.

Conway's Law is central to this decision: organizations produce system designs that mirror their communication structures. A small, tightly-coupled team naturally produces a monolith. A large organization with autonomous teams naturally gravitates toward microservices. The architecture should match the organizational reality, not the other way around. Many failures come from adopting microservices prematurely -- before the team is large enough to absorb the operational overhead, or before domain boundaries are well understood, leading to services that are too fine-grained and tightly coupled.

A monolith is like a single large kitchen where all chefs work together to prepare every type of dish. They share the same counters, ingredients, and ovens. Communication is instant -- a chef can glance over and see what another is doing. This works well for a small restaurant. A microservices architecture is like a food court where each stall specializes in one cuisine -- sushi, pizza, salads. Each stall has its own kitchen, inventory, and staff. They can scale independently (add more pizza ovens during lunch rush), use different equipment, and operate at different hours. But coordinating a combo meal that includes items from multiple stalls requires a ticket system, and if the sushi stall goes down, the combo meal fails even though pizza and salad are fine.