INNOQ published a primer on Self-contained Systems in August 2026, written by Johannes Seitz. I read it with one question in mind: Does it match what I say in my talks and in my Java Magazin article?

A note before you read on: the primer is only available in German. If you do not read German, the rest of this post still works as a summary of where I agree with the current SCS thinking and where I see it differently.

Short answer: yes, in the core. The primer is good, compact and honest about its trade-offs. But there are three points where I set different priorities. Those are more interesting than the agreements, so they get more room here.

Where we agree

The core of the architecture style is described the same way I describe it: cut the system along business capabilities instead of technical layers, give every system its own UI, its own business logic and its own data storage, use asynchronous integration as the default and synchronous calls only as a well justified exception.

I liked the section about the data trap. The primer says clearly that shared data is a bad criterion for module boundaries and that there is no master data system for “customer” or “contract”. Next to it stands the process trap, the reflex to draw system boundaries along the steps of a flow chart. I see both mistakes in customer projects again and again. The primer uses Parnas and information hiding as the test for a good cut, which fits my own argument: modularity is a design topic, not a deployment topic.

The conclusion matches my position too. The monolith was never the problem. The problem was its tendency to grow without control. Stefan Tilkov’s line, that we love monoliths so let us build many of them, says it well.

The failure modes of messaging are covered properly: transactional outbox, idempotent receiver, dead letter queue, durable subscriptions. Anyone who saw my talk knows the example with the duplicated deliveries. Exactly that class of problems is named in the primer, together with the patterns that solve it.

Point 1: The modular monolith is missing as a middle step

The primer goes from the grown monolith almost directly to the first carve-out. It names the threshold where the effort pays off, which is when coordination, testing and deployment have become expensive. But between “large monolith” and “first independent system” there is another step for me: the modular monolith.

For a large part of the business applications I work with, a well modularised monolith with Spring Modulith is the pragmatic choice. One deployable, one database, but clear module boundaries that are also verified. You get the most important part of the benefit, the business oriented cut and control over coupling, without paying for the operation of a distributed system.

Self-contained Systems are worth it when several teams have to develop and deploy independently. That is an organisational threshold, not a technical one. If you have not reached it yet, you can practise your module boundaries inside the monolith and extract them later. The primer describes the carve-out very well, but one chapter earlier I miss the honest statement: maybe you do not need distributed systems at all yet.

Point 2: The UI integration is too JavaScript heavy for me

The chapter on UI integration starts in the right place, with links, transclusion, server side includes and edge side includes. Then it moves on to web components, Angular custom elements and module federation.

My implementations are server side Java. Vaadin renders the user interface, the integration works through links and redirects, through transclusion and through a shared design system. In practice this carries you surprisingly far. The primer mentions these ways, but treats them more like a first stage before the component based approaches.

What I miss completely are the ROCA principles. Resource-oriented client architecture is almost a natural fit for SCS: meaningful URLs, HTML rendered on the server, the application still works without JavaScript, no shared client state. If you build this way, the loose coupling between the user interfaces comes almost for free.

On module federation I am more sceptical than the primer. It names the drawbacks correctly, so shared runtime, shared dependencies, a proprietary library as a mandatory part of the macro architecture. But for me this is no longer a trade-off, it is a contradiction to the style. You build systems that can be deployed independently, with a lot of effort, and then you couple them again in the browser. If such a tight integration is really needed, that tells me the business cut is probably wrong.

Point 3: Single sign-on deserves more than a side note

Authentication and authorisation appear in the primer under the cross-cutting standards, and the UI integration chapter mentions that all frontends have to run under the same domain so that a shared session cookie works.

From my project experience this is one of the first things you stumble over. As soon as a user moves between two systems and has to log in again, the seamless experience is gone, and the nice architecture feels like a step backwards for the business department. A shared single sign-on belongs, together with the design system, into the mandatory part of the macro architecture, not into a footnote. The same goes for the question where the shared navigation lives. The primer does discuss that at the end, including the uncomfortable truth that a central frame creates a single point of failure.

One half sentence with a future

At one place the primer mentions that coding agents can partly cover missing specialisations in a team. It is only half a sentence, but an important one.

A Self-contained System should be owned by a small team, from the idea to production. In practice this is often where it breaks: the team has no database expertise of its own, no test automation specialist, nobody for the pipeline. What interests me here is less the speed of writing code and more the question which artefacts a team needs so that agents can work well inside a bounded system. An SCS is an almost ideal size for that: a manageable context, its own database, its own user interface, clear interfaces to the outside. That is a topic for another article, but it is the point where architecture meets the way we will build software in the future.

Conclusion

The primer is worth reading, especially for architects who have to cut their system landscape again. It is honest about the trade-offs, and the chapters on domain architecture and messaging are the strongest ones.

If you come from the Java world and work with Spring Boot and a server side UI framework, read the UI chapter with some distance. And before you split your system, ask yourself whether you really have several teams that must deliver independently. If not, start with clean modules inside one deployable.

Keep IT simple.