This slide cover on topic how cross wallet amount transfer happens using different possible solutions
- Have gone through each solution pros and cons
- Which one is preferable for monolith and microservices and also based on the key pointers.
software and hardware may support different numeric precisions in serialization and deserializatio, this may cause unIntended rounding errors? The number could be extremely big or extremely small Many choose float or double as a datatype. It is still a proper choice as long as individuals understand the potential risk of losing precision.
maintains an account balance for each user account. For In-memory stores we use Redis String accountId = “A” Int partitionNumber = 7 Int myPartition = accountID.hashCode() % partitionNumber; Zookeeper
maintains an account balance for each user account. The final component is a service that handles transfer commands. - Let’s call it as a wallet service. Key responsibilities of wallet service will be - - Receive transfer command - Validate - If valid - Update account balance for two users involved in the transfer In real life user accounts are likely to be present in different nodes.
of using In-Memory solution? Does not meet our correctness requirement Wallet service updates two redis nodes on each balance transfer request -> there is no guarantee that both updates would succeed. Example- Wallet service node crashes after the first update has gone through but before the second update is done. -> result in an incomplete transfer. Open Question -> For this situation if you think What is needed?
of using In-Memory solution? Does not meet our correctness requirement Wallet service updates two redis nodes on each balance transfer request -> there is no guarantee that both updates would succeed. Example- Wallet service node crashes after the first update has gone through but before the second update is done. -> result in an incomplete transfer. For this situation if you think What is needed? The two updates need to be in a single atomic transaction.
protocol - When database nodes replies to coordinator we are willing to commit the transaction, then coordinator nodes decision is to commit or abort the transaction. What if database nodes crash in this process -> What happens when Coordinator crashes? - Coordinator writes its decision to disk - When it recovers, read the decision from disk and send it to replicas. (Or abort if no decision was made before crash) - Problem : If coordinator crashes after prepare, but before broadcasting decision, other nodes do not know how it has decided - Replicas participating in transaction cannot commit or abort after responding “ok” to the prepare request (Otherwise we risk violating atomicity) - Algorithm is blocked until coordinator recovers Then the coordinator will timeout and says we can abort the transaction for everyone.
an alternative to 2PC transactions, designed to handle long live transactions that involve multiple services. TC/C is a type of compensating transaction that has two types. 1. In the first phase, the coordinator asks all databases to reserve the resources for the transaction 2. In the second phase, the coordinator collects replies from all databases : If database replies with yes -> coordinator will ask all database to confirm the operation If any database replies with no. coordinator will ask all the databases to cancel the operation, Which is the Try-Cancel process.
this pattern is - l What if First Try phase fails What if the first TRy phase succeeds but confirms fails? - which can result in $100 missing -> The sum of account balance will be 0, which is less than the beginning of TC/C. It violates the fundamental rule of accounting that sum should remain the same after a transaction
saga is simple All operations are ordered in a sequence. Each operation is an independent transaction on it’s own database Operations are executed from the first to the last. When one operation has finished, the next operation is triggered a. b. c.
has failed, the entire process starts to roll back from the current operation to the first operation in reverse order called backward recovery. Another way to handle this is you retry i.e you try to execute that step again and you continue your transaction to make cross wallet transfer successful that is called as a forward recovery.
is determined by the business needs and goals. Challenge of the choreography solution is := services communicate in a fully asynchronous way, so each service has to maintain an internal state machine on order to understand what to do when other services emit an event. It can become hard to manage when there are many services. Orchestration Solution handles the complexity well. So it is usually preferred solution in digital wallet system SAGA Design Pattern -Which solution should implement when?
The answer depends upon the latency requirement. Operations in saga have to be executed in linear order, but it is possible to execute them in parallel in TC/C If there is no latency requirement, or there are very few services such as our money transfer example we can choose either of them If we want to go with the microservice architecture choose Saga If the system is latency-sensitive and contains many services operations TC/C might be a better option. So decision depends upon few factors :-
vrushaliraut
oracle4engineer
yanaemon
taka_aki
leveragestech
ewolff
kakehashi
tockn
ufried
toru_kubota
subroh0508
yoshikiiida
sachag
sugarenia
lemiorhan
jonyablonski
robhawkes
eileencodes
deanohume
destraynor
sferik
denniskardys
tmm1
chriscoyier
