Architecting Software for Leverage

What You'll Learn

1Hear about Nubank engineering team’s journey from startup to stability, the evolution of their domain model in time.

2Learn what were some of the leverage points that helped them along the way.

When a financial services startup is created, it’s fair to assume that it will have a small team of engineers who will have the knowledge and control about the whole system being created to launch the first products. With few people and limited resources, it's necessary to think of the best way to create leverage achieving the most with what's available.  

At that point, the domain is not fully clear, and neither the architecture characteristics necessary to support all products and customers that the startup will eventually have, so leveraging the team and resources to go to market as fast as possible and get early feedback is usually key for the company success.

As the company evolves, different aspects become the most important ones at that time, so architecture decisions need to take into account how to get the most leverage for those particular aspects.

At Nubank, the most valuable digital bank in the world, 7 years after launching its first product, the company grew to over 700 engineers and dozens of products in 3 countries, in a microservices architecture running on top of kubernetes and AWS with over 600 microservices written in Clojure. It becomes unviable to have all teams of engineers knowing how to deal with all the intrinsic complexities associated with financial products; so the leverage point became abstracting complexities into some core business platforms so just a single team has to deal with that specific complexity and the others can build new products on top of it with one less complexity to worry about.  

This talk will explain the architecture decisions taken throughout the lifecycle of Nubank, aiming to get the most leverage on what was more important in each company phase, from the very beginning until the current days.

Tell us a little bit more about your talk.

This talk is mostly about our experience at Nubank, how the company evolved and the system evolved with the company in a hyper-growth environment. I'll try to lay out the early stages, at first in a startup mode and the need to go fast, and make some choices acquiring a lot of technical debt to ship faster, then intermediate stages up to the reality we are now, where stabilization and leverage are more important than time to market. We are trying to act on the multiplier effect instead of just velocity. The talk will navigate you through the leverage points that we can get in the early stages, and what they are when we reach the maturity of the product or the company. 

How did things change for your engineering teams from early-stage to when stability became the most important?

In the early days, you are not sure about anything, you're not even sure if the company will succeed, especially on startups. Most of them will fail. You want fast feedback loops and ship stuff as fast as you can, or invest more on the feedback cycle rather than stability. You have a small team. We had a team where everyone met and knew each other, 15 engineers working extremely close, talking to each other on a daily basis, then we moved to a company with over seven hundred engineers, where that becomes impossible and no single person can have all the context. Instead of optimizing for velocity, you have to optimize for containing complexity or for a multiplier effect. It's like having a team dedicated to improving developers' productivity so that all the teams can benefit. 

That's the argument for moving from monolith to microservices, but you started as microservices. Any thoughts around that?

In the beginning, we are in that phase where we are not sure about anything, so the thing that we're most likely to get wrong is the domain model. You know what you know at the time, and you model against it, but things change. Even though we used microservices from the very beginning, we got the model wrong in some places. We started modeling around displaying information or organizing information. And when we eventually had to build our own in-house credit card system, we didn't have the full credit card domain in our heads. We were learning as we went at that time. Even though we had microservices, we also had subsystems of microservices. They are like subdomains inside the major domain. And because of the wrong modeling at the beginning, the boundaries between these subdomains were not well defined. Eventually, we had to redesign the system or rearchitect the system in a way that these boundaries were more explicit or more concrete. And this is what I'm going to talk about, platformization inside the company. From the system that is already running for millions of customers, extract platforms with defined boundaries around the subdomains of the system. So we contained the complexity of that subdomain and abstracted it to other users. Now that we have 700+ engineers, we don't have to have all the engineers with the whole domain in their heads, they can know the high-level definition of a domain, and use it, rather than having all the intricacies of that.  

What do you want somebody who comes to your talk to leave with?

I want people to leave with what are the leverage points that you can have on each stage of the company. Or what can make you go faster in the early stages, and what can make you continue when you reach a big scale either on the customer side or on the company side. This will be the focus of my talk.


Lucas Cavalcanti

Principal Engineer @nubank
Lucas Cavalcanti is a principal engineer at Nubank, the most influential Brazilian fintech, built as a service-oriented architecture leveraging Clojure and Datomic. Lucas is a functional programming enthusiast and proponent of best practices in software development with vast experience in real... Read more

Tuesday May 25 / 09:10AM EDT (40 minutes)

TRACK Architecting a Modern Financial Institution TOPICS Financial ApplicationsOrganizational PatternsMicroservicesDomain-Driven Design ADD TO CALENDAR Calendar IconAdd to calendar

From the same track

View full Schedule