Monolith — One App, One Deploy

One thing to build, one to deploy, one to monitor, one to alert on. No service mesh, no distributed tracing required to debug a request, no schema registry. A junior engineer can run the whole stack on their laptop in five minutes.

Rename a function, the IDE updates every caller. Move a column, write a single migration. Try the same across a dozen microservices and you'll discover what "distributed coordination" really costs.

"Save the order, save the customer, save the invoice — atomically" is one DB transaction. No sagas, no compensating actions, no eventual consistency to explain to the business.

An in-memory function call is ~1 nanosecond. A network hop, even on a fast LAN, is ~500,000 nanoseconds. Monoliths skip the network entirely for every internal call. They're often faster than the equivalent microservices system at small to medium scale.

Every team's PRs land in the same artifact. One bad change blocks all releases until it's reverted or fixed. With 5 engineers this is fine; with 200, it's a daily fire.

The reporting endpoint is slow and CPU-heavy. The login endpoint is fast and frequent. In a monolith, you scale them by adding instances of the whole app — wasting memory replicating login code to handle reporting load.

A memory leak in the analytics module crashes the checkout. A long-running report drains the connection pool away from real users. Without internal isolation, one weak feature can take down the whole product.

Without enforcement, internal modules import each other freely. After a few years you have a "big ball of mud" — every change touches half the codebase. This is what gives monoliths their bad name; it's a discipline failure, not an architectural inevitability.