back to the presentation
concise summary2019

Evolution of tinkoff.ru over 3 years

Over the course of three years, Tinkoff.ru went through not one big transition, but several related evolutions: the frontend monolith turned into a set of independently developed applications, content management was separated from releases, and personalization rules grew into an experimental ML platform. The story shows how to change a working sales channel without stopping product development.

November 22, 2019ArchDays 20197 min read

This concise summary is based on automatic captions from the recording and presentation slides. It has been shortened and edited; it is not a verbatim transcript.

The main thread
01

Frontend: from monolith to product applications

In 2016, the public site was a React monolith with a common repository, infrastructure and release. At first, the team did not rewrite it entirely: they identified repeatable blocks, forms and tracking, made common components and agreed on contracts. New product parts were created nearby, and old ones were gradually transferred to the platform.

As product teams grew, they were given separate applications, repositories, and release responsibilities. Common engines became dependencies that were developed by the core team according to the internal product model. Microfrontends appeared here not as a technology for the sake of technology, but as a coincidence of the boundaries of code and ownership. Independence required versioning, documentation, compatibility, and a clear update path: without this, the common platform just moves the central bottleneck to another repository.

02

CMS and content without app release

The old CMS was closely tied to templates and frontend release. The page change went through development and general release, so marketing hypotheses were waiting for the engineering cycle. The new model presented the page as a composition of known blocks with a verifiable configuration. Editors were able to collect and publish content without releasing the application, and developers focused on developing blocks, contracts, security and platform performance.

The transition was also gradual: the new system picked up scripts one at a time while the old one continued to serve the rest. A team that both understood the architecture and worked with real editors and products was essential. An isolated group of architects might design a clean but inconvenient system. The platform becomes useful only close to consumers, and its roadmap is formed from repetitive tasks and measurable reduction in publication time.

03

Personalization and evolutionary lessons

At first, personalization was based on manual rules and A/B tests: the segment determined the page option, events connected the impression with the application, and statistics chose the winner. With the growing number of products and simultaneous experiments, a platform was needed that could resolve conflicts, conduct audits, and calculate the results. The next step is a predictor on Vowpal Wabbit, which selects an option based on the user’s context. ML turned out to be an extension of a reliable experimental loop, and not a replacement for analytics.

The main lesson is that architecture and organization change together. New application boundaries required product owners, platform teams, and compatibility rules; independent editors - new contracts and control; personalization of the general data infrastructure. A large system cannot be improved by one revolution: you need to maintain business flow, build a new opportunity nearby, transfer customers and remove the old one. Each stage must provide benefits until the entire target picture is completed.

Takeaways

What to take away

  1. 01Evolutionary migration preserves the food supply: a new solution first proves its value next to the old one.
  2. 02Microfrontends are useful when application boundaries coincide with ownership and independent release of teams.
  3. 03A release-free CMS decouples the speed of content hypotheses from the engineering cycle while maintaining verifiable platform contracts.
  4. 04ML personalization makes sense on top of mature events, experiments, and analytics, not instead of them.
Share