The Modular Monolith: Scale Without Microservices

CodeOpinion (Derek Comartin)
CodeOpinion (Derek Comartin)May 21, 2026

Why It Matters

Following a modular-monolith strategy reduces early technical debt and operational overhead, enabling faster delivery and safer, incremental scaling when real load or team boundaries demand it. It helps organizations avoid costly distributed-system pitfalls until the benefits of physical separation outweigh the trade-offs.

Summary

In the video, Derek from codeopinion.com argues that many teams prematurely adopt microservices, messaging, multiple databases, and Kubernetes to “build for scale” they don’t yet need, adding unnecessary complexity and operational costs. He recommends defining clear logical boundaries within a single deployable monolith—a “loosely coupled monolith”—so modules have ownership and contracts while remaining in one repository and one database. This approach preserves the option to split services, introduce async processing, or add brokers later without paying upfront costs. Derek frames the advice around the 4+1 architectural views and stresses that logical separation is distinct from physical deployment.

Original Description

We often justify over-engineered architectures: 20 microservices, Kubernetes, and message brokers by saying "we're building for scale." But if you only have 500 users, you aren't building for scale, you're building for scale you don't have.
🔗 Kurrent
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
✔️ Join via YouTube
0:00 - The 500 User / 20 Microservice Trap
1:05 - Why "Scale" is a Vague Requirement
2:00 - Every Pattern Has a Trade-off
3:42 - Logical vs. Physical Boundaries
4:35 - The Distributed Monolith Trap
5:33 - The Loosely Coupled Monolith
6:48 - Adding Async Processing Pragmatically
8:20 - Why Messaging Doesn't Fix Bad Boundaries
9:55 - Temporal, Data, and Behavioral Coupling
10:28 - Building a Path for Scale

Comments

Want to join the conversation?

Loading comments...