When building an extremely complex platform like a fintech app, most of the time you come up with a “wishlist,” including all the “must-haves” you want to have in the product. For a financial app, it contains literally everything, and your list will look something like:
100% security
100% fault tolerance
100% reliability
100% scalability
100% flexibility
and so on, so on…
However, that seems to be theoretically impossible. It’s like asking a small kid in a toy store, “What do you want?” The obvious but not pleasant answer will be, “Everything and right now!” The product must be reliable, it must comply with the law in a particular area, and it must be flexible and scalable so that you can build on top of it to customize the functionality that it has (and add new functionality).
On the road to your perfect fintech product, the first question you will have to answer is what strategy to choose while building your app’s architecture. While the choices seem almost unlimited, all options have their advantages and disadvantages at different stages of business growth. In this article, we’ll take a look at different approaches to fintech architecture to help you create a winning strategy for your product.
The Fragile Balance Between Stability and Scalability: the CAP Theorem
Any great Fintech idea will not transform into an effective and competitive product without a good app architecture. While developing any IT system, we always prioritize business requirements, and financial systems aren’t an exception. That’s why it’s not a really good idea to base the system on technical requirements, such as for example, desired technologies, as they are secondary. As all systems are unique in functions and requirements, apps’ architectures will also vary. So, how can we describe a good financial system architecture? Let’s take a look at one example and describe all possible options.
Typically, at MobiDev, we start with defining core business requirements, and they can be described as a user or business flow. By analyzing business requirements, we better understand particular business goals, and this understanding allows us to formulate functional and non-functional requirements for a future system, considering the “list of key quality attributes” and “particular metrics for every quality attribute”.
Those are attributes that play a key role in the following planning of the financial app, as their implementation directly depends on chosen architecture or the offered technology stack. Unfortunately, not all attributes can be combined with each other. In fact, we are unable to meet all the requirements that we have for our app. One of the proofs of this statement is the CAP (Consistency, Availability, Partition tolerance) theorem, which can be applied to the whole system.
If we take into account the investment of time necessary for building various architectures, which leads to various financial spending and maintenance costs, we’ll agree that the balance between the priority of formulated requirements, development cost, and maintenance cost is crucial.
That’s why it’s essential to understand a few things:
- Not all business requirements can be met at the same time
- Every business requirement has implementation and maintenance costs
- Balancing requirement implementation and costs is key for technical decisions that are effective for business
So, what main factors do we need to take into consideration before projecting financial app architecture?
Location
Once we know the location of the future business, we get a clear understanding of the regulatory requirements or limitations that exist in particular countries or are established by particular financial institutions. Actually, this is a crucial factor that has a tremendous and immediate impact on system architecture. It’s necessary to consider a wide range of requirements starting from the location zones or handling of sensitive data (GDPR, CCPA, etc.) to the management of different geographical zones with various services/servers. For example, we might have various taxation systems in various zones or have a requirement to collect, store and manage personal data only in a particular country or region. This makes us design systems with distributed architectures.
While we always hear about scaling out databases, business logic that takes into account geographical zones plays a huge role in financial application development. That’s why we recommend starting from one country or two countries when it comes to fintech startups to simplify the first stages of production.
The type of the business model and the system load
The type of the business model and the system load — these two criteria are closely correlated. If we are talking about the B2C model, our prognostic abilities are much lower than when it comes to the B2B model. In B2C businesses, we have to deal with daily/seasonal loads, the consequences of developing advertising campaigns on social media, or even rumors.
Knowing more about the business model and potential system load helps not only predict the main type of scaling: microservice architecture, SOA (service-oriented architecture), scalable monoliths, or just data scaling (for example, with databases) but also to develop the system more effectively. For example, mixing several approaches can allow businesses to achieve a balance between business requirements and expenses including development and support costs. You can read more on how to scale software product development at fast-growing tech startups here.
Performance/latency
Performance/latency and network delays are important not only for the system’s parts such as cache, and CDN, but also for the protocols that will be used and for the choice of the architecture model and connections in the system. For example, trendy serverless architecture has one big drawback — cold starts. While the issue can be mitigated by “pre-warming,” we still will have problems with connecting several serial functional blocks in the microservices system, as it will increase latency significantly.
However, it’s only one approach to architecture, so we need to know and use various design methods in architecture.
Real-time
Although this criterion is closely connected with performance and latency, it differs a bit from them. That’s why real-time is worth our special attention as we need to take into account the possibility of streaming or chatting while developing a fintech startup. Although these features aren’t always necessary for financial products, it’s better to work on them anyway, and it’s especially important in the B2C systems, for instance, for customer support or notifications.
Security protocols and technologies
Security protocols and technologies are also important aspects to think about while designing a future app. The necessity of storing confidential data and sensitive information can determine the architecture of the system; which is pivotal when we are talking about fintech. For fintech products is extremely important to:
- Design Users and Admins flow excluding accidental or intentional information leakage
- Develop clear access and permissions matrix
- Enforce fintech app security with multi-factor authentication, KYC verification, infrastructure access & vulnerability monitoring, data storage security, in-rest hard drive encryption
- Protect the app against OWASP Top 10 vulnerabilities
- Follow the procedure of code, storing, access and permissions inspection, established for fintech software
System reliability and fault tolerance
The thing is that no one (even the giants like Google or Amazon) can guarantee 100% uptime, particularly when it comes to Google and Amazon cloud infrastructures. It’s thought that 99.99% uptime is good enough (here is the info on AWS and Google Cloud).
In the case of microservice architecture, the failure of one part of the system is less critical than for monolith architecture. Therefore, we need to understand business requirements connected to system reliability and fault tolerance really clearly. Lack of transparency in business requirements usually leads to irrational and excessive spending or even problems with service availability if an inexpensive but less reliable option was chosen.
Although each business case is unique, the common steps of building a fintech app are the same: clarifying business requirements, criteria, and key nonfunctional requirements, and only then designing system architecture considering all of the above. However, we also need to take into account the current state of business, and we mean not only the budget but also the stage of business growth: whether we design the system for a startup or an established company. In other words, we need to know if business requirements are fully formulated and well-described and whether we need to adapt the product to market.
Here is where we face one unusual challenge that comes into the game: in many articles, we read that microservices architecture is the best for financial systems (we completely agree with this!) but this approach is usually used ignoring the growth stages businesses go through and the adaptation to the market. However, this could be a key element in business success. Let’s take a look at the well-known picture that illustrates the problem the best.
This is true not only for functionality but also for app architecture. If we compare the engines and transmissions of the motorcycle and car, they are quite different.
Three Options for Fintech Architecture: Monolith, SOA, and Microservices
Eventually, the next question you will have to answer is which approach to financial app development should you choose. Well, you can use pretty much everything, the choices vary very much, but when selecting from all the different approaches you can use, there are pitfalls and benefits. So, let’s build and then analyze in terms of efficiency the architecture of the financial app.
This is only an example of one project to choose the most suitable architecture provided that we are in the startup stage and business conditions can be changed. In the startup stage, we need to easily add new functionality and not spend a lot on the implementation and support of those new features. We’ll simplify the criteria for the financial app architecture and keep only the main ones, such as:
- Scalability for increased workload
- Correlation between developer productivity and cost
- Flexibility in adding new functionality
- Fault tolerance
As a rule, the evaluation of these characteristics is enough for the first stages. Moreover, they are connected and correlated with each other. In most cases, we choose from the following three architectural approaches: Monolith, SOA, and Microservices, so based on our experience, we’ve created the table you can see below.
| Scalability | Cost | Flexibility | Fault tolerance | |
|
Monolith |
1 | 3 | 3 | 1 |
| SOA | 2 | 2 | 2 |
3 |
|
Microservices |
3 | 1 | 2 |
2 |
Where ‘3’ – the best, ‘1’ – the worst
The results of the assessment are completely empirical, based on our own experience. So, what does such a complex evaluation mean for startups? The analysis and the fact that the system architecture can be changed during different stages of business growth gives us to understand that in terms of costs, it’s better to start from the monolith, then set aside unchangeable parts of the system to separate services, and only after this step, move to microservices.
The core difference between the aforesaid approaches lies in the size of the services and the functions every service executes. If in microservices every service is usually based on Lambda or similar technology and executes a simple function, in SOA every service works as a full-fledged app with a full business role. Monolith has the same functionality, but the connections between business abstractions are stored inside the app, in contrast to the previous approaches. The monolithic app scales as a whole unit making scaling difficult and less optimal. Of course, we need to consider the system’s size, but remember that we’re talking about startups.
For this reason, here is another important conclusion: apps in different architectures work the same with the same connections in the app, but the connections between business abstractions (functionality) are positioned on the different levels of the app. In the case of monolithic apps and SOA, the business logic connections of the services are usually placed inside the programming code, and the connections between the services — are on the infrastructure level, but in microservices, all the connections are arranged only on the infrastructure level. This explains the popularity of the Infrastructure as code (IaC) approach: it simplifies the connection design in the app for developers but requires additional knowledge and skills, including the basics of cloud infrastructure and services.
The Best Architecture for a Fintech App: How to Choose?
Microservices apps are easily scalable but they are more difficult and time-consuming to build: you need to spend far more time planning service infrastructure and service connections. Plus, you need additional time on DevOps to set a task and control its execution. In fact, the time required on building microservices architecture (including the planning stage and the time spent on communication during the process) can be increased, in our experience, by 1,3, and even 2,5 times compared to the monolithic architecture.
If we are talking about SOA, it uses the `Decompose By Business Capability` pattern — one of the most well-known strategies to break an application into services by defining the business capabilities of the app and creating a particular service for each of them. Business capabilities are the features that are available for customers while using the app. Unlike microservices, it takes less time to plan and build the project as the system requires fewer external infrastructure connections. Additionally, this approach helps to create more flexible systems in the world of ever-changing business requirements as changes are made on the level of the programming code only if they are related to particular business areas.
Finally, the monolithic architecture is the fastest when it comes to development as the functionality is built on the developer’s side, is their responsibility, and doesn’t deal with the infrastructure level.
In the first stages, we recommend balancing breaking the system into separate blocks and increasing the costs. That’s why we recommend avoiding microservices while creating financial apps from scratch. Microservices make it more complex and time consuming to build the system, and this usually comes with raising spending. This approach is far from perfect for startups as at this current point, and the key problem is an absence of distinctly stated requirements.
Therefore, the best strategy for fintech startups is to start with monolithic architecture and then move to SOA, defining the parts that won’t be changed in the future and the parts that will be changed, implementing asynchronous interaction between the parts of the system. And then — adopt microservices to optimize the system maintenance costs.
Otherwise, the lack of finalized business requirements in the first stages can lead to unnecessary changes and additional functionality that will be more expensive compared to monolithic architecture. This doesn’t mean that this approach is the only one to utilize. Actually, we recommend different architectural approaches in different cases.
- If we don’t have fully finalized business requirements and business flow, the monolithic architecture allows a developer to make changes on their own, without involving other roles. For example, we need a DevOps engineer only in the deployment stage, but not in the development one.
- If we already have an existing service or the 80-90% confidence level that business flow works, the SOA approach works the best.
- If we have an existing service in the need of optimization, microservices will be the most optimal choice.
Of course, if your product doesn’t have high-load functionality, the architecture should be selected, taking into account that functionality.
To conclude, it’s better not to address the chosen architecture as something permanent. As your startup grows and changes, the system architecture also evolves. It’s absolutely okay to start with monoliths, on the growing stage — separate some functional blocks into services, thereby moving to SOA, and on the optimization stage — turn to microservices. It’s crucial to agree on the core business requirements and the architecture approach in the first stage to avoid misunderstanding and ensure that the technology choice is reasonable.
