27.2 What are a monolith's strengths?

In the restaurant: In one kitchen, passing the paneer takes a second. A new cook learns everything in one place. You open and close at the same time. Nothing gets lost between stalls.

In the system:

• Simple to build, run and debug. One repository, one build, one deploy, one log stream. A stack trace shows the whole request.
• Fast calls. Modules call each other in-process, in microseconds, with no network failures, timeouts or serialisation.
• Real transactions. "Create order, reserve stock, record payment" can be one database transaction (Chapter 17). No sagas needed.
• Easy refactoring. Moving code between modules is a code change, not an API migration between teams.
• Cheaper to operate. One thing to monitor, secure, scale and keep on call.

Where it starts to hurt, usually as the team grows, not the traffic:

• Everyone deploys together. One team's broken test blocks everyone's release.
• Coupling creeps in. Without boundaries, any code can call any other, and changing orders breaks recommendations.
• One size of scaling. You scale the whole app even if only search needs more machines.
• One technology stack for everything.
• One failure domain. A memory leak in recommendations can take down checkout.

Many successful companies run large monoliths for years. Shopify, for example, runs one of the largest Ruby on Rails codebases in existence, worked on by more than a thousand developers.

Memory code: "One kitchen is fast and simple until there are too many cooks."

---