Self-contained systems cut a large system along business domains into autonomous web applications. Each owns everything it needs — UI, business logic, persistence — and belongs to one team. The style trades a uniform application for independently evolvable, independently deployable, independently failing units.

The cut is the hard part: boundaries follow business domains (bounded contexts), not technical layers.

Self-contained systems: three autonomous web applications, each owning its UI, logic, and data, integrated through links and UI composition in the browser and asynchronous events below — no shared database.

How It Works

  • Each SCS is one deployable web application with its own database; one team owns it end to end.
  • Integration sits as high in the stack as possible: links first, then UI composition, async events last. Synchronous calls between systems are the rare exception.
  • Data a system needs from a neighbor arrives by async replication, so it keeps working while the source is down.
  • Teams share infrastructure — style guide, deployment platform — and avoid shared business code.

Failure Modes

  • A wrong domain cut surfaces as features that always touch two systems; the coordination the style was meant to remove returns.
  • Synchronous call chains creep in, coupling availability and stacking latency — the landscape degrades into a distributed monolith.
  • Neglected UI integration shows users the seams: inconsistent navigation, repeated logins, jarring style changes.
  • A shared “commons” library accumulates business logic, re-coupling systems through the back door.

Verification

  • Chaos check: stop one SCS in staging; the others keep serving their core functions.
  • A change-coupling report over the commit history shows features landing in one system; recurring cross-system features flag a wrong cut.
  • Traces confirm user-critical paths cross no synchronous system-to-system call.
  • Each system reaches production alone — release calendars contain no coordinated multi-system entries.
  • Microservices split finer: an SCS landscape counts a handful to a few dozen systems, each possibly containing services internally. SCS keeps the UI inside the unit; microservices usually externalize it.
  • Micro frontends supply the UI-composition techniques SCS integration relies on.
  • A modular monolith achieves similar change isolation inside one deployable — stronger consistency, weaker autonomy.
  • Event-driven architecture supplies the asynchronous backbone between systems.

References

  • scs-architecture.org — the canonical community description, with characteristics and FAQ
  • Building Microservices, 2nd ed. — Sam Newman (O’Reilly, 2021), on finding and owning boundaries
  • Micro Frontends in Action — Michael Geers (Manning, 2020)