Software engineers working in Fintech often are asked system design questions that focus on fintech systems. Here is a short and simple guide to keep few things in mind when answering such interviews.

Choice of database

In fintech, the database is one of the most important choice. Most transactions need to happen atomically. The mutation operations must be fault tolerant. In some cases the writes could be delayed writes. Think of ACH where you provisionally debit an account but the actually commit might happen in future.

Relational databases like MySQL, Postgress etc. are great solutions. However you also need to factor in things like data localization. Is your database eventually consistent or is consistent in real time etc?

One way to solve this problem is by having a database for SOT (source of truth) that is replicated for read heavy operations.

Idempotency

Financial APIs must be idempotent. That means the cost to call the same API multiple times quickly should be low. We do not want to accidentally charge a user 10 times because there were 10 automatic retries.

Idempotency is generally achieved by sending a “idempotency key” with every request that is supposed to be unique.

Separating vendor communication

Financial systems are often complex and have dependencies on external partners such as banks or networks. This component must be separated from rest of the system to make the design simple. Also remember that vendors might chose to interact with your systems either through a push or pull method.

But your vendor component must be designed in a way that it abstracts away this complexity from the rest of the system.

Logging is important

Add logging system that writes to a message queue and then stores these logs securely. This also allows use to see the system evolution with time. What actions lead to user’s balance going down from $1000 to $500 ? We can answer those sort of questions by analyzing logs.

Risk Engine

Add a microservice for analyzing risks. It shows that your pay close attention to fraud prevention and analysis. Risk engine would often be a simple service that accepts certain signals and returns true to false or more states depending on the need.

Communication framework

You also need a communication framework responsible for sending emails and text messages and taking care of things like OTPs. Ideally this should be designed as a message queue with priorities and a pool of worker machines responsible for processing the message queues.

Security

Authentication, Authorization and Rate limiting is critical. This can be achieved using things like API gateway for all inbound communication. Security can be achieved using either application level encryption like JWE/JWS (called JOSE) or through MTLS which is a transport level security mechanism.

Conclusion

These are just some helpful tips but we are more than happy to give you more deeper dives into specific design problems. Reach us out if you want use to cover something.