By Mr. Anonymous
This piece was written by someone who requested to remain anonymous
Mpesa
An average Mpesa transaction takes a maximum of 100 bytes. And that is a complex transaction like paying a bill. Sending money and buying airtime takes about 50-60 bytes. I am being generous here. If encryption was employed (never is) which most experts will tell you is easy to crack A5/1 stream cipher that Safaricom uses to rarely encrypt pre-paid SMSes and Mpesa Transaction – pathetic!], it would increase the size of a normal Mpesa to 105 bytes. Maximum.
The A5/1 stream cipher uses three LFSRs.
So, having said the simple things above, one question really beats the me… HOW CAN MPESA HAVE OVERLOADS? It is technically impossible. Look at the example below.
Assumptions:
– No of Mpesa Users – 10, 000, 000 [Generous again!]
– Number of transactions per day – 2 [ish…]
– Average message size – 2 way – (105 bytes * 2) [Generous]
– SMS confirmation 1 – 160 bytes [Generous]
Total Possible Traffic per 24 hours:
10, 000, 000 * 2 * (210 + 160) = 7400000000 bytes
= 6.89 GB of data
Tuko pamoja so far?
Let take an example of average Lan for Investment Bank in Kenya which a proximately has 30 to 40 employees. It would work ok with 3 IBM 3650 eSeries Srver averaging 4GB of RAM each and just a mere 512 kbps Wimax link.
Open Question 1 : How can a 3.5 G network working at a rate of 14.4 Mbps fail to handle 6.89 GB of data?
Ciphering
Open Question 2: Let us assume the network is configured by an expert [someone who actually knows how to optimize resources] and it operates optimally. For a vetted and tested application running on a well-mannered server [FreeBSD/Debian/Gentoo] that have Symmetric Multi Processing enabled by default, A well optimized Oracle installation does a cool 60, 000 transactions per second.
That is 4 Million Transactions per Minute. it should NEVER EVER take more than 90 seconds for you to get a response. Mpesa has a backlog of 4 Days? as i? write this. PS : We are talking about 1 server here. A service like Mpesa must have at least 10. Yes, 10 dedicated EXPENSIVE but mis-configured servers, giving them the performance of a well optimized windows 95 box.(cringe!!)
That is why Safaricom need to get out and invest in getting their network properly setup and configured. My guess is, the current network was setup with little consideration of future growth.? For example a server configured to handle 10,000,000 requests suddenly gets 100,000,000 request will definitely go on strike, demanding whatever machine would want. With fiber optic here the problem will increase tenfold unless……
These are the kinds of brains and reasoning that Kenyans should expect from now henceforth. Well thought off, researched and factual information. Lets see if Michael Joseph will put a full page add to mispresent the facts on the backlog. Wakenya, esp IT Savvy wameamka sasa.
MPesa transactions are routed to the Vodafone Money Transfer Switch in UK, authorisations are done from there. There is a .NET / SQL Server stack running there complete with DR & BCP procs & mechanisms. The problem is most likely on the saf com side.
As for SIM encryption, am shocked to see that they dont have this, but am still not sure, from what I know, SIM comes with built in RSA / 3DES keys and enciphering algorithms, thus any serious STK app would have these…
Secure mobile banking and mobile commerce coming your way.
Nice article!!
@Njihia that is the way to go for developers
what is the source of your information…? you seem to know alot
Aaaiiii, boss
Your assumptions are broad and unfounded.
Have you ever designed a system? Was it bandwidth intensive, database intensive or processing intensive? What considerations did you make? Where did you assume the bottle necks occur?
Why do you think that the problem was connectivity bandwidth – blockage on a link on the Mpesa system?
Kachwanaya, I think your outlook on what may have been the problem is narrow. Do you have any idea how Mpesa actually works, what components it has etc?
May be you should have a chat with Mwangi, he seems to have a broader, albeit not full understanding of the system.
Gitosh,
Enlighten us on the SIM encryption part at least …..and where, in your opinion, could a bottleneck/congestion occur on such a large-scale critical system as MPESA, considering the hundreds of thousand transactions in handles per day/hour….
Have I ever designed a system? The answer is Yes, both for database intensive and bandwidth
So let me pause there, coz before i answer the remaining questions i would request you to prove that what is being said here is wrong instead of just saying it is narrow way of looking at it. You see it doesn't help when you come up and say that what one is saying is wrong unless you give an explanation as to why you think so. By the way telling me to talk to Mwangi is not explanation i am talking about here.
Still on talking to Mwangi, Mwangi tell us that Mpesa transaction is routed to UK, and at the end of it, it looks like we have one agreement here with him, the problem seems to be with Safaricom, and for technical explanations where will that be if it is not network and the bandwidth issues
I guess most of us here would love to hear your explanation based on full understanding of the system. Thanks
The bottle Neck cannot be on the SIM bit, SIM ops are pretty simple and depend on your phone, so the dance starts once the message leaves ur phone to the operator then to the VMT switch and back. When safcom gives free SMS they r not delivered reliably cz of the load, while I am sure that the VMT switch authorises and replies back fast enough (if not a reversal would be initiated) the problem may still lie on Safcom, their ability scale vertically n horizontally
Foremost, Very nice article!
About the backlog, i don't think we can really comment on the backlog without having an idea about where the problem is, for all we know the problem could be anything, including, but not limited to wrong configurations,bandwidth,bugs etc.
About encryption(or the lack of it), kindly expound on that, please state where exactly it is missing. am assuming that the risk would be communication between the handset and the BTS, but here we have encryption of data that is sent out and received.
heheheh… Can someone sit down and check the entire architecture of MPESA . Forget the 3G things its not a factor. To understand this a bit more look at SMS transport.. its a store and forward. Then the link to UK- May be using decomissioned satelites (Reliable..?) down to VMT switch and now to the nice servers the gentleman has talked about. Now if you can figure that out then the bottleneck could be …..
Ehh!! What are u guys talking about. VMT, KBPS.. typical geeks.. Cant u at least discuss soccer… U are confusing me bana.
If SMS and USSD transmissions were half as complex as a SSH or a VPN connection, then the article above would be BROAD and, indeed not only unfounded but non-factual.
Bandwidth intensive? Mpesa ni 100 bytes maximum mzee!!
Database intensive? Mpesa ni 100 bytes maximum mzee!!
Processor intensive? I doubt a match and approve/deny logic check for mpesa can even make a Xeon QuadCore processor feel anything!
I, for one, know HOW mpesa works. Even Zap or wap.zunguka.com is more complex.
Like my learned friend Mwangi Said, Shida ni Safcom. they do Store-and-delay badala ya store-and-forward to voda.
?? ???? ??? ???, ? ??? ????????! ???.
safcoms,bottleneck congestion is simply unexpected.that iis what is being explained here&if its football your looking for here scram!
I admire the visionary anylsts who look into systems that should be optimal to serve you and I perfectly.
Considering safaricoms income by the day-safaricoms engineers should do some serious back cheks,i am simply not understanding also how annoying delays and delays should occur…
6.9 gig as explained should be simple to synthesise by now if it was a problem in the past.by now they should have solutions.really!do somethng…