Monolith Advantages

The four main advantages are simplicity, easy deployment, easier debugging and local ACID transactions. Simplicity means one codebase, one process and one database, so there are fewer components, technologies and failure modes to build, secure and operate. Deployment is one artefact through one pipeline, with no cross-service version coordination or contract drift. Debugging is easier because a request runs in one process with a complete stack trace and one log stream. Transactions spanning modules commit or roll back together. These advantages are not trivial: they translate into faster time to market, lower infrastructure cost and shorter incident diagnosis, and every move to distribution should be justified by drivers that outweigh losing them.

Because the whole request executes in one process, so every tool sees all of it. The IDE debugger can step from the controller through pricing, inventory and order code without crossing a network. A failure produces one complete stack trace showing the full call chain, and logs arrive in one stream with the same thread and correlation context. JFR or async-profiler can profile the entire request, and a Testcontainers-based full-system test reproduces it in one JVM. In microservices the same request spans several processes and logs, often with partial failures, so you need distributed tracing just to find which service failed. The note's example puts median root-cause time at 25 minutes versus three hours.

In a monolith a business operation spanning modules runs in one local ACID transaction on one database. With Spring's @Transactional, reserving stock, saving the order and awarding loyalty points share one connection and one transaction manager, so they all commit or all roll back, and invariants such as stock never going negative can be enforced with a row lock. In microservices each service owns its database, so there is no shared transaction. You need a saga with compensating actions, an outbox for reliable events, idempotent handlers and acceptance of visible intermediate states. The note's example shows the gap: one 80-line method versus a saga with 1,200 lines of failure handling.

MonolithFirst is Martin Fowler's heuristic that most new systems should start as a monolith, preferably a modular one, and split only when the need is proven. The reasoning is that early on you do not know the domain well enough to draw stable service boundaries, and wrong boundaries are far more expensive to fix across services than across modules. Starting with a modular monolith gives you speed, simple operations and local transactions while you learn. When boundaries have stabilised and a real driver appears, such as many teams or divergent scaling, you extract the module that needs it. The note's fintech example extracted its first two services only at 60 engineers.

Protect the single pipeline so it stays fast and safe as more people commit. Trunk-based development with short-lived branches avoids long merges, and feature flags let teams merge unfinished work without releasing it. Build time is the main threat, so use modular builds, a build cache, parallel test execution and module-scoped tests on pull requests, with the full suite on main; the note shows these cutting pipeline time by 40 to 70 percent. Enforce module boundaries with Spring Modulith verification so one team's change does not break another's. Keep releases rolling or blue-green on Kubernetes with readiness probes, and keep rollback as simple as redeploying the previous image.

Use in-process application events with Spring Modulith's event publication registry. A module publishes a domain event such as OrderConfirmed inside its transaction, and listeners annotated with @ApplicationModuleListener run after commit, asynchronously and in their own transaction. The registry stores each publication in a database table in the same transaction as the business change, marks it complete when the listener succeeds, and lets incomplete ones be resubmitted after a failure or restart. That gives you the decoupling of events, with modules that do not call each other directly and side effects such as notifications off the request path, without a broker, network calls or a second deployable. The events can later be externalised to Kafka.

Try the cheaper scaling options first, because most hot spots can be fixed inside the monolith. Start by measuring which module is hot and why, using per-module Micrometer metrics and profiling. Then optimise that module's queries and indexes, add caching for read-heavy data, and route reporting or listing reads to a read replica. Scale horizontally by running more instances behind the load balancer, which works as long as the application is stateless. Isolate noisy work with separate executors, thread pools or bulkheads, and move background jobs to a separate deployment of the same artefact if needed. Only if one module still needs very different scaling or availability is extraction justified.

I would argue from drivers, not taste. First I list the business drivers, such as time to market, strict consistency, team size and expected load, and map each to the four advantages: simplicity, single-pipeline deployment, debugging and local transactions. Then I quantify what distribution would cost: extra infrastructure, a platform with mesh, broker and tracing, sagas for cross-module invariants and slower incident diagnosis. I propose a modular monolith with enforced boundaries, Spring Modulith verification and in-process events, so a later split stays cheap. Finally I record explicit revisit criteria in the ADR, for example more than 30 engineers or divergent scaling, so reviewers see a deliberate, reversible choice.