The modular monolith — the most underrated pattern in enterprise software

Modular monoliths have a resurgence after the craze of the microservices era. Hype happens, then the tech finally finds its place. Don't follow fashion, be honest what your team can actually deliver and maintain.

My medium-scale Tech North Star is built around this pattern — and its returning context: a core banking system, a complex end-user application in automotive, systems that need to integrate a dozen or so legacy calls and still let a team of twenty-ish people ship independently and fast.

That is harder to achieve than it sounds. The urge to scale up too early, especially for ambitious leaders to show off how they manage headcount, instead of how they succeed with less.

Just as microservices sound like the answer here. At this scale, with this team size, lacking the platform engineering enabling the real work, its just creates a distributed monolith — all the coordination overhead, none of the macro-efficiency.

A well-designed modular monolith gives you:

• Clear module boundaries that enforce team ownership without network calls bogging down the system and causing users to suffer a bad application experience.
• Integration seams that contain the chaos of legacy systems behind clean interfaces, so your team don't have to scrape their mind out at every feature implementation wrestling outdated legacy.
• A deployment model that a mid-sized team can reason about and operate without a dedicated platform squad, even on a Black Friday rush when every minute of uptime worth 100x revenue.
• ADRs that document why each integration decision was made — critical when the legacy system vendor changes or the integration contract shifts so blast radius is limited.

The package includes C4 diagrams at every level, decision records for the key integration choices, and a team structure recommendation that maps module ownership to squad boundaries.

You don't need to go distributed to go fast. You need to go reasonably modular.