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.

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.