Global retail media ad spend is on track to cross $200 billion in 2026, according to a report from WARC, the first time the channel has overtaken combined linear and connected TV advertising worldwide. Behind that shift sits infrastructure that has to hold up under enormous real-time load: millions of ad auctions running every day, thousands of requests per second, with zero tolerance for a shopper seeing a broken page or a missed ad slot.
Stepan Lyakhov works on that kind of infrastructure. He’s built high-load systems in logistics, fintech, and advertising: at Vi.Tech he got marketplace search for 3M+ products down to a 200ms SLA at 500+ RPS, and at Magnit OMNI he designed a multi-vertical advertising platform from scratch that now handles over 1000 RPS and 1.5 million ad queues.
We talked to Stepan about how architecture like that gets built, why Go became his primary tool, and how he sees the future of backend engineering as AI gets woven into infrastructure.
You found your passion for engineering back in 6th grade, when you wrote your first program, then moved from a small village to a city to pursue it. How did that early drive shape you as an engineer?
Stepan Lyakhov:
As a kid I was always asking how things worked. My brother and I would walk around and talk about biology: how nature works, why insects can fly. But the question that stuck with me most was how the human brain works. My brother couldn’t answer it, and that’s when I realized there are still things we understand very poorly. That excited me.
Around the same time I discovered games built around AI and robots, things like Portal 2 and Deus Ex. That’s what planted the idea that I wanted to build something like that myself.
I started learning programming, got into circuits and mechanisms, watched shows about robots making their own decisions, noticed technologies like search engines. That curiosity led me into engineering. I didn’t yet know what kind of engineer I’d become, but the direction was clear.
You’ve worked in logistics, fintech, and advertising. Why is Go your primary tool for building scalable systems?
Stepan Lyakhov:
At university I went through Pascal, C, C++, and my first commercial language was Java: popular, but loaded with heavyweight constructs. When Go started picking up popularity, I gave it a try and realized it lets you write simple, fast, readable code with far fewer constructs.
But the real killer feature is how easy Go makes concurrent code. A goroutine starts with basically one keyword. I liked C too, for its conciseness and control over memory, but it stayed low-level. Go found a comfortable balance. That simplicity around concurrency is what won me over, and with the right microservice architecture, Go lets you build and ship focused services fast across very different domains.
At Vi.Tech you worked on search and catalog for a marketplace with 3M+ products. What architectural decisions at the Go and Elasticsearch level kept the SLA at 200ms under 500+ RPS?
Stepan Lyakhov:
You need to split it into two parts: processing the query in the Go microservice, and optimizing Elasticsearch itself.
On the Go side, the request has to be processed in 20–30ms: extracting stop words, guessing a likely category, or spotting a color in the query and turning it into a structured filter. The goal is to offload as much as possible from full-text search onto filters.
Then the harder part starts. It comes down to how the index is designed and which features are switched on: typo tolerance, prefix search, order-independence. All of that is a trade-off. More features mean more compute, and at some point the 200ms SLA stops holding. That’s where experience matters, understanding how these mechanisms work internally, not overcomplicating the query, and balancing search quality against compute cost and latency.
You cut catalog indexing time by 66% — from 6 hours to 2 — and sped up data migration by 70% for datasets over 20GB. How do you build data pipelines so massive updates don’t break the production SLA?
Stepan Lyakhov:
Two stages here too: data collection, and how indexing is configured in Elasticsearch.
Product data (attributes, titles, descriptions, stock) is scattered across different systems, and it has to be pulled together consistently. The key is keeping data in a structure that lets a full reindex make as few network calls as possible, enriching the product incrementally before it’s sent to Elasticsearch. That becomes an architecture question: where to store data, in what format, which Kafka topics tie it together so the final structure stays flat.
Memory management matters too. With a million products you can easily rack up hundreds of millions of allocations just from working with slices and hash maps constantly. Preallocating memory instead of asking the OS for chunks nonstop saves real resources on a big indexing job.
On the Elasticsearch side, separating the read index from the write index matters a lot: running search and indexing on the same index at once hurts performance badly. Bulk indexing helps too, sending documents in large batches instead of one at a time. Once the new index is built and validated, you just switch traffic over. It’s essentially an alias change, so the heavy indexing work never touches the client-facing SLA.
At Magnit OMNI you built a multi-vertical advertising platform from scratch — over 10 microservices, handling 1000+ RPS and managing 1.5M+ ad queues. Which design pattern proved most effective for real-time ad auctions?
Stepan Lyakhov:
First, you need to understand the business domain. That’s what tells you where you can cut corners, where perfect consistency doesn’t actually matter to the business. Second, separate reads from writes. Advertising almost always gets bolted onto an existing user flow, search, a catalog, and it can’t break that flow.
So the architecture needs to either show an ad safely or just skip it if the SLA won’t hold, while the user still gets the data they came for. The ad component should never become a bottleneck for the core product.
The read path is heavily cached and strictly time-limited. Setting up an ad entity is a multi-step process, so that asynchronous setup should stay separate from the ad actually going live in production. And you have to keep monitoring ad quality constantly: an irrelevant ad can seriously damage metrics, both for the ad system and for search results.
You built the hiring process for the Golang team — a 5-stage technical interview, and personally ran 30+ interviews. What do you look for first when hiring a senior engineer for extreme loads?
Stepan Lyakhov:
The main thing is not to overcomplicate hiring. It’s already stressful for the candidate, and it costs the company time and resources. The hard part is figuring out exactly which skills the role actually needs. There are more candidates than open roles right now, so hiring has gotten more competitive, and companies need to assess candidates more carefully.
We structured the funnel so we could cheaply screen for fundamental distributed-systems knowledge early, a short questionnaire, for example. Then it moves into stages on high-load systems, Go itself, and practical work with it.
I also look hard at business-domain understanding, or at least the ability to pick it up fast. A senior engineer needs to grasp what the business is trying to achieve, because they’ll be talking to stakeholders who don’t have time to go deep into technical detail. A strong senior can translate business goals into technical requirements and balance cost, complexity, and delivery speed.
You’re active in mentoring and educational programs. How do you see your role in the tech community, and what impact do you want to have on the industry?
Stepan Lyakhov:
I’ve always liked teaching. Even at university, once I understood something, I enjoyed explaining it to classmates. IT became a fashionable way to improve your social and economic position at some point, and there’s nothing wrong with that, but I’ve always wanted to point at something else: software engineering is, first and foremost, an engineering discipline, full of genuinely interesting technical problems.
I want to show people how deep that rabbit hole goes, how much you can build just sitting at a laptop, while picking up real understanding of very different business domains along the way. Technology has become the nervous system of modern business, and that’s interesting to me. Beyond teaching, I want to stay close to where the technology is heading and gradually bring my own engineering perspective to it. And ultimately, I want more people to get into this field. It’s one of the things I’ve been most passionate about.
How do you see the backend engineer’s role evolving as ML gets integrated into core infrastructure — an area where you already have hands-on experience?
Stepan Lyakhov:
I’ve been interested in AI, robotics, and engineering since I was a kid, so I’ve thought a lot about what the world looks like once machine learning and automation are woven deeply into everything we do. Narrowing to IT: I think AI will gradually work its way into almost every kind of software, but for narrow, specific tasks, not one huge AGI doing everything, but lots of small, specialized algorithms integrated as services into existing infrastructure.
Next to almost every service handling some business operation, there could be an AI component watching it, improving the process, or making the interaction feel more human. So you end up with a lot of small “artificial brains” built for specific jobs, not one giant Skynet: modules for analytics, personalization, or spotting abnormal behavior in security systems.
So backend engineers will increasingly need to learn how to fold these AI modules into existing systems. The hard part isn’t building the model itself. It’s understanding where it adds value, integrating it safely and efficiently, and making it a reliable part of a larger production system.
