7 reasons for using microservices in fintech app development

In the modern app consumer space, where speed and reliability are paramount, microservices are the way to achieve these goals.

In 2021, roughly 71% of organizations adopted microservices, with 37% doing it partially.

While the approach involves more complexity, organization, and monitoring systems, the end results are worth the effort.

For example, microservices can increase productivity by up to 50% and decrease overhead costs by half on average.

Now, if you’re having doubts about adopting microservices in your next fintech app project, here are a few points for you to consider.

Agility

Agility is perhaps the first reason to adopt a microservices architecture. 

Because major app functionalities are broken down into independent components, it’s very easy to add, remove, and upgrade them as the need arises. This allows developers to quickly adapt to new technologies, user complaints, or market changes.

Indeed, the firm Accenture Solutions IQ found that the average time to market was reduced from months to mere days or even hours when they implemented microservices on their projects.

Amazon was one of the early tech companies that realized the need for microservices. Back in 2001, their entire website was monolithic; essentially, it was one gigantic program. Thus, even tiny changes required testing and updating the whole system.

It was very inconvenient. As Amazon executive Rob Brigham recalled:

“Even when you have that big, large, new version, it still adds a lot of overhead on this delivery pipeline. That whole new code base needs to be rebuilt. All of the test cases need to be re-run, to make sure there have been no rushes. And then you need to take that entire application, and deploy it all to your full production fleet.”

This led Amazon to adopt a decoupled architecture known as Amazon Web Services (AWS). As a result, Amazon can now deploy code roughly every 11.7 seconds.

Let’s use Uber’s architecture to illustrate further how microservices can speed up development time:

Instead of a single development team working on the entire app, Uber can delegate each component to separate groups, thus allowing the development of these features to happen simultaneously.

Furthermore, if Uber wanted to implement new technology for their Trip Management system to change the process of their Payments system, they only need to work on those components while leaving everything else intact.

And because everything is self-contained, there’s no need to re-test the entire system either.

This ability to rapidly add and expand app features ultimately helps in what is perhaps the holy grail of every tech app: scaling.

Scalability

If there’s one thing that drives companies to adopt microservices, it’s scalability. That’s because scaling an app to millions of users is virtually impossible and astronomically expensive for a monolithic setup.

To illustrate why, let’s take Paypal’s transition into the microservices architecture they use today. Just a few short years after it debuted in October 1999, Paypal started quickly growing its users and transaction volumes.

But their monolithic app was hindering them from scaling rapidly.

For one, they could only update the program fixes during off-peak hours to minimize service disruption as much as possible. It also required coordination from the entire dev team to implement even the small changes.

And that’s just a small part of a whole laundry list of scalability issues:

Source: Postman / Paypal

There was also the problem of programming language compatibility. In its early years, Paypal used a system called CIPRO that allowed services to communicate with each other.

The problem is that CIPRO used C++, which means it could only talk with other components that also used C++.

The ultimate solution for all of these problems, among others, was the development of the Paypal as a Service (PPaaS) architecture. This system allowed a uniform API scheme for all internal and external service requests (using REST API).

PPaaS has not only allowed the expansion of Paypal’s internal systems but also enabled third-party developers to connect with Paypal’s services using the same API calls. That’s indispensable if you want to scale any application rapidly.

But there’s another hidden benefit of microservices for scalability: efficient use of resources.

One interesting study has shown that microservices are less resource-intensive than monolithic apps. This is all thanks to smarter allocation algorithms that make the best use of what’s available.

You can see it in this diagram, where the orange dots represent instances in a microservices app.

Ultimately, efficient use of resources also leads to lower costs of running each instance of a microservices app. There’s a “sweet spot” when this happens, however, and that’s when microservices are running only 70% of the time:

Still, the conclusion is undeniable: breaking your system into manageable components is the cheapest and most efficient way to scale it.

Reusability

Because the components of a microservices app are self-contained, you can do whatever you want with it without affecting the rest of the system. This also means that parts are highly reusable.

Let’s see how this can impact a banking app. First, here’s a comparison of a typical fintech app using a monolithic versus a microservices approach:

See the Fund Transfer microservice? Because it’s an independent component, you can implement that feature into other fintech apps (for example, a bank that wants a personal finance app and a lending app) without having to build it from scratch. 

That also means that whenever you update the Fund Transfer component, the changes automatically propagate to every app or feature that relies on it.

For example, Amazon Pay is a microservice that allows third-party developers to embed the Amazon Pay checkout option to their e-commerce sites via API calls. This is a viable option for developers who don’t want to create a payment function from scratch.

Source: Amazon

This kind of flexibility is simply not possible with a monolithic approach. Reusability is vital if you want to scale rapidly, update your app quicker, and reduce development overhead for a better bottom line.

Easier maintenance

It might seem counterintuitive, but managing a microservices app is actually easier than a monolithic one. How is that possible if you’re dealing with thousands of discrete components, as opposed to one giant block of software?

The answer is that microservices often have better tools and methodologies to handle a large number of components effectively.

For example, the Monzo app system architecture is composed of a mammoth 1,500 individual services that, while self-contained, are often part of larger functions.

As a result, even a simple swipe from a Monzo card requires a dozen or so services to process it.

Here’s a quote from Monzo engineer Matt Heath on how they can manage to update fixes on multiple services at this volume:

“We have tools around that. We have lots of testing around these things. We have lots of tooling that allows us to initiate rollout, and if that’s not working well, it will automatically roll back. Because we have those safety mechanisms in place, we can do that with a quite high degree of confidence.”

Monzo also relies on its mono repository to allow efficient versioning and testing of every service it’s running. This gives a “single source of truth” that makes running a battery of tests easier on either specific or interrelated services.

In many ways, a mono repository is a monolithic approach to managing a microservices architecture—and it works well.

Plus, you can easily diagnose app bugs by focusing on the cluster of microservices that’s responsible for it. Also, fixing them is simple and straightforward, and it doesn’t require shutting down your entire app.

The bottom line is that microservices facilitate apps that run 24/7—even when maintenance Is involved.

High reliability

A microservices approach doesn’t just impact development; it can also enhance an app’s real-time performance and availability.

For example, Netflix encountered a data corruption issue in 2008. Unfortunately, this single point of failure closed down their entire DVD rental service for days, which was a significant hit to their operations.

It was the impetus that led Netflix to transition to a microservices approach. Fast forward to today, and Netflix enjoys a flexible architecture that’s much more resilient to such outages.

This is because, when a microservice fails, the system simply brings up an instance to replace it. Netflix even deliberately terminates random services to test this resiliency in real-time.

A well-executed microservices architecture also delivers better performance than a monolithic app. 

In an earlier section, we’ve already touched on one aspect of this—resource allocation. But, beyond this, microservices can also help improve CPU and latency. And usually, enhancing the performance of one component can cascade to other services as well.

This is what the Monzo app team experienced. When they tweaked their code to reduce the CPU time of their data store module, they saw a significant latency and CPU usage drop on the entire system.

Source: InfoQ

Walmart Canada is another great example of how a microservices approach helped improve system performance significantly. At the time, the website was struggling with its legacy systems that could barely keep up with its traffic of 6 million views/minute.

And when Black Friday hit, the site just ground to a screeching halt. Customers felt it and weren’t too happy about it.

Source: Legacy Typesafe YouTube channel

However, after their microservices transition, Walmart Canada saw incredible gains almost overnight. They achieved a 20% improvement in their conversion rate with zero downtime. They even saw operational cost savings of up to 50%.

Specialization

Microservices also allow development teams to specialize in specific features during development. Not only does this speed up development time, but it also simplifies maintenance and even improves the quality of the output.

Adopting the right approach to microservices allows you to break down a complex app and abstract it into simple components that are easier to work with, as Monzo did successfully. 

After all, according to engineer Matt Heath:

“You don’t need to know how 1,600 services work.”

This means that teams only need to worry about their component since each individual service should work in its context. So, for instance, developers don’t need to know the intricacies of managing containers and VMs; that’s someone else’s domain.

This sense of ownership and abstraction is a fantastic way to streamline the development process of otherwise complex applications.

It also allows you to allocate talent much more efficiently. Consider that a typical microservices architecture separates the UI, logic, and data functions into discrete services.

With this setup, you can form a team of UX experts and designers to work on the UI portion of the app, while developers and engineers can work on the microservices.

Thus, your talents are much more focused on the areas where they can make the most impact.

Simplified integrations

Finally, microservices facilitate faster and more efficient integrations between different components in your software. This is crucial for fintech because you often need to connect with other financial institutions and banks.

For example, the Open Banking initiative allows apps to interface with banks to facilitate records and transactions safely. Rather than program the integration for each platform, Open Banking API will enable you to rapidly add institutions without touching the code.

Source: Fortunesoft

A microservice architecture also makes it easy to integrate third-party tools and libraries into your app. That’s because your system is flexible enough to accept these services without having to hard code them in.

For instance, Plaid acts as an intermediary that connects a user’s bank account and other fintech platforms like Venmo and Robinhood. So if you want to quickly add Know Your Customer (KYC) capabilities for compliance, Basis ID can do that for you.

You can often implement these tools and libraries with a few lines of code. And if it’s not working out, you can replace it with another third-party tool.

Microservices are the future of fintech

We’ll be honest—fintech isn’t an easy industry to be in.

The constant demand from consumers and regulation means developers must constantly adapt to make it through.

But with proper implementation of microservices, fintech apps can have the speed, flexibility, and performance to survive and thrive.

Of course, microservices have complexities that can bring more trouble than they’re worth—if you don’t know how to navigate them. That’s why you need an experienced agency like DECODE to harness its power properly.

Ready to talk? Schedule a session with us today!