CODEWITHSUNDEEP
pythondatabasesecurityweb-applicationsarchitecture
Kanar
Kanar

Reputation: 21

System architecture and stack used for big applications

I have a two questions regarding best practices and technologies being used in banking apps and similar "high risk" applications.

Let's say we were trying to build a banking app on which the customer can register an account with his or her credentials and transfer and receive money. Just built like every common banking app with authentication mechanisms, PUSH TAN and other verification methods prior to transfering money, session login which expires after a given time period of inactivity which results in automatically logging out and fingerprint authentication and so on...

QUESTIONS:

What system level architecture patterns (High Level Design) are used as the foundation for such applications?

And what (Stack) programming languages, db querying languages and APIs are typically used for such high risk applications like banking apps (maybe languages and FWs like Python and Django, MySQL, Cassandra)?

I'm very thankful for every answer so don't hesitate to throw in whatever you know.

Upvotes: 0

Views: 218

Answers (1)

Cosmin Ioniță
Cosmin Ioniță

Reputation: 4055

Here are my thoughts around this:

  • In general, high-risk systems (banking apps, exchanges) should follow strict requirements in terms of security, availability, reliability, correctness. If one of those features is not carefully considered, bad things can happen (people lose money). This usually leads to higher costs, compared to other types of applications.
  • In terms of architecture, if you want to go with the current trends, you can use microservices. For example Monzo use a microservice-based approach to run their backend (this nice presentation goes into more details). This is definitely the new way of building low-latency scalable backend systems (even for high-risk apps). One downside that I see with this approach (I may be wrong) is the lack of maturity (compared to classical client-server model) and the fact that you always need to be up to date with the open-source technologies that are involved, because they are in a constant change. Big companies have dedicated teams which contribute and stay up to date with open-source technologies.
  • You can always go with a client-server architecture where the backend is just a fleet of nodes which process requests and talk to a database. This might be a bit simpler to start with, but probably harder to evolve. Choosing the architecture depends entirely on the development strategy that you plan for your system. There are pros and cons on any approach.
  • In terms of tech stack, I would go with mature languages/frameworks, like Angular, Java, C#, Spring Boot. That way you can find more easily developers to help you out, but also an ecosystem built by the industry over the years.
  • In terms of database, you could go with a relational solution (MySQL, SQL Server) and use transactions to provide atomic updates (to account balances, for example). This may hit the overall performance at some point, in terms of latency / throughput. A No-SQL approach may improve the speed, but may also come with data duplication, and some challenges in choosing the right data model.

As you can see, there are tradeoffs everywhere. It only depends on the initial strategy you set up, so you can avoid big future changes.

Upvotes: 1

Related Questions