Skip to content
back to the episode
Episode summary2025CTO

Architecture: Quality Attributes First, Trade-offs Later

Alexander Polomodov hosts his colleague Daniil Kuleshov — a Staff engineer in the Architecture Research and Transformation unit, in his seventh year at the company and his twentieth in IT. The talk runs from a military town and QBasic through directory sites, an RTB startup and an ad platform to personal authorisation and advice on the discipline of learning.

Code of Leadership · episode #479 min read

This summary is shorter than the full episode; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

A military town, school and QBasic

Daniil corrects his host: not eight years at the company but seven, since August, though his official IT record is exactly twenty years — the first employment-book entry dates to 2005, his third year at university. His unit grew out of a project code-named 100M: the business was growing fast and the systems had to be ready. From there comes the architecture review: a team prepares, representatives of the key verticals sit in — information security, infrastructure, reliability, product areas — and of thousands of services only the business-critical and above are reviewed. Daniil adds a caveat: he measures scalability and reliability not of a service or system but of what the company delivers to its users. He grew up in a serviceman's family, in a small Krasnoyarsk-region town whose single school owed its strongest teachers to servicemen's wives, and as a child he meant to become a military doctor.

In year seven the family moved to Nizhny Novgorod, where his mother got the straight-A pupil into a teaching grammar school with three languages — German, English and Latin — and a humanities bias. The computer science teacher, Svetlana Nikolaevna, pulled him into IT: with no computer at home for a long time, he haunted the school lab and its Windows 3.1 machines, where she opened up BASIC for him. 3D Max was affordable to few, so the two of them added a third axis with ordinary mathematical transforms inside QBasic: a flat figure turned three-dimensional and rotated by given parameters. He gave two senior school years to it and admits he copied the harder integral transforms without understanding them — he worked them out only at university, which he entered on radio physics after a strong school physicist, transferring to computational mathematics by his third year. He is grateful to the physicists anyway: they taught students to think, and their credit test was harder than the exam.

02

Directories, advertising and a Yandex ban

He started earning early: assembling desktop machines, and once Flash MX arrived, writing banners and wrappers in ActionScript — advertising, in effect. In his third year he, a fellow student and the student's elder brother took on their own product, XMS, Extended Management System: a box of pluggable modules meant to be more than a CMS. Websites paid for it — a designer draws, they build the markup and deploy over SFTP — and then US clients appeared with PayPal integrations and e-learning systems: demand for online education existed by 2006 and 2007, though the explosion, Alexander adds, came later with massive open courses. The next client was a national alliance of directory publishers they reached in Nizhny Novgorod, a competitor of Yellow Pages, which had realised paper was going away: the team digitised the whole cycle — code for typesetting the books, a system for the information department, personal accounts online.

There the first lesson in customer focus landed: the information department met the beautifully rewritten form with a stopwatch — a clerk filled the old, ugly one in 35 seconds and the new one in three minutes, and half a year of work was buried. High load came with growth: the directories covered some fifty cities, and six to eight thousand unique visitors a day with spikes of 300 to 400 requests per second forced work on scaling and cache invalidation; calls were tracked through pools of dedicated numbers — call tracking, as Alexander names it. Monetisation, in Daniil's own hedged words, to some degree killed the user experience: management pushed less relevant cards up the results, there was no product analytics, people searched less, and the answer was that the money was coming in. Over-optimisation dealt the heavy blow: Yandex banned the whole network, traffic fell roughly thirtyfold and took a year to recover. Daniil left on his own for government-contract outsourcing, where the team tried XP and Agile inside while a state standard nailed the scope down outside, with round-the-clock work before delivery.

03

RTB startup, the bank and authorisation

Chasing the high load from conference talks, he moved to Moscow and found a queue for vacancies instead of the familiar "come and start work". An RTB startup took him, and at Alexander's request Daniil unpacks the acronyms: an SSP registers sites willing to give up an ad slot; a DSP sets the strategy and bids in a second-price auction over Open RTB; a DMP glues cookies with heuristics into a non-personalised portrait — gender, age, interests — so a manager can aim a creative at a segment, paid by CPA or CPM. Alexander adds that American programmatic consolidated in the mid-2000s, Google having bought DoubleClick along the way. The investor, a doctor of economics who made his money in construction, treated it as an interest and let people experiment: the stack mixed C++, PHP, Java, Hadoop and Vertica. Alexander suspects a power vacuum where the lead is whoever brings order, but Daniil adds that the startup had a strong CTO and managers bringing in modern practices — Planning Poker estimates, demos and retrospectives. Retrospectives came out crooked until an external expert was invited: hence the advice not to fear asking for help.

Former colleagues brought Daniil into the bank, where Alexander interviewed him alone in a meeting room built for twenty, the other interviewers never having arrived; the induction talk came from Oliver Hughes, then chief executive, whose "do not be afraid to make mistakes, just do it" the guest still repeats. The work was familiar: an ad platform bought in 2012, whose management system was the control plane, with the data plane in C++ and Scala. The monolith was split into SSP, DSP and DMP, but committing to every client at once produced what Alexander likens to handing out eight CPUs when you have one, while the matrix structure made developers re-learn someone else's domain every two or three days. Then Alexander handed him the personal authorisation project: a year of customer development, quality attributes and constraints instead of pros and cons, a load-tested proof of concept — and the discovery that a much-praised open-source solution suited a different load profile. The model was simplified but contract compatibility kept, and the team became a centre of expertise on distributed databases. The close covers work-life balance, eating the frog first thing and fixed hours for learning; architecture review is promised as a second episode.

Takeaways

What to take away

  1. 01A year-long customer development decays as it runs: Daniil advises picking the key stakeholders, the corner cases and both the simplest and the hardest scenario, and building the tool around them.
  2. 02An architectural choice cannot come from pros and cons — that compares a circle with a square; start from quality attributes and constraints, derive the significant requirements, then load-test a proof of concept on your own infrastructure.
  3. 03A failed technology is worth turning into an asset: after the unsuitable open-source solution the team became a centre of expertise on distributed databases other teams now consult.
  4. 04A responsibility matrix where one engineer owns a whole set of important services makes the socio-technical system fragile, and switching domains every two or three days hurts time to market.

Sources