The Architecture Decision You Can Undo: Microservice Boundaries with Spring Modulith

We’ve spent a decade telling developers that microservices are the grown-up way to build software. That real engineers decompose everything into independently deployable services from day one. And we’ve spent that same decade dealing with the fallout. Distributed debugging. Eventual consistency headaches. Integration tests held together by prayer. And teams that can’t ship a feature without a cross-team deployment ceremony.

What if the whole premise was wrong? Not microservices themselves, but the timing. What if the right number of services at the start of a project is one?

Using Spring Modulith, I’ll show you a monolith with boundaries that most microservice architectures would envy. Enforced by tests, not by network latency. Modules that can be extracted when the pain is real and put back when it isn’t. This isn’t a talk about choosing the right architecture. It’s a talk about building one that lets you change your mind.

Because the decisions that matter most are the ones you can undo.

What you’ll take home

• A rule you can use on Monday: direct calls when you need the answer now, events when you need the reaction eventually — and how Spring Modulith turns that rule into something the build enforces.
• How to bolt a new capability onto a live business flow with zero changes to existing modules — one listener class, nothing else.
• Why async doesn’t mean decoupled: listening to an event is still a dependency — and Modulith’s cycle report will show it to you.