When to Choose Microservices Over Dynamically Scaling a Monolith

What Dynamic Scaling of a Monolith Can Solve

Deploying a monolithic application as a cluster behind a load balancer can handle increased traffic and eliminate single‑point failures. Adding machines distributes requests and shares the load, which is sufficient for many companies whose only problem is throughput.

Core Modules Dragged Down by Edge Modules

All functions run in the same process, sharing thread pools, memory, CPU, and database connections. In the author’s former company, order, payment, and inventory logic co‑existed with reporting and activity pages. A slow SQL in the reporting module occupied the DB connection pool for dozens of seconds, causing order requests to time out as well.

Scaling the cluster to ten machines does not help because each instance runs the same code; the reporting module can still block the order module on every machine. Splitting the core modules (order, payment, inventory, etc.) into independent services isolates failures: edge‑case problems no longer affect the stable core, providing process‑level isolation that adding machines cannot achieve.

Collaboration Efficiency Bottleneck

When many developers work on the same codebase and service, merge conflicts become frequent, and releases must wait for all teams. Adding more machines does not reduce code conflicts or eliminate the need for coordinated deployments.

Splitting services also splits team boundaries: each team owns its service, develops, tests, and deploys independently. This reduces friction and aligns with Conway’s law, which states that system architecture mirrors the organization’s communication structure. The author notes that the problem becomes pronounced when a team exceeds 15‑20 members.

Resource‑Characteristic Differences Cause Configuration Conflicts

Operations such as PDF parsing, large file uploads, email fetching, and OCR are long‑running, memory‑intensive, and require special timeouts. Placing these alongside core CRUD operations forces a compromise: core services cannot have a 30‑minute HTTP timeout or an 8 GB heap, yet the resource‑heavy tasks need them.

Running these tasks in a separate resource‑focused microservice allows distinct configurations (e.g., 8 GB heap, 30‑minute timeout, larger file size limits) while keeping the core service lightweight and responsive. Scaling a monolith to meet the resource‑heavy needs would waste resources during normal operation and still risk OOM in the core process.

When to Split into Microservices

Core link affected by edge module : non‑core failures make core APIs unavailable; adding machines cannot help; recommendation – deploy core modules independently.

Team collaboration efficiency drops : frequent merge conflicts, release waiting, high onboarding cost; adding machines cannot solve; recommendation – split services by team boundaries.

Large resource‑characteristic differences : operations exceed 10 s, use >100 MB memory, need special timeouts; adding machines cannot reconcile configs; recommendation – split by resource consumption.

Different release rhythms : core modules need stable, infrequent releases while edge modules iterate fast; monolith forces whole‑system releases; recommendation – independent services with independent deployment cycles.

Traffic overload : QPS exceeds single‑machine capacity; adding machines can solve; recommendation – simple cluster scaling, no microservice needed.

When Microservices Are Not Needed

Teams of 5‑10 people with modest traffic and no signals listed above can keep a monolith and scale it as needed. Distributed systems do not make slow code faster; they add network latency (nanosecond‑level in‑process calls become millisecond‑level RPCs). A flow that traverses four or five services can add over 200 ms of latency.

Microservice adoption also brings new costs: network communication, data consistency, distributed transactions, tracing, and service governance. Each requires additional infrastructure and personnel. Without a dedicated platform team, service governance may lag, leading to more failures than a well‑run monolith.

Conclusion

Microservices and cluster scaling solve different layers of problems. Scaling addresses throughput, while microservices provide isolation and improve team collaboration. In practice they are complementary: first split the system into services where isolation is needed, then scale each service independently. The decision should be driven by business needs and concrete signals, not by technology hype.