Self-Contained Systems: The Microservices Alternative
Self-contained systems (SCS) offer a middle ground between monoliths and microservices by organizing software into independent vertical slices—each with its own UI, backend, database, and no runtime dependencies. This approach eliminates distributed complexity while maintaining modularity and team autonomy, making it ideal for business apps that don't require hyperscale.
The Monolith vs. Microservices Pendulum
The 15-Year Architecture Cycle
For the past 15 years, the industry has swung back and forth between monolithic and microservices architectures. Monoliths felt overengineered and fragile; microservices promised independence but introduced distributed complexity that most teams weren't equipped to handle.
Why Microservices Failed in Practice
Microservices were supposed to solve scalability and deployment issues, but 90% of systems didn't actually need that level of complexity. Teams made services too small (nanoservices), and the distributed nature created new problems: circuit breakers, distributed tracing, and DevOps overhead—all for products that didn't require Netflix-scale infrastructure.
The Big Ball of Mud Problem
When teams split a monolith into microservices, they often didn't solve the underlying architectural mess—they just distributed it. Poor modularity and tight coupling remained; they were just spread across HTTP calls instead of function calls.
What Are Self-Contained Systems?
Core Structure: Vertical Slices
A self-contained system (SCS) is an independent vertical slice of an application that includes its own UI, backend logic, database, and crucially, no runtime dependencies on other systems. Each SCS operates like a standalone app rather than a tightly coupled service.
The Magic: Boundaries, Not Technology
The power of SCS lies in clear business-aligned boundaries, not in any particular technology choice. These boundaries eliminate the need for circuit breakers, distributed tracing, complex DevOps pipelines, and the anti-pattern of a monolithic frontend calling dozens of tiny APIs.
How Self-Contained Systems Communicate
Minimal, Decoupled Communication
SCS systems communicate sparingly—either through UI links (user navigation) or asynchronous, event-based messaging. This keeps systems truly independent and avoids the synchronous coupling that plagues microservices architectures.
Echoes of 1990s Modular Design
SCS resurrects the principles of modular applications from the 1990s—small autonomous teams, business-aligned boundaries, and clear separation of concerns—but applies them with modern infrastructure and event-driven patterns.
Real-World Success: ERP System Refactor
Spring IO 2025 Case Study
At Spring IO 2025, teams shared success stories of splitting legacy ERP systems into self-contained systems. Each team owned their slice end-to-end (UI, backend, storage), and data sharing used event replication. The result was cleaner, more maintainable, and scalable in the right way.
When to Use SCS vs. Microservices
Right Tool for the Right Problem
Microservices are justified for real-time trading platforms with thousands of concurrent users and true hyperscale needs. Self-contained systems are better for business apps, internal tools, and systems that don't require distributed complexity—which is most enterprise software.
Avoid Complexity Theater
Don't adopt microservices or complex distributed architectures just to feel modern. If your system doesn't have genuine scalability constraints, self-contained systems offer modularity, team autonomy, and maintainability without the operational burden.
Notable quotes
The magic of SCS isn't in the tech. It's in the boundaries. — Presenter
90% of systems didn't need it, and in general people started to associate the idea of monolith with legacy bad software. — Presenter
You still have the same mud, but now it is distributed all over the place. — Presenter