As a senior backend engineer at Django Stars, I've accumulated nearly 5 years of experience working on an online platform for Molo Finance, the UK’s first digital mortgage lender. The stack our team works with here includes Django, FastAPI, and aiohttp for building backend services, Postgres and Mongo for managing data, React, Vue, and Next.js to build the frontend, and Terraform with Kubernetes to manage the infrastructure.
I feel that the tips below could significantly save time for developers on any major fintech project. At least, I'd have been grateful to come across a similar list earlier in my career, preparing me for the challenges ahead. Without much additional explanation, here's what I can share from my personal experience.
3rd-party APIs
Fintech app development almost always relies on 3rd-party API providers.
Implementing most of the features related to money handling requires mountains of data. 3rd-party providers save developers and users the bother of collecting and reprocessing it.
Integrations in fintech app development allow developers to spend less time reinventing numerous wheels and focus on their product's core instead. As the illustration suggests, 3rd-party services can be used for credit checks, KYC (Know Your Customer), transaction processing, regulatory compliance, and many other functions.
For example, Molo has a total of about 15 integrations. Our task is to get synergy out of them.
Fallback Plans
When there are many integrations, they occasionally crash. Think of it as an axiom.
Keeping this in mind, you need to build a fintech app as a reliable system. In other words, the app had better work even in case of failure of one or another 3rd-party integration.
In my practice, there were projects where this consideration was missed — which entailed continual suffering for the entire business. Such suffering is especially intense when the integration falls off at the early stages of the user flow (for instance, credit scoring). But there is an opportunity to improve the system's efficiency.
Independent Processes
Having subsystems can increase flexibility.
The essence of this approach is to separate the system's business logic and build small subsystems, each implementing a specific domain separately. Which means using microservices.
What's in it? Firstly, such a structure is more maintainable and scalable. (I'll return to this below.) Secondly, if one of the subsystems fails, it doesn't bring down the entire app. In other words, we can continue using other services. If, in addition, point 3 is taken into account and communication between the services is asynchronous, the customer may not even notice that something is wrong.
On the other hand, microservices have their drawbacks. Distributed systems bring additional complexity to testing and development, and when making changes to particular services, one must take into account their interconnection with others.
Of course, this approach may affect certain parts of the flow, but what's more important is that the system as a whole keeps functioning.
Background Processing
Strive to build a strong UX and asynchronous communication.
The more 3rd-party dependencies a fintech application requires, the more likely it is that some of them will be temporarily unavailable. At some point, it becomes almost inevitable. Meanwhile, when it comes to money, the app's dependable operation means more than convenience — it defines user trust in the platform.
Asynchronous communication between 3rd-party services and the main app can help anticipate interruptions and situations where this or that 3rd-party service requires time to process requests, and the customer has to wait instead of moving by the flow.
- Sync communication: The client expects a timely response from the service and might even block while waiting.
- Async communication: The client doesn’t block while waiting for a response.
The point is to set up a messaging system for all requests to the 3rd-party API where a response shouldn't necessarily be sent immediately. If an error occurs there, a retry pattern is activated. This looks like "knocking" on the integration until it responds. Once it responds, the app informs the customer that everything is okay and they can continue with the flow.
An alternative implies having a UX that allows the customer to proceed with the flow without stopping or waiting for an immediate response from the integration.
Background processing in fintech application development means that we don't block the customer from proceeding with the flow, or at least they don't need to wait for a particular response for ages when integration is down. With a naive (blocking) approach this may lead not only to poor UX, but potentially it can break the system down when all threads will be consumed.
Of course, don't forget the importance of proper communication with the customer through UX or notifications.
This is a sound strategy to prevent interruptions.
Software Design Patterns When Writing Code
This is extremely important.
If the architecture is not laid out correctly from the beginning, then later on (talking about years), the system will turn non-maintainable, which breaks the concept of Agile. That's why design patterns are crucial when deciding how to build a fintech app.
Miscalculations in this regard are less critical if the system is divided into domains and represented as separate small services. In this case, many things can be refactored later without worrying that the whole system will break due to the replacement of only one service.
Fintech App Building Tips
Here are some things to pay attention to in fintech app development:
- Switching/adding providers. Returning to the first point, one of my earlier articles details testing 3rd-party API layers in fintech applications. The central thesis is that, most likely, no integration sandbox can cover all the test cases app developers need. Therefore, you need to think about testing the flow in advance and be able to mock the data from the 3rd-party.
- Caching. When building a fintech app, integrations can be expensive. Their responses are better to cache — to save some cash.
- Always have a plan B. Concerning key integrations, the ability to quickly switch to an alternative provider is a must. A well-thought-out architecture makes this possible. Also, microservices help, for example, making it possible to replace only one service and release it for production without affecting others.
- Scalability. Above, I paid a lot of attention to concepts from distributed systems. Deliberating maintainability and reliability, I only in passing mentioned another vital component, scalability. It's necessary to build the project with anticipation of future scaling. And this is about microservices again. When it's the monolith, and some part of it needs expanding, that would require scaling the whole monolith with all the other components, which is expensive. In the case of microservices, it's possible to scale only one service, which is much more resource-efficient.
- Backups. Reliability is also related to any other “system crashes,” e.g., database-related. There should be replicas (copies) of the main database in different regions of the cloud provider. Say, if AWS falls in London, there is still a great chance that it will work in other regions of the world.
- Security. Multi-factor authentication, cloud-based deployment, and other measures such as those described by my colleague Alex Ryabtsev in his article on cybersecurity for mortgage software are better to foresee in advance.
- Infrastructure. It should be fully automated with the ability to deploy it without manual work. On Molo, we use Terraform for this purpose.
- Logs. It's essential to have plenty of logs. They should be available at any time for monitoring and debugging purposes. Logs are indispensable in tracking the app's behavior, improving security, identifying errors, and troubleshooting.
Of course, it's impossible to show all the pitfalls and reveal all the know-how in fintech application development in one short article. And yet, even being the tip of the iceberg, the tips I shared here may assist developers in creating their next big thing in fintech.
Similarly, giving a general answer to how much it costs to develop a fintech app is not easy. I'd only say that the cost can range from tens of thousands to hundreds of thousands of dollars, depending on factors such as complexity, regulations, and 3rd-party integration. However, if you contact Django Stars, our specialists can provide a more accurate evaluation of your project.
Top comments (1)
Hello, Soner! 👋 Welcome to the Dev community. 🎉 This is a great article. Thanks for sharing. 😎