Abstract
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.
Interview:
What is the focus of your work these days?
The majority of time in my day is spent collaborating across teams to design a global account platform that banks and partners can use to bring a ‘money without borders’ experience to their customers. Recently, I’ve been focused on scaling Wise Platform’s third-party payment capabilities, creating a unified gateway for partners to receive payments in multiple currencies globally.
And what was the motivation behind your talk?
I believe that when directed towards the right missions, software development has the potential to bring positive change to society. Wise's mission of ‘Money without borders’ is one such mission, but certainly not the only one. In this talk, I want to share our shortcomings and learnings on how to build a decoupled system that evolves in pace with ever-changing customer needs, so that these principles and techniques can be used to power other important missions.
Who is your talk for?
- Architects, Staff+, and Technical Leads keen to add principles and techniques for designing decoupled systems to their toolbelt. It is particularly suited for those looking for a simple, yet powerful, message to advocate for within their teams and organisation.
- Senior Engineers looking to strengthen their understanding of how to build a decoupled system. In particular, those looking for clear “red flags” to avoid and patterns to follow.
Speaker
Andrei Tognolo
Staff Engineer @Wise, 19+ Years in Software Engineering, Previously Senior Consultant @ThoughtWorks
With nearly 20 years of experience in software engineering, Andrei is a Staff Engineer at Wise, where he has spent nearly a decade building a robust global financial system. Prior to Wise, he was a consultant at ThoughtWorks, where he focused on technical excellence. His current mission is to identify and reduce accidental complexity through elegant solutions, ensuring that Wise’s architecture remains robust and easy to extend as the system grows in scale.
Find Andrei Tognolo at:
Date
Monday Mar 16 / 01:35PM GMT ( 50 minutes )
Location
Fleming (3rd Fl.)
