The video on-demand of this session is available to logged in QCon attendees only. Please login to your QCon account to watch the session.

Session + Live Q&A

Architecting Software for Leverage

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.

Main Takeaways

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

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


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.


Speaker

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

Date

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

Track

Architecting a Modern Financial Institution

Topics

Financial ApplicationsOrganizational PatternsMicroservicesDomain-Driven Design

Add to Calendar

Add to calendar

Share

From the same track

PANEL DISCUSSION + Live Q&A Financial Applications

This Is What a Large-Scale Cloud Adoption Program Looks Like

Tuesday May 25 / 10:10AM EDT

We have seen countless stories of teams that transformed or migrated applications to the cloud. Yet there aren’t many insights into what it takes to move hundreds and hundreds of workloads, of various technologies, languages, and platforms.  In this session, you’ll hear some of...

Dio Rettori

Head of Cloud Architecture @jpmorgan

Session + Live Q&A Financial Applications

From Batch to Streams: Building Value from Data In-Motion

Tuesday May 25 / 11:10AM EDT

Most things in life are a constant flow of events. Falling in love, getting a mortgage, and becoming a parent are good examples. However, something usually goes unnoticed: most events ultimately lead to another, and there is an inherent correlation between them. You just need to look closer and...

Ricardo Ferreira

Principal Developer Advocate @elastic

PANEL DISCUSSION + Live Q&A Financial Applications

Panel: Challenges & Opportunities of the Modern Financial Institutions

Tuesday May 25 / 12:10PM EDT

In the panel, we’ll have the chance to discuss the challenges and opportunities of modern financial institutions with experts of different backgrounds and sectors of the financial industry, Dio Rettori, and Lucas Cavalcanti. With the key support of a broader view of the market from Camila...

Lucas Cavalcanti

Principal Engineer @nubank

Dio Rettori

Head of Cloud Architecture @jpmorgan

Camilla Crispim

Portfolio Technology Director @ThoughtWorks

View full Schedule