Optimizing TCO
with reliable
Tarantool cache

During the first stage, the developers ruled out any paid services because those costs exceeded the IT budget. That’s where Tarantool appeared. First, the team began transferring high-performance services that required many MS SQL database instances.

Today, the technical team of Wildberries has its own approach to creating reliable distributed systems. Tarantool is ideal for those systems as a universal storage for high-demand data: user profiles, banners, discounts, etc. In total, the company has twelve Tarantool-based microservices.

• The most critical service of the Wildberries website is the User Profile Master Storage, which contains data of 50 million users. MS SQL was been completely discarded in this case.
• The service that allows saving items for later is the company’s most extensive Tarantool-based service. It takes about 120 GB of memory and has 3–4 copies in each data center.
• In RPS terms, the highest-loaded services are the Promotizer and the User Profile Master Storage, receiving about 6,000 and 12,000 requests per second, respectively.
• The warehouse system’s quick reference materials, where some information can be rechecked, also run on Tarantool.

Here is how Tarantool operates. There are several master instances hosted on virtual or hardware machines in each data center. The connections follow the master-master pattern. Interfaces, or synchronizers, download information and write it onto the masters (e.g. information about discount coupons and their terms and conditions). Replicas hosted on virtual machines or in Kubernetes connect to these masters. On top of that, there are applications that access the replicas.

Each application works with two clusters. In case of a data center failure, an application can access the other cluster. There is a layer that stores the Tarantool Go driver interface and hides the logic. This layer sees all the replicas and can perform reads and writes on the master.