One of spring days 2012 brought us a new project. One of our regular customers recommended our company to a very ambitious and engaged Moscow businessman. After reading the specifications, we were at a loss… after 5 years of active web-development! HiConversion project demanded the following:
- advertisement posting and administration in VK social network;
- statistics gathering from all the ads published on outer resources: Google Analytics, Yandex.Metrica;
- ability to monitor statistics on all the published ads for any time period;
- depending on results of the above-mentioned statistics - automatic or manual ads administration;
- access to all targeting settings (both one-by-one or bulks);
- interfaces for advertising agencies, hierarchical roles and permissions system;
- control over user account: ability to replenish account, automatic publishing blocking if there is budget is not full.
And that is just the tip of the iceberg. But let’s now concentrate on the architectural approach to implementation of such a complicated project.
As you see, all the above-mentioned demands are far from trivial web-application, not to mention Drupal default functionality. Necessity to update dozens of thousands queries per minute with outer resources' information forced us to look for roundabouts to overcome both Drupal core and other services limitations.
To get the most of these limitations, we had to re-think queries saving and processing formats in Drupal. Various data formats, principles of their communication and authentication needed to be taken into consideration, of course. As a final result - our queries had been processed not by cron scheduled tasks, but by php-demon. It had been monitoring element's presence in queue and implemented tasks at the very maximum speed which could have been achieved. A complicated ‘semaphore’ system (based on Drupal Lock API) was in charge of monitoring resource limits. Also, our interface allowed to easily add the new types of queries’ elements.
We also were forced to modify the very principle of fields processing in Drupal due to enormous statistical data storage (~1 million queries). At the same time, we wanted to stick to Drupal philosophy and to have the possibility to use standard implementations. That is why we created new types of fields which were more adjusted to our needs and used 100% of Drupal Field Storage API solutions. In our case, the majority of operations demanded a vast amount of fields to be updated with one-type kind of information in one go. This condition actually helped us to optimize the system - we added the functionality of fields mass updating and the posterior calling of the needed hooks. Advantages of such approach showed up very soon - we were able to use modules to build views with very complicated and interdependent filters and save them.
Regardless of system complexity we have left enough space for further functionality enlargement, e.g. queue event handler with flexible setting was added easily. On user-interface it looked like the addition of Field Collection element with a set of field settings. From the code perspective, we only needed to add these settings and reaction rules handler, expanding its basic behavior class.
Of course, despite the above-mentioned non-typical tasks, we needed to implement more common ones. For example, ads editing via exported Excel files; Yandex-market feeds scheduled parsing; and lots of other challenges concerning complicated user interface. Also, it is worth mentioning that during this project implementation we made several patches for contribution modules (famous Views - among them).
Now, pure statistics of all the high-load this ‘monster’ handled easily when our contract with this client was almost over:
- 400,000 nodes;
- from 4,000 to 20,000 new ads daily;
- 2,000 active advertising campaigns;
- 145,000 published ads;
- 8,000 ads published simultaneously;
- 21,000 ads where statistics is gathered from and targeting tactics are worked on less than 1 minute;
- up to 90,000 queries to VK API daily, average amount - 30,000;
- database size of 8 GB, up to 2 million queries in one table;
- 1 year of development by the team of 4 web developers;
- more than 32,000 code lines.
Of course, quality of work is not measured by the number of lines. So here are some facts for our not-involved-into-development audience:
- This project is the 7th advertisement networks which managed to gain VK accreditation;
- HiConversion was nominated for “Startup 2012’ award in Russia;
- Half a year after the first iteration launch this service-provider managed to gain such famous clients as MTS (rus. МТС), Euroset (Евросеть), Teamo, Sotmarket, Alfa-Bank (Альфа-Банк), etc.
This startup owners’ role can not be underestimated: their proficient approach to business architecture bore fruits. Later, the second iteration had been implemented via absolutely another development technology. The project is continuing to grow and holds its positions on targeted advertising market in social networks. We wish everybody has such clients and challenging projects!