Moasis is a project that was created from scratch by me and only me. Additionally it became a huge commercial success.
Moasis is a system that performs real time auctions of advertisement on mobile phones. It works according to the Real Time Bidding concept. This means that a mobile phone that “wants” to show a new advertisement (every 30 seconds an advertisement banner gets refreshed) collects information about a phone, a user and environmental factors and sends a proposal to many companies that may be interested in showing their advertisement. Each of those companies makes a bid by offering certain amount of money (usually fractions of a cent). The one that has the best offer wins the auction and its advertisement gets shown on the mobile phone. The whole process takes usually around 200 milliseconds.
Moasis has advanced functions of matching advertisement to the need of a client using multiple criteria including:
- Location
- Size of a banner
- Time of day
- Distribution of expenses in time (pacing)
- Exchange that passed the offer from mobile phone
- Mobile device model
- Interests of the mobile phone user
- Content of the banner
The functionality that owners of Moasis are the most proud of is patented geolocation system that allows precise selection of areas where the given advertisement should be displayed (user is located on the map using either GPS or IP geolocation).
Moasis also collects huge amount of statistical information about users that can be later analyzed and the criteria for showing advertisement can be updated, so that advertisement is shown only to users that generate value to the advertising company.
The real challenge in designing RTB systems is their speed. You can tell that a given website is very popular if it generates a million of requests during a day. My system had to handle this level of traffic during 20 seconds and be scalable to even greater number in the future. Another problem is the average request time. A single HTTP request needs to handled in maximum 50 milliseconds, otherwise response won’t reach the auction before it ends (additional delays include propagation time and TCP retransmissions).
I managed to solve the problem of high load by load balancing and redirecting the traffic to a bunch of virtual servers, performing very deep optimizations and by eliminating long IO operations (including reading and writing to a database, generating logs, searching for campaigns meeting certain criteria etc.). The average response time got minimized mainly by performing extensive caching and thanks to multithreaded architecture that was using all cores of the system. Eventually the average response time went down to 1 millisecond.
Huge problems that needs to be addressed when designing services is fallibility of elements of the system and potential problems with communication between those elements. During my work several times my system experienced problems with a database, hard drives of servers got full or application stopped functioning because of bugs that I accidentally introduced. In services that perform large scale financial operations such problems tend to be very costly. When the system doesn’t work, it doesn’t earn money and you also loose credibility with clients. Just one weekend of downtime is worth as much as a good car. This is why one of major functionalities become a monitoring system. In the office we installed a PC display device with charts showing current activity of the system running 24 hours a day. When unexpected fluctuations happened, it was a sign for us to investigate deeper logs of the system to check what is going on.
My application is basically the backend of the whole system and therefore it is not accessible publicly. The external website about the system can be found here: