Monolith

A monolith is one program that does everything your product needs. The signup flow, the payment logic, the email sender, the reporting screens, and the database queries all live in the same repository and compile or package into a single deployable artifact, like one JAR file, one container image, or one Rails app.

When you run it in production, every feature shares the same process and the same memory. A function calling another function is a normal in-process call, not a network request. That is the defining trait: components talk to each other directly inside the application instead of over HTTP or a message queue.

Monolith is not an insult. The first version of almost every successful product is a monolith because it is the fastest way to ship. Shopify, GitHub, and Stack Overflow have run enormous monoliths for years. The word only describes the deployment shape, not the code quality.

The whole application is built into one artifact. A typical Java monolith compiles into a single WAR or fat JAR; a Python one is a single app served by Gunicorn; a .NET one is one published service. You deploy that artifact to a server or container, and it boots as one operating system process.

Scaling is done horizontally by running more identical copies behind a load balancer. If checkout traffic spikes, you cannot scale just the checkout code, because checkout is not a separate thing you can run alone. You add more full copies of the entire app, even though only one module is busy. This is the main cost of the model.

State usually lives in one shared relational database that every part of the app reads and writes. Because all calls are in-process, a request can touch the user table, the order table, and the inventory table inside a single database transaction, which makes data consistency simple to reason about.

Reach for a monolith when the team is small, the product is still finding its shape, and you want one place to build, test, and debug. With everything in one process there is no network latency between modules, no distributed tracing to set up, and one deploy pipeline. Local development is starting one app, not orchestrating fifteen.

The pain shows up at scale. A monolith forces one language and one runtime on everyone. A single bad deploy can take down every feature at once. Build times grow until a one line change takes ten minutes to ship. And you cannot give the CPU-heavy image processor more cores without also paying to run more copies of the lightweight login page.

The honest answer for most teams is to start with a well organized monolith, keep clear internal module boundaries, and only split a piece into its own service when a real problem demands it, such as one component needing independent scaling, a separate team owning it, or a different runtime. Splitting too early buys you distributed systems complexity before you have the scale to need it.

Picture an online store as a monolith. A customer clicks Place Order. The web layer receives the request, the order module validates the cart, the inventory module decrements stock, the payment module charges the card, and the email module queues a receipt, all as ordinary method calls inside one running process, wrapped in one database transaction. If the payment fails, the transaction rolls back the stock change automatically.

Now the store goes viral. Order traffic is ten times normal but everything else is calm. To handle it you spin up twenty more copies of the entire store app behind the load balancer, each carrying the full code for browsing, search, admin, and reporting that nobody is hammering. It works, but you are paying to scale code that does not need scaling.

That tension is exactly where teams start carving the busy parts out into separate services. Until that point, the monolith was the right call, and trying to be clever earlier would have slowed the product down.