“I’m into backend”: ideas for Adal Cloud and technology on a motorcycle

On October 3, I attended Yandex’s “I’m into backend” conference in Moscow. It was a packed day: talks on reliability, stream processing, search, and distributed systems; conversations with engineers; and several ideas I want to think through for my own project.

In the past, I usually came to conferences as an organizer. This time, I was there representing my own company and product. I built Adal Cloud from scratch — from the initial idea and development to a full-fledged legal entity and participation in tech parks. Showing up at a conference in this role was a meaningful milestone for me in itself.

I’m building infrastructure for reliable webhook delivery. So I was especially interested in failures, retries, service state, and how systems behave when things go a little off plan. Or completely off plan.

Every talk I chose had something useful in it. In some cases, it was an idea I could try against my own architecture. In others, it was a reason to reconsider a familiar approach. And sometimes it was simply a reminder that engineering fundamentals still matter, no matter how many new tools appear around us.

Configuration should survive infrastructure problems

Vladislav Tyulbashev spoke about delivering configuration to 200,000 hosts during data center failures.

The scale is impressive, but what interested me more was the underlying question: how do you manage a system when the infrastructure you normally rely on is already partially unavailable?

One idea I took from the talk was signed configurations with timestamps. If updates arrive late or out of order after the network recovers, the service must be able to reject a configuration that is older than the one it has already accepted. Otherwise, restored connectivity can unexpectedly roll the system back to an old state.

I separated this into two properties for myself: the authenticity of the configuration and its freshness. A signature helps verify the first. A timestamp or version helps verify the second. These are different questions, and it is useful to keep both explicitly in mind.

This is something I want to think about for Adal Cloud. It does not mean immediately building a separate complex system, but it is definitely worth understanding in advance how nodes will distinguish a current update from a delayed one.

Stream processing: restarts matter too

Alina Shestakova from Positive Technologies spoke about processing an event stream with ML and LLMs, including restarts and scaling stateful components.

For me, this was a good reason to look at a system beyond its normal operating mode. A service may handle an event stream confidently while everything is running and warmed up. Then a release happens, or a restart, or a change in the number of instances — and that is exactly where the interesting questions appear.

What remained in memory? What has already been persisted? Where should processing continue from? What happens to latency while the component returns to a working state?

After this talk, I want to pay closer attention to transitions between system states. For a product that delivers events, this is especially close to home: users expect predictable behavior even while infrastructure is being maintained.

YTsaurus Flow and what processing guarantees really mean

Egor Khairullin presented YTsaurus Flow: stream processing at more than 100 GB/s, with an emphasis on state and processing guarantees.

This again made me think about how easy it is to say “no loss and no duplicates,” and how important it is to understand what exactly stands behind those words.

When discussing event delivery and processing, it is useful to clarify the boundaries of the promise every time: who accepted the event, who stored it, who processed it, and at what point the result can be considered complete. To the user, this may look like one operation. Inside the system, it is a whole sequence of actions.

My takeaway for Adal Cloud is to describe guarantees more precisely and test them against concrete scenarios. The clearer the product promise, the easier it is to evaluate whether the architecture actually fulfills it. This applies to both implementation and documentation.

Vector search: understanding what is inside

Andrey Aksyonov from Avito spoke about the basics of vector search, how it works, and its trade-offs.

This is a bit outside my current tasks, but that is exactly why it was interesting. Sometimes it is useful to choose a talk that expands your technical horizons, even if its content will not turn into a ticket tomorrow.

I took from it a familiar but important engineering principle: before choosing a tool, it is worth understanding how it works and what price you pay for its properties.

There are many AI-related solutions appearing now that are tempting to try simply because they are new. Understanding how search works is a good way to bring the conversation back to concrete requirements: what are we searching for, at what quality, in what time, and over what data?

I like it when a talk leaves me with a clearer sense of the questions I should ask before choosing a technology.

Architecture changes together with the product

Sergey Sinyagin spoke about the evolution of the architecture behind medicine search in Yandex Eats as load increased.

From this topic, I took away a reminder that is especially useful when building your own product: architecture has context. A decision is made for a specific set of requirements, load, and team capabilities. Over time, all of that changes.

That is why stories of evolution are interesting to me: what problem appeared, what became insufficient, what had to be reconsidered. They provide much more food for thought than a finished diagram you might try to copy.

For Adal Cloud, this is a reason to leave room for decisions to change as experience accumulates. It is good to understand the likely direction of growth, but it is even more useful to distinguish between a problem that already exists and one you are only imagining.

Distributed cache: looking at the whole request path

Sergey Akimov spoke about reworking a distributed persistent cache: asynchronous execution and working with composite objects.

What attracts me to topics like this is the chance to look at the entire path of a request. Where does it wait? What data is actually needed? What work is done every time, even though it could be avoided?

This is the way of looking at a problem that I took away for myself. Before choosing another optimization mechanism, it is useful to understand where time and resources are going in the existing process.

For a webhook delivery service, this perspective is useful too: accepting a request, persisting it, attempting delivery, and receiving a response form one user scenario. I want to see it as a whole first, and only then dig into individual parts.

The most useful conversation happened after the talk

I also want to mention how open the speakers and organizers were. It was genuinely nice to see people willing to talk, understand a question, and help. For me, this is an important part of a conference: the chance to discuss your own situation with someone who has solved similar problems.

After the event ended, I noticed Vladislav Tyulbashev and went over to ask him questions about Adal Cloud. It turned into a good conversation: I described what I was working on and received several interesting ideas.

But the advice that stayed with me most was something I phrased for myself like this: do not add complexity until scale requires it.

After seeing a system running on hundreds of thousands of servers, it is easy to get carried away and start mentally moving its design into your own product. That conversation helped me return to the current needs of Adal Cloud. Other people’s experience is useful not only because it gives you things to add to the roadmap, but also because it helps you consciously postpone decisions.

Now I have ideas to think through and a clearer understanding of the questions I should ask my own architecture.

Technology has climbed onto a motorcycle

Over the course of the day, I became more convinced that the pace of change has increased.

Before, you could say that technology was moving forward. With the arrival of AI, it first started running, and then, it seems, climbed onto a motorcycle and rode off. And you are standing there next to your familiar tools thinking: right, looks like it is time to speed up.

It reminds me of Alice Through the Looking-Glass: you have to run just to stay in the same place. For a developer, this increasingly feels like the need to keep learning, try new things, and check which familiar solutions still fit the changed tasks.

At the same time, behind many new products are familiar engineering questions: state, storage, latency, failures, cost, observability. At the conference, I especially felt how useful this foundation is. It helps you understand the next technology and figure out where it is actually worth applying.

I want to follow this movement with curiosity, while making product decisions based on the product’s needs. You can be interested in the newest things and still keep the architecture simple. The advice from the conversation with the speaker fits well with that thought.

And, of course, the buffet

If we are talking about the most pleasant part of the event, the buffet had a very serious chance of taking first place. Everything was genuinely tasty and varied. After a full day of conversations about system reliability, it was nice to confirm that food delivery was also working properly here.

Thanks to the organizers and speakers for a rich day, for being willing to answer questions, and for the opportunity to discuss real engineering problems.

I left with several ideas for Adal Cloud and the desire to explore them in more detail. For one day at a conference, that is a good result.