Real-Time Exchange Payment System Design

https://hackernoon.com/best-practices-for-event-driven-microservice-architecture-e034p21lk

Today, we are going to talk about something special. A system design for a real -time currency exchange payment system.

User stories

  • Player can store their money as currency X
  • Company will receive currency Y which is exchanged from currency X
  • After validation of receiving currency Y, company will reward same amount of currency Z back to player
  • Exchange rate for each transaction is based on the rate within 24 hours
  • Fault Tolerance for exchange rate need to keep within 1%
  • Each of transaction’s data need to keep at least 6 month

What could possibly go side ways when we design this system?

  • Maybe Lack of Payment ?
  • Duplicate of Payment ?
  • Incorrect currency conversion ?
  • Max currency tolerance meets ?
  • Incorrect Payment ?

And what if it really goes wrong ?

It will always goes wrong no matter how well we design, so that’s assume

  • We have Bugs occurs between 0.1% to 0.001%
  • Price for fixing each Bug cost 15$
  • And we measure transaction from 0 to 1M transaction per day

So, the formula will look like this >> Bug Cost * Percentage of Bugs * Total Transactions

And what will this result look like ?

Result will look like this, as you can see the more tolerance we gave to the system the highest cost we need to pay for fixing the trouble we make.

Therefore, when we design the system we need to somehow minimize the possibility of the fault tolerance.

How Should We Design

I separate my design into two main parts, Currency Services, Reward & Store Services. I will show you why I design like this later on.

Currency Services

  • Our structure for Currency Services
Currency Services
  • Work flow for Currency Services (CQRs)
Work flow for Currency Services

The idea for the currency service is doing long polling to get the latest data from Bank. (let’s say we poll every 5 seconds)

After receiving data from Bank API, currency service will do two different things following CQRS design pattern, and that is update and display.

Therefore, Command Model stands for receiving data from Bank API and select data from DB simultaneously. Then it will excutes the compare function to pick out the best currency rate for X > Y and Y > Z to meet lower fault tolerance. Just like we have mentioned. After that DB will get update.

Once DB is update, Query Model will do it’s job to display data from DB and pulish the real-time Data to the relevant services.

In conclusion, Currency Service will handle the logic for keeping fresh rate up to date, meanwhile the comparing process inside will ensure the exchange rate keep as low as possible.

Store && Reward Services

  • Our Structure for Store && Reward Servcies
Store && Reward Services

First, Store Services receive events from previous Services then it store data into its own local database. By which means, each services store its own data from event-bus where services can store the additional data by adding more fields in its DB. We call that Availabiility.

Second, all the datas which database are storing can be called as event-logs. It stores all the incoming logging of all events. Therefore, its also easy-to-rollback by using its event-logs. That's assume if you have a bugs happend in Timestamp X, you only need to go to that Timestamp X and running events one by one for debugging. And this will also keep Fault tolerant as low as possible.

Third, if you are going to create new services for new logic to replace old services. You only need to change the event-bus and Event database point to new services. Which is a very smooth and fast replacement

Last, the most import one. Transaction guarantee!!! Event-Driven gives you a transaction guarantee are either at least one or at most one.

Whole System

System Overview
  1. Frist, Client sending request for storing X currency.
  2. API Gateway receiving request and pass it to event Bus.
  3. Store Services receive each requests from event-bus, meanwhile receiving X -> Y currency exchange rate from currency services (We assuming it's a long pull every 5 seconds). Then Store Services convert X currency to Y currency
  4. Reward Services receive each requests from event-bus, meawhile receiving Y -> Z currency exchange rate from currency services (We assuming it's a long pull every 5 seconds). Then Reward Services convert Y currency to Z currency then sending out back to players.

For more detail, you can visit my github link: https://github.com/libterty/Payment-Process-Architecture/blob/master/payment-process.md

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store