We all strive for loosely coupled and highly cohesive systems, yet as products scale, it is not uncommon for architecture to drift towards a “distributed big ball of mud” where a single change requires cascading changes across multiple services.

In this talk, we’ll go behind the scenes of Wise’s architectural evolution. As we scaled from a company focused on international transfers to a global financial account, we faced substantial friction due to our tightly coupled systems. This led to a strategic shift in how we approach service boundaries and interactions.

We’ll dive into the core principle that guided this transition: treating each internal subsystem as a third-party product "sold" to other teams. We’ll unpack:

• The Red Flags: Two specific indicators that an interaction might be too coupled—when a provider knows exactly who its clients are, and when a provider exposes its internal logic to them.
• The Patterns: We’ll explore concrete solutions, such as shifting from "provider-pull" to "client-push" data flows and implementing clean gateways to encapsulate subsystems.

We will conclude by pondering the design decisions we're making today that may inadvertently hinder future product evolution, leaving you with practical tools to spot and avoid coupling in your own work.

Main Takeaways:

• Designing decoupled systems comes with an inherent cost; however, with the right principles and techniques, we can minimize this overhead while maximizing scalability.
• At Wise, we have been following a simple principle to avoid building a tightly coupled system: treat each internal subsystem as a third-party product “sold” to other teams.
• Two red flags to look for: when a provider knows who their clients are; when a provider exposes its internals to them.
• Two patterns to follow: favor client pushing data instead of service provider pulling it from client; have a clear gateway to the subsystem.