Self-contained systems: a practical alternative to microservices for growing businesses

Microservices promised clean separation, independent deployability, and scalable teams. What many teams actually got was a distributed monolith with harder debugging, expensive network calls, and deployment pipelines that take longer to maintain than the product logic itself.

Self-Contained Systems (SCS) offer a different trade-off. They keep the modular separation that microservices aim for, but with simpler operational boundaries and less infrastructure overhead. That makes them particularly interesting for small and mid-sized teams that need structure without hiring a dedicated platform team.

What a self-contained system is

A self-contained system is an independent web application that owns its own data, its own UI, and its own business logic. Each SCS communicates with other SCSs through well-defined web APIs or asynchronous messaging. The key difference from microservices is that each SCS is a complete vertical slice, not a thin service with shared dependencies.

In practice, an SCS might be:

• A product catalog application with its own database and admin interface
• A checkout system with its own order storage and payment integration
• A customer portal that runs independently from both

Each can be built, tested, deployed, and operated by a small team without coordinating deployments with the other systems.

Why this matters for smaller teams

Microservices require significant infrastructure investment before they deliver value. Service discovery, distributed tracing, API gateways, centralized logging, and container orchestration are table stakes. For a team of three to ten developers, that overhead can consume more time than the actual product work.

Self-contained systems reduce that burden. Because each SCS is a complete application, you can start with a monolith and extract SCSs as the business case for separation becomes clear. The infrastructure stays simple until complexity proves it needs to grow.

What the Spring I/O talk covers

The talk from Spring I/O 2025 (linked above) walks through concrete patterns for migrating from microservices to SCSs, including:

• How to identify bounded contexts that work as standalone systems
• Data ownership strategies that avoid shared-database coupling
• API design for SCS-to-SCS communication without tight coupling
• Deployment strategies that let each SCS evolve independently

The speaker presents SCS not as a replacement for all microservice use cases, but as a viable option for teams that adopted microservices prematurely and now feel the cost.

When to consider self-contained systems

SCS makes sense when:

• Your team is small but expects to grow
• You need clear domain boundaries without infrastructure overhead
• You have a monolith that is well structured but needs clearer separation
• You started with microservices and the operational cost is too high

SCS is less suited for:

• Truly independent services that need separate scaling (microservices still win here)
• Systems where data consistency across boundaries requires distributed transactions
• Teams already running a successful microservice architecture without pain

Final thoughts

Architecture decisions should match team size, not industry trends. Self-contained systems sit between a well-structured monolith and full microservices, offering a practical middle ground for growing businesses that need modularity without the DevOps tax. The Spring I/O talk is a good starting point if you are evaluating this approach.

The full talk is linked above — about 45 minutes, practical examples, and honest about trade-offs.