Changing Yota
architecture with
Tarantool-based cache

Yota is a mobile operator that extensively implements innovations in its work. The company was the first to launch LTE onto the Russian market, offer unlimited 4G broadband for 78 regions, and use drones for SIM card delivery.


Tasks and requirements

In 2017, Yota realized that the company needed to speed up the backend response to mobile app requests. Opening the application could take 5–6 seconds, which was noticeable to the user, so Yota services left a negative impression.

At that time, the company used a service-oriented architecture with synchronous requests that heavily affected the system performance. The microservice architecture was then starting to gain popularity. As part of its implementation, Yota technical experts started looking for an in-memory solution that would help them organize the cache. In the end, they settled on Tarantool.



Behind the cache in Yota, there is an extensive IT landscape with roughly 200 services. The services are divided into IT products, each in its own isolated infrastructure. For example, the IT product responsible for customer data and the IT product responsible for subscriber notifications work independently. Domains are configured in the cache, so there is no need to send a GET request to a product every time to collect information. The Yota team also added branching logic for domain invalidation. When a backend event occurs—for example, the subscription time runs out—the cache wrapper intercepts the event and resets this particular subscriber’s domain.

Today, Yota has the following services implemented on Tarantool technologies.


The primary Tarantool-based service in Yota is the Profile Aggregation Service‑a personalized cache that speeds up customer data handling. The service collects and caches profile data from adjoining systems. It invalidates the data after receiving external signals. Adding a new profile only requires a configuration.

The domain-oriented Enterprise Persistent Storage holds data structures created by IT products. The service handles saving, updating, reading, and deleting data. For example, it enables the user to create a payment template in the mobile application.

icon icon


Profile Aggregation Service

This is the service that aggregates and encrypts subscriber data. When data changes, services send asynchronous requests to invalidate their cache data. Requests are processed asynchronously, and data is sharded in the backend to increase access speed.

Enterprise Persistent Storage

This is a domain-driven persistent data storage providing a CRUD interface for reading, writing, modifying, and deleting data that requires fast access. In particular, the services use it to store temporary data during process execution.



The Semaphore Service stores information about blocked actions in the system. The service is actively used for designing product logic and asynchronous interactions.

The interactive directory was migrated to Tarantool. It stores directories of client numbers ported to Yota as well as region codes. It is synchronized with the Central Database of ported numbers and updates the data every day. The directory quickly provides information to the mobile app, website, and backend.


The product catalog was also migrated to Tarantool. Previously, the configuration required a lot of effort and developer contribution; now an analyst creates a YAML file with the catalog configuration. The new architecture allowed creating a flexible Yota constructor where a customer can choose the number of minutes and gigabytes in a package. With the legacy architecture, this would be technically impossible. Yota’s service catalog structure is defined by YAML.

Frontends Auth Storage Service (FASS) is an authorization service that manages subscriber tokens.

icon icon


Tarantool-based Yota services can safely process cache read requests in the amount of 3,000 TPS. Due to the changes in architecture over the past few years, the speed of modification has increased, and it has become easier and faster to change services. Before, a full release with analytics, development, and testing would take weeks. Now it takes three days at most, including testing, which isn’t necessary for ordinary tasks.

0.2–3 ms

Access time in Yota services on Tarantool

3,000 TPS

Number of load testing read requests that Tarantool processes

2–3 days

TTM for a release with a configured product catalog

Get a consultation

Order a demo

Thank you for your request

Tarantool experts will
contact you shortly