On launching a distributed system to global markets

Description

N26 has a mission to build the bank the world loves to use. While it’s currently live in countless countries in the EU, the company plans on launching in the US later this year, and also has immediate plans for Brazil and beyond. Launching in global markets presents some fascinating legal, business, and especially technical challenges. N26 wants to launch a core global product while also ensuring that user data is isolated in its respective region. This desire raises questions of storing user data in their legal countries while ensuring that it can be fetched anywhere in the world, ensuring that certain data is globally unique, and determining how all this can be done while minimizing changes to its existing infrastructure.

Kat Liu explores some of the biggest architectural trade-offs and hardships N26 faced while deploying a completely new platform of services. She provides an overview of the company’s existing architecture, including the existing stack and region-agnostic core microservices. You’ll learn the main problems N26 faced—launching in the US with the same BE architecture, legal requirements of data isolation between regions, discovering where a user’s data sits and what to do if a US user goes on holiday in the EU, and deciding where to implement the request routing. Kat outlines the solutions, including choices for new data center architecture, the first iteration of replicating N26’s authentication service and the second iteration of building a layer on top of all services, master-master replicated database of hashed data that’s populated on signup, and adding routing logic to the edge-load balancer layers. The company’s frontend solution revolved around fetching the correct data center on login, caching the static data center endpoint, and making sure this satisfies further legal requirements. You’ll learn about how the company minimized trade-offs of dealing with eventual consistency and preventing some timing attacks. Finally, Kat examines the lessons the company learned, that eventual consistency may or may not work for you based on the use case, that being fully agnostic to data regions may allow room for exploration, to replicate as little as possible because it’s less prone to error and security leaks, and that legal requirements take priority.