mpesa vs banks

How M-Pesa/banks ensure your money is safe.

The amount of money being transacted on a daily basis through the banks and M-Pesa runs into the billions. How does M-Pesa ensure that money is not lost or money deposited to the wrong no by mistake?

Mpesa just like any financial institution stores information in a database where if I send Kshs 100 to person B a debit is made to my account and credit to person B’s account all in a matter of seconds.

For m-pesa or the bank to be able to run transactions seamlessly they need a database engine that is reliable, consistent and safe. most database engines have such properties but a database that can handle acid transactions is one that fits this bill. What is an acid transaction you might ask?

ACID stands for (atomicity, consistency, isolation, and durability) Let’s look at acid transactions in the case of a bank or m-pesa transaction.

  • Atomicity-atomicity guarantees that all commands that guarantee a transaction are treated as a single entity and that they either fail together or succeed together. in the case of m-pesa/bank transfer when you send money the debit and credit transactions are treated as one and they either both fail or succeed.

Atomicity ensures that no inconsistency ever arises in the process of a transaction.

  • Consistency-consistency ensures that changes made in a database are consistent with database constraints. a transaction fails if it does not meet the set rules and constraints. in the case of a bank or m-pesa transaction, it’s impossible for a transaction to be successful when the sender has a negative balance because of the constraints that are in place blocking this.
  • Isolation-this ensures that transactions run in isolation and that no one transaction affects another for whatever reason. without isolation cases of wrongful debits and credits will be too many crippling a service entirely.
  • Durability-this ensures that once a transaction is completed the records of the transaction are forever available. durability is tied to a service SLA and the higher the SLA the less amount of downtime the service will have.

In the case of m-pesa/bank transactions, their service administrators ensure that they replicate the data to ensure redundancy and reduce points of failure.

in October 2011 Safaricom decided to transfer m-pesa servers from Vodafone Europe to Kenya. this move was to guarantee the durability of the system as it is easy to manage data nearer considering the sensitive nature of the service the move also reduced latency(delay)when performing transactions.

For a system like m-pesa to run it needs servers with very high IOPS(input-output operations per second) as it handles thousands of transactions per second.ACID transactions mainly run on SQL databases because of their consistency. an example is PostgreSQL or SQL for the NOSQL counterpart MongoDB is a good candidate to handle acid transactions

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top