Citilink is one of Russia's top online discount stores. Its extensive network of outlets and depots offers a wide variety of products. In 2020, Citilink's sales amounted to 132.7 billion rubles, which makes it the third-largest company in Russia.
In 2010, Citilink's data on inventory items, including stock status and prices, was stored in a relational database. This database was accessed through a monolithic service based on the Symfony PHP framework. Year after year, the load was increasing, and the relational database could no longer handle it.
For a long time, Citilink has been using a cache system, which reduced write and read load on the database. However, that system was becoming increasingly complicated. Caches had to be invalidated to guarantee data integrity in case of a reboot. At some point, the cache size reached 100 GB. Now it was more viable to put data in an in-memory database than to cache it.
Four main factors can explain the rapid increase in data and the complexity of architecture planning:
High availability even if a data center is lost
Ability to handle a load of 2 million writes per minute and up to 40,000 reads per minute
Low instance start overhead---one developer can deploy a new instance in one minute
Easy scaling and containerization
The developers tested many DBMSs. Some of them didn't support ACID, and others had a complex, entangled architecture. In 2018, the Citilink team piloted Tarantool in the master-master replication mode. After that, the team attempted to implement Tarantool as a monolithic replacement for the DBMS in use. However, tests showed that Tarantool isn't too efficient when used as a monolithic solution in a data-intensive system. Therefore, the development chose the following approach:
High availability in case of server shutdown or data center failure. Citilink stores its data in two data centers. Each one of them has a number of servers where databases are running. Every server can host several Tarantool instances, depending on the amount of data in those instances. In case a data center goes down, each database instance in it has a replica in the other data center.
Blue-green deployment. Master-master replication in Tarantool allows quickly and easily building a system
to seamlessly transfer application or service traffic from the old version to the new one.
Key takeaway: The solution can process a load of up to 2 million writes per minute and allows continuously keeping the product catalog up-to-date.
The catalog is fully updated in 3 seconds instead of 10–30 minutes
Data is provided in less than 30 milliseconds
70 database instances for the most data-intensive services
No caching, simpler code, more relevant data
DBaaS allows achieving a time to market of one minute instead of two weeks
Increased availability
Tarantool experts will contact you shortly
