1、Table of ContentsThe Fragile Balance Between Stability and Scalability:the CAP TheoremLOCATIONTHE TYPE OF THE BUSINESS MODEL AND THE SYSTEM LOADPERFORMANCE/LATENCYREAL-TIMESYSTEM RELIABILITY AND FAULT TOLERANCEThree Options for Fintech Architecture:Monolith,SOA,and MicroservicesThe Best Architecture

2、 for a Fintech App:How to Choose?1When building an extremely complex platform like a fintech app,most of thetime you come up with a“wishlist,”including all the“must-haves”you want tohave in the product.For a financial app,it contains literally everything,and yourlist will look something like:100%sec

3、urity100%fault tolerance100%reliability100%scalability100%flexibilityand so on,so onHowever,that seems to be theoretically impossible.Its like asking a small kid ina toy store,“What do you want?”The obvious but not pleasant answer will be,“Everything and right now!”The product must be reliable,it mu

4、st comply withthe law in a particular area,and it must be flexible and scalable so that you canbuild on top of it to customize the functionality that it has(and add newfunctionality).2On the road to your perfect fintech product,the first question you will have toanswer is what strategy to choose whi

5、le building your apps architecture.Whilethe choices seem almost unlimited,all options have their advantages anddisadvantages at different stages of business growth.In this article,well take alook at different approaches to fintech architecture to help you create a winningstrategy for your product.Th

6、e Fragile Balance Between Stability andScalability:the CAP TheoremAny great Fintech idea will not transform into an effective and competitiveproduct without a good app architecture.While developing any IT system,wealways prioritize business requirements,and financial systems arent anexception.Thats

7、why its not a really good idea to base the system on technicalrequirements,such as for example,desired technologies,as they are secondary.As all systems are unique in functions and requirements,apps architectures willalso vary.So,how can we describe a good financial system architecture?Letstake a lo

8、ok at one example and describe all possible options.Typically,at MobiDev,we start with defining core business requirements,andthey can be described as a user or business flow.By analyzing businessrequirements,we better understand particular business goals,and thisunderstanding allows us to formulate

9、 functional and non-functionalrequirements 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 financialapp,as their implementation directly depends on chosen

10、 architecture or theoffered technology stack.Unfortunately,not all attributes can be combined witheach other.In fact,we are unable to meet all the requirements that we have forour app.One of the proofs of this statement is the CAP(Consistency,Availability,Partition tolerance)theorem,which can be app

11、lied to the whole system.3If we take into account the investment of time necessary for building variousarchitectures,which leads to various financial spending and maintenance costs,well agree that the balance between the priority of formulated requirements,development cost,and maintenance cost is cr

12、ucial.Thats why its essential to understand a few things:Not all business requirements can be met at the same timeEvery business requirement has implementation and maintenance costsBalancing requirement implementation and costs is key for technicaldecisions that are effective for business4So,what ma

13、in factors do we need to take into consideration before projectingfinancial app architecture?LOCATIONOnce we know the location of the future business,we get a clear understandingof the regulatory requirements or limitations that exist in particular countries orare established by particular financial

14、 institutions.Actually,this is a crucial factorthat has a tremendous and immediate impact on system architecture.Itsnecessary to consider a wide range of requirements starting from the locationzones or handling of sensitive data(GDPR,CCPA,etc.)to the management ofdifferent geographical zones with va

15、rious services/servers.For example,wemight have various taxation systems in various zones or have a requirement tocollect,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

16、,business logic that takes intoaccount geographical zones plays a huge role in financial applicationdevelopment.Thats why we recommend starting from one country or twocountries when it comes to fintech startups to simplify the first stages ofproduction.THE TYPE OF THE BUSINESS MODEL AND THE SYSTEM L

17、OADThe type of the business model and the system load these two criteria areclosely correlated.If we are talking about the B2C model,our prognostic abilitiesare much lower than when it comes to the B2B model.In B2C businesses,wehave to deal with daily/seasonal loads,the consequences of developingadv

18、ertising campaigns on social media,or even rumors.Knowing more about the business model and potential system load helps notonly predict the main type of scaling:microservice architecture,SOA(service-oriented architecture),scalable monoliths,or just data scaling(forexample,with databases)but also to

19、develop the system more effectively.Forexample,mixing several approaches can allow businesses to achieve a balancebetween business requirements and expenses including development andsupport costs.You can read more on how to scale software productdevelopment at fast-growing tech startups here.5PERFOR

20、MANCE/LATENCYPerformance/latency and network delays are important not only for the systemsparts such as cache,and CDN,but also for the protocols that will be used and forthe choice of the architecture model and connections in the system.Forexample,trendy serverless architecture has one big drawback

21、cold starts.While the issue can be mitigated by“pre-warming,”we still will have problemswith connecting several serial functional blocks in the microservices system,as itwill increase latency significantly.However,its only one approach to architecture,so we need to know and usevarious design methods

22、 in architecture.REAL-TIMEAlthough this criterion is closely connected with performance and latency,itdiffers a bit from them.Thats why real-time is worth our special attention as weneed to take into account the possibility of streaming or chatting whiledeveloping a fintech startup.Although these fe

23、atures arent always necessary forfinancial products,its better to work on them anyway,and its especiallyimportant in the B2C systems,for instance,for customer support ornotifications.Security protocols and technologiesSecurity protocols and technologies are also important aspects to think aboutwhile

24、 designing a future app.The necessity of storing confidential data andsensitive information can determine the architecture of the system;which ispivotal when we are talking about fintech.For fintech products is extremelyimportant to:Design Users and Admins flow excluding accidental or intentionalinf

25、ormation leakageDevelop clear access and permissions matrixEnforce fintech app security with multi-factor authentication,KYCverification,infrastructure access&vulnerability monitoring,data storagesecurity,in-rest hard drive encryptionProtect the app against OWASP Top 10 vulnerabilities6Follow the pr

26、ocedure of code,storing,access and permissions inspection,established for fintech softwareSYSTEM RELIABILITY AND FAULT TOLERANCEThe thing is that no one(even the giants like Google or Amazon)can guarantee100%uptime,particularly when it comes to Google and Amazon cloudinfrastructures.Its thought that

27、 99.99%uptime is good enough(here is the infoon AWS and Google Cloud).In the case of microservice architecture,the failure of one part of the system isless critical than for monolith architecture.Therefore,we need to understandbusiness requirements connected to system reliability and fault tolerance

28、 reallyclearly.Lack of transparency in business requirements usually leads to irrationaland excessive spending or even problems with service availability if aninexpensive but less reliable option was chosen.Although each business case is unique,the common steps of building a fintechapp are the same:

29、clarifying business requirements,criteria,and keynonfunctional requirements,and only then designing system architectureconsidering all of the above.However,we also need to take into account thecurrent state of business,and we mean not only the budget but also the stage ofbusiness growth:whether we d

30、esign the system for a startup or an establishedcompany.In other words,we need to know if business requirements are fullyformulated and well-described and whether we need to adapt the product tomarket.Here is where we face one unusual challenge that comes into the game:in manyarticles,we read that m

31、icroservices architecture is the best for financial systems(we completely agree with this!)but this approach is usually used ignoring thegrowth stages businesses go through and the adaptation to the market.However,this could be a key element in business success.Lets take a look at thewell-known pict

32、ure that illustrates the problem the best.7This is true not only for functionality but also for app architecture.If we comparethe engines and transmissions of the motorcycle and car,they are quitedifferent.Three Options for Fintech Architecture:Monolith,SOA,and MicroservicesEventually,the next quest

33、ion you will have to answer is which approach tofinancial app development should you choose.Well,you can use pretty mucheverything,the choices vary very much,but when selecting from all the different8approaches you can use,there are pitfalls and benefits.So,lets build and thenanalyze in terms of eff

34、iciency the architecture of the financial app.This is only an example of one project to choose the most suitable architectureprovided that we are in the startup stage and business conditions can bechanged.In the startup stage,we need to easily add new functionality and notspend a lot on the implemen

35、tation and support of those new features.Wellsimplify the criteria for the financial app architecture and keep only the mainones,such as:Scalability for increased workloadCorrelation between developer productivity and costFlexibility in adding new functionalityFault toleranceAs a rule,the evaluation

36、 of these characteristics is enough for the first stages.Moreover,they are connected and correlated with each other.In most cases,wechoose from the following three architectural approaches:Monolith,SOA,andMicroservices,so based on our experience,weve created the table you can seebelow.Where 3 the be

37、st,1 the worstThe results of the assessment are completely empirical,based on our ownexperience.So,what does such a complex evaluation mean for startups?Theanalysis and the fact that the system architecture can be changed duringdifferent stages of business growth gives us to understand that in terms

38、 of costs,9its better to start from the monolith,then set aside unchangeable parts of thesystem to separate services,and only after this step,move to microservices.The core difference between the aforesaid approaches lies in the size of theservices and the functions every service executes.If in micr

39、oservices everyservice is usually based on Lambda or similar technology and executes a simplefunction,in SOA every service works as a full-fledged app with a full businessrole.Monolith has the same functionality,but the connections between businessabstractions are stored inside the app,in contrast t

40、o the previous approaches.The monolithic app scales as a whole unit making scaling difficult and lessoptimal.Of course,we need to consider the systems size,but remember thatwere talking about startups.For this reason,here is another important conclusion:apps in differentarchitectures work the same w

41、ith the same connections in the app,but theconnections between business abstractions(functionality)are positioned on thedifferent levels of the app.In the case of monolithic apps and SOA,the businesslogic connections of the services are usually placed inside the programmingcode,and the connections b

42、etween the services are on the infrastructurelevel,but in microservices,all the connections are arranged only on theinfrastructure level.This explains the popularity of the Infrastructure as code(IaC)approach:it simplifies the connection design in the app for developers butrequires additional knowle

43、dge and skills,including the basics of cloudinfrastructure and services.The Best Architecture for a Fintech App:Howto Choose?Microservices apps are easily scalable but they are more difficult andtime-consuming to build:you need to spend far more time planning serviceinfrastructure and service connec

44、tions.Plus,you need additional time onDevOps to set a task and control its execution.In fact,the time required onbuilding microservices architecture(including the planning stage and the timespent on communication during the process)can be increased,in ourexperience,by 1,3,and even 2,5 times compared

45、 to the monolithic architecture.10If we are talking about SOA,it uses the Decompose By Business Capabilitypattern one of the most well-known strategies to break an application intoservices by defining the business capabilities of the app and creating a particularservice for each of them.Business cap

46、abilities are the features that are availablefor customers while using the app.Unlike microservices,it takes less time toplan and build the project as the system requires fewer external infrastructureconnections.Additionally,this approach helps to create more flexible systems inthe world of ever-cha

47、nging business requirements as changes are made on thelevel of the programming code only if they are related to particular businessareas.Finally,the monolithic architecture is the fastest when it comes to developmentas the functionality is built on the developers side,is their responsibility,anddoes

48、nt deal with the infrastructure level.In the first stages,we recommend balancing breaking the system intoseparate blocks and increasing the costs.Thats why we recommendavoiding microservices while creating financial apps from scratch.Microservices make it more complex and time consuming to build the

49、system,and this usually comes with raising spending.This approach is farfrom perfect for startups as at this current point,and the key problem isan absence of distinctly stated requirements.Therefore,the best strategy for fintech startups is to start with monolithicarchitecture and then move to SOA,

50、defining the parts that wont bechanged in the future and the parts that will be changed,implementingasynchronous 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

51、 can leadto unnecessary changes and additional functionality that will be more expensivecompared to monolithic architecture.This doesnt mean that this approach isthe only one to utilize.Actually,we recommend different architecturalapproaches in different cases.1.If we dont have fully finalized busin

52、ess requirements and business flow,the monolithic architecture allows a developer to make changes on their11own,without involving other roles.For example,we need a DevOpsspecialist only in the deployment stage,but not in the development one.2.If we already have an existing service or the 80-90%confi

53、dence level thatbusiness flow works,the SOA approach works the best.3.If we have an existing service in the need of optimization,microserviceswill be the most optimal choice.Of course,if your product doesnt have high-load functionality,the architectureshould be selected,taking into account that func

54、tionality.To conclude,its better not to address the chosen architecture as somethingpermanent.As your startup grows and changes,the system architecture alsoevolves.Its absolutely okay to start with monoliths,on the growing stage separate some functional blocks into services,thereby moving to SOA,and onthe optimization stage turn to microservices.Its crucial to agree on the corebusiness requirements and the architecture approach in the first stage to avoidmisunderstanding and ensure that the technology choice is reasonable.12