Yandex for Backend

🏠 Как мы вынесли рекламу в офлайн Меня зовут Юра Журихин, я руководитель разработки наружной рекламы в Поисковых сервисах и ИИ. В нашей бизнес-группе большое количество разных бэкенд-сервисов. И наружная реклама — один из таких нетривиальных примеров. Мы долго занимались онлайн-рекламой и уже успели стать в ней экспертами. Но сейчас я хочу рассказать, с какими вызовами мы столкнулись, когда выносили её в мир офлайна. 👩‍⚕️ Читайте об этом в карточках выше 🔶 На конференции «Я про бэкенд» я более подробно рассказал о методах определения аудитории вблизи физических рекламных экранов и поделился алгоритмами отслеживания видимости рекламы на движущихся носителях. А также объяснил, какие способы помогли нам переосмыслить традиционные методы оценки эффективности наружной рекламы. 📺 Смотрите доклад на ютубе. 📎 Кстати, конференция «Я про бэкенд» пройдёт уже этой осенью — будем много говорить про бэкенд и то, как он меняется в эпоху ML. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🈯️ Приглашаем на Back to Back! Это конференция для бэкенд-инженеров, архитекторов, SRE и техлидов. Поговорим о том, что болит в больших системах: latency, bottlenecks, отказоустойчивость, масштабирование и инфраструктура. А также обсудим архитектурные решения, которые нельзя проверить на слайдах — только в продакшене. Когда и где: 📆 1 августа 📍 Одновременно в Москве, Белграде и Ереване В каждом городе — свой фокус программы: 🟢 В Москве и Ереване собираем инженеров на Architecture & Performance — трек про производительность и реальные продакшен-задачи 🟢 В Москве и Белграде ждём всех, кто дружит с C++, — трек C++ Zero Cost про производительность, системную разработку и инженерные задачи 💹 Но это не всё! На площадках будут активности от команд и сервисов Яндекса. А если не сможете приехать лично — подключайтесь онлайн к любому из городов. 🔶 Полную программу мы соберём к началу июля, но регистрация уже открыта! Так что переходите на страницу своей площадки, чтобы узнать подробности и оставить заявку: 📟 Москва 📟 Белград 📟 Ереван Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔨 Как мы чиним невидимое: сеть в Yandex Cloud 🎙️ Меня зовут Костя Крамлих, я руководитель службы сетевой виртуализации в Yandex Cloud. Недавно я заглянул в гости к ребятам из подкаста «Разбор полётов» — поговорили про сеть, надёжность и немного про стажёров. Что мы обсудили: 🟢 Принцип нашей работы Все Data Plane должны работать полностью при отказе Control Plane — это самое главное и фундаментальное свойство надёжности. Почему? Control Plane — это сложные сервисы с бизнес-логикой, вероятность отказа там гораздо выше. А Data Plane — это то, что реально процессит трафик клиента. Если упал Control Plane — неприятно, но клиент может подождать. Но если перестал работать Data Plane — трафик не идёт. А для пользователя это в 10 раз хуже. 🟢 Мы стремимся обновляться незаметно для клиентов Раньше перезапуск Data Plane ронял трафик. Поэтому мы используем Blue Green Deploy прямо на хосте: привозим на живой сервер две инсталляции Data Plane и плавно переключаем интерфейсы виртуальных машин с одного на другой. Результат — сотни миллисекунд, которые укладываются в TCP-ретрай. И подавляющее число наших клиентов этого вообще никак не замечает. 🟢 Собственная модель учений В большом Яндексе их проводят почти 20 лет: просто отключают один дата-центр фаерволом и смотрят, все ли сервисы выжили. Но в облаке так нельзя: мы не можем диктовать клиентам, как строить резервирование. Поэтому у нас гибридная модель. Раз в две недели на препроде полностью отключаем одну зону. А некоторые сервисы (региональные, консоль) тестируем прямо на проде: они по своему построению должны выдерживать отказ любой зоны. 🔶 Слушайте больше подробностей о том, как мы строим сетевые продукты в Yandex Cloud, в полном выпуске подкаста «Разбор полётов» на сайте, ютубе и в Яндекс Музыке. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 YaFF в опенсорсе: как и зачем мы сделали zero‑copy-представление для Protobuf В высоконагруженных C++-сервисах часто используют Protobuf. Он по-своему удобен, но парсинг миллионов объектов в секунду забирает заметную часть процессорного времени. Переезд на FlatBuffers кажется решением, однако на практике это не «Protobuf без парсинга»: различия в схемах, API и доступе к вложенным данным делают миграцию дорогой и рискованной. 🟢 Мы выложили в опенсорс YaFF (Yet Another Flat Format) — альтернативный способ представления Protobuf для высоконагруженных сервисов. Библиотека позволяет встраиваться в существующую Protobuf-инфраструктуру и работать с данными, но не расходовать ресурсы на их десериализацию. Это даёт возможность экономить до 20% вычислительных мощностей. 🔶 Читайте в статье на Хабре все подробности об архитектуре YaFF. Внутри: тернистый путь к успеху, низкоуровневые детали и красивые цифры бенчмарков. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🧬 Как Яндекс Диск выдерживает сотни гигабит входящего трафика Типичная схема бэкенд-приложения выглядит стандартно: группа экземпляров сервиса и балансировщик перед ними. Пользователь отправляет на него запрос, а тот проксирует его на конкретный инстанс. Эта схема отлично работает на лёгких API-запросах, но рассыпается, как только трафик становится тяжелее. Меня зовут Илья Абрамов, я разработчик в Диске. И в нашем случае речь идёт о массовой загрузке файлов. Миллионы пользователей с разной скоростью интернета загружают данные самых разных размеров — от крошечных документов до многогигабайтных архивов. Хочу рассказать, как мы решили проблему распределения такой нагрузки. ❇️ Что сделали Мы полностью отказались от промежуточных балансировщиков при загрузке файлов. В нашей текущей архитектуре путь данных выглядит иначе: пользователь отправляет тяжёлый трафик напрямую в сервис. Но для этого нам пришлось переосмыслить сам принцип того, как клиент находит нужный сервер, и придумать, как сэкономить сетевые ресурсы. Ведь если хост перегружен, пользователи либо вообще не могут загрузить файл, либо сталкиваются с катастрофическим падением скорости. ❇️ Поэтому мы разделили процесс на два типа запросов: 🟢 Control (управляющие). Это легковесные HTTP-запросы. Их задача — получить одобрение на загрузку и узнать адрес целевого сервера. Они проходят через стандартный балансировщик, так как почти не создают сетевой нагрузки 🟢 Data (данные). Это тяжеловесные потоки байтов, которые идут напрямую от пользователя к выбранному серверу и минуют промежуточные звенья ❇️ Теперь архитектуру загрузки в Диске формируют два ключевых компонента: 🟢 Балансерун (Balancer). Он выбирает наиболее подходящий экземпляр сервиса для конкретного пользователя. Балансерун в реальном времени держит в памяти актуальный список всех живых серверов (через Service Discovery) и мониторит их состояние. И на выходе отдаёт пользователю уникальную ссылку на загрузку 🟢 Кладун (Uploader). Это сервис, который принимает входящий data-запрос по прямой ссылке и сохраняет файл в целевое хранилище 💹 Схема взаимодействия выглядит так: пользователь спрашивает у Балансеруна, куда положить файл → Балансерун анализирует загрузку системы и отвечает: «Вот ссылка на сервер №3» → пользователь открывает прямое соединение с этим сервером и отправляет данные в Кладун. 🔶 В статье на Хабре я рассказал, как мы искали идеальный алгоритм для достижения равномерной утилизации сети на всех аплоадерах (и почему это было не так-то просто), а также как нам пришлось глобально переработать логику и в итоге создать алгоритм HOBA 🤸🏻 Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

📖 Как использовать Temporal Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта. ❇️ Не поддавайтесь иллюзии чистой архитектуры Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы. Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход. ❇️ Как надо делать: 🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK 🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования 🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity 💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность. Какие инструменты могут помочь: 🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение 🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката 🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться ➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫 🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

все

🎙 Мы знаем, что бэкендерам есть что рассказать про серверную сторону AI За последние пару лет искусственный интеллект проник во все сферы. Сложно построить новый проект без умных рекомендательных и генеративных технологий. Появились сотни новых AI-first-продуктов и тысячи AI-фич в обычных сервисах. 🈯️ Приглашаем на «Я про бэкенд 2026». На этой конференции мы поговорим о высоконагруженных рекомендательных, генеративных и других системах под капотом продуктов с AI/ML, а также о вызовах, с которыми сталкиваются их разработчики. В прошлом году было 13 докладов от специалистов из Яндекса, Авито, Т-Банка, Сбера и VK. Например, спикеры рассказали, как выжимать максимум из decoder attention на GPU и как сэкономить 200 тысяч CPU в рекомендательном движке Рекламы. Посмотреть все выступления можно в плейлистах на ютубе или в VK Видео. В этот раз мы ждём ваши доклады на такие темы: 🟢 Архитектура систем с AI/ML 🟢 Работа на стыке бэкенда с железом, в том числе глубокая оптимизация по использованию GPU, CPU, памяти, сети 🟢 Облачные и коммунальные решения, инфраструктура 🟢 Алгоритмы и подходы к решению практических задач 🟢 Хранение и стриминг данных 🟢 MLOps: деплой, эксплуатация, наблюдаемость и так далее 🟢 Любые другие темы, связанные с интересными челленджами на бэкенде 🔶 Отправить заявку на участие можно тут Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 Как мы откатываем за секунду и не ломаем прод Меня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за разработку систем деплоя. Платформа развёртывания входит во внутреннюю инфраструктуру компании, которая решает сложные задачи: от строительства дата-центра до IDE и код-систем. 🎙 В новом выпуске подкаста «В офисе» я объяснил, как устроена платформа, которая обслуживает все деплои Яндекса. Вот три кейса из этого разговора: 1️⃣ Концепция антихрупкости Классический Kubernetes, Docker и OpenSSH не вывозят наши масштаб и требования, поэтому мы написали свой SSH. Это помогает нам находить выход из любой аварии и строить архитектуру таким образом, чтобы поломка одного приложения никак не влияла на весь пайплайн. Зачем? Чтобы любой наш сервис умел деградировать, а не падать. И деградация одного никак не влияла на остальные. 2️⃣ Агентская часть деплоя Система стала настолько сложной (стейт-машина, у которой было больше 17 переходов), что погружение нового разработчика в работу у нас занимало примерно год. Поэтому мы переписали логику на поведенческих деревьях — как в движке для ботов Unreal Engine. Их можно переиспользовать и визуализировать, при этом сложность разработки упала в несколько раз, а новый инженер пишет код в продакшен уже буквально через две недели. 3️⃣ Роллбэки за секунду Чтобы откатить докер-контейнер, нужно было заново его собрать, проинициализировать скрипты, переменные окружения и секреты. Это занимало много времени. Мы придумали механизм снапшотов. Контейнер, на который нужно откатиться, уже есть в системе: он собран, всё разархивировано, переменные окружения и секреты скачаны. Так что для отката остаётся только «исправить симлинк» и запустить ворклоуд. 🔶 В полном выпуске подкаста я также рассказал, как мы обеспечиваем стабильность сервисов, что сложнее всего реализовать в деплой-платформе и как сломать Яндекс Музыку 😄 А ещё объяснил, почему сервисы вообще падают. Полный выпуск подкаста — на ютубе. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💻 Декомпозиция, автоматизация и 15 минут нагрузки Меня зовут Дима Александров, я руководитель технических решений в Яндекс Лавке. За годы работы мне довелось плотно заниматься вопросами надёжности как в Еде, так и в Лавке. А недавно я составил стратегию надёжности, где зафиксировал майндсет и конкретный план действий. Каждый деплой всегда сопряжён с рисками: можно сделать ошибку в коде, подтянуть бажную зависимость или неверно рассчитать нагрузку. Поэтому нужно системно повышать предсказуемость релизов. Что мы для этого делаем: 🟢 Проводим автоматическое нагрузочное тестирование в CI. Перед каждой выкладкой мы запускаем его в изолированном load-окружении. Сервис должен поработать под полной нагрузкой хотя бы 10–15 минут. Этого достаточно, чтобы убедиться, что утилизация ресурсов и тайминги ответов не деградировали по сравнению с прошлым релизом 🟢 Запускаем end-to-end-тесты в продакшене. Мы регулярно проверяем capacity системы в целом с помощью нагрузочного тестирования в проде. Это помогает своевременно заметить нехватку запаса прочности или выловить кривой релиз 🟢 Тотально автоматизируем регресс. Если у вас много ручного тестирования, то ошибок из-за человеческого фактора не избежать. Единственный выход — автоматизировать 75–90% сценариев. Это даёт возможность гонять полный пакет регресс-тестов на каждый релиз 🟢 Декомпозируем изменения. Чтобы сократить шанс что-то внезапно сломать, мы разбиваем приложения на модули, уходим от монолитов на бэке и фронте, изолируем блоки 🟢 Управляем ресурсами автоматически. Система должна сама докидывать их, если обнаружила нехватку. А когда нагрузка спадает — перекидывать мощности, например, на аналитические вычисления 🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, какие два способа помогают снизить ущерб от любого инцидента. И объяснил, что помогает вовремя реагировать на множество алертов в сложной распределённой системе с кучей сервисов Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузками Спасибо всем, кто присоединился поговорить об инфраструктуре, платформах и observability. Было супер 🈯️ Делимся хайлайтами о том, как команда Yandex Infrastructure модернизировала строительство и охлаждение дата-центров, чтобы ускорить внедрение AI: 🟢 Концепция «кампус дата-центров». Для поддержания растущих нагрузок Яндекс изменил подход к размещению вычислительных мощностей. Теперь мы будем объединять независимые дата-центры с одной локацией в кампусы с общей внешней инфраструктурой. Это поможет оптимизировать энергопотребление и увеличить мощности в три раза до 180 МВт — рекорд для России. 🟢 Жидкостное охлаждение. Для его реализации наши инженеры разработали сайдкары — дополнительные стойки с жидкостно-воздушными радиаторами. До недавних пор мы использовали только фрикулинг — охлаждение воздухом. Сайдкары дополнят этот подход без масштабной реконструкции дата-центров. Сочетание двух технологий сделает терморегуляцию дата-центров эффективнее и ускорит адаптацию инфраструктуры к растущим нагрузкам наших сервисов и продуктов внешних партнёров. 🟢 Dev Cluster. Инструмент для динамического распределения GPU-ресурсов поможет разработчикам за несколько кликов настраивать конфигурацию контейнеров для любых задач без сложной настройки. 💹 Наши распределённые хранилища уже работают с эксабайтами данных, обеспечивая вам стабильные платформы разработки и деплоя. Теперь мы готовы к нагрузкам, которые ещё вчера казались предельными. Ждём новые фичи в YandexGPT и других сервисах! 🧠⚡️ Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🚗 Как мы связали бэкенд UMO 5 с телематикой автомобиля На связи Миша Чарзавакян, руководитель разработки Яндекс Электро, и Лёша Косенко из Яндекс Авто. Хотим рассказать, как мы строили Connected Car для нового электромобиля UMO 5 с технологиями Яндекса. Речь об удалённом управлении машиной: согреть салон зимой в минус 15, проверить состояние, отправить команды. Кажется, звучит довольно просто, но давайте заглянем под капот. ❇️ Как устроена телематика в UMO 5 У каждого современного автомобиля есть блок телематики, который отвечает за взаимодействие с внешним миром. Мы пошли не по пути прямой интеграции бэкенда с этим блоком, а сделали cloud-to-cloud. Наш бэкенд общается с сервером партнёра, а тот — уже с телематикой. В обычной схеме это HTTP-трафик для получения состояния и отправки команд + Kafka для результатов команд, алертов и сообщений. И мы думали, что интеграция будет максимально тривиальная. Но нет. ❇️ Главная боль — Kafka У партнёра развёрнут кластер Kafka из трёх инстансов. Когда наш бэкенд к нему подключался, Kafka возвращала список своих внутренних IP-адресов. А драйвер нашего бэкенда пытался подключиться к этим IP, но не мог, потому что это внутренняя сеть партнёра. Мы не понимали, что с этим делать. В нашей команде вообще не было экспертизы в Kafka: в Городских сервисах она не используется. ❇️ Как решили проблему Нам помог самый простой AI-промпт. В Kafka есть выделенный параметр advertised.listeners, который позволяет переопределять IP-адреса кластера Kafka. Мы попросили партнёра прописать на их стороне наши IP. И — о чудо! — всё заработало. 🔶 В полном выступлении мы также рассказали, что ещё есть под капотом электромобиля. Спойлер: там не только батарея 64 кВт/ч и мотор на 200 лошадиных сил 🙃 А ещё мы объяснили, как работает Алиса в UMO и почему она может это делать даже без интернета. Смотрите видео на сайте Городских сервисов, ютубе и в VK Видео. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🏗️ infra.conf’26 уже сегодня: подключайтесь обсудить инфраструктуру, платформы и observability Совсем скоро встретимся, чтобы поговорить о высоких нагрузках, инструментах, базах данных, надёжности, доступности, управлении инцидентами и особенностях эксплуатации инфраструктуры в эпоху ML. Доклады начнутся в 11:00 мск. В программе: 🟢 Как управлять доступами к 1500 системам (и без бутылочных горлышек) 🟢 Зачем нужен механизм выгрузки метаданных объектов в S3 Inventory 🟢 Как освободить разработчиков от рутины с помощью агентов и Kubernetes-операторов 🟢 Что помогает перемещать десятки петабайт данных внутри S3 🔶 Полное расписание Подключайтесь к трансляции на сайте конференции. Для тех, кто будет очно, дополнительно подготовили экспозону и несколько мастер-классов. 🈯️ До встречи на infra.conf’26! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🛎 Приглашаем на Vertis Java Meetup Это встреча разработчиков и инженеров от Яндекс Вертикалей. Мы обсудим практический опыт, новые подходы, реальные задачи и пообщаемся с коллегами и единомышленниками в неформальной атмосфере. Когда и где: 📆 18 июня, 18:00 📍 Екатеринбург, «Ельцин-центр» В программе: 🟢 Как мы используем Temporal в Недвижимости. Герман Михайлов, бэкенд-разработчик в Яндекс Недвижимости, расскажет, как и зачем мы перешли с сервисов-scheduler’ов на Temporal. А также поделится, можно ли (не) построить космолёт на десятки тысяч workflow в секунду и во сколько обойдутся первоклассные наблюдаемость и отказоустойчивость 🟢 CGLIB, Spring AOP и нарушение гарантий JVM. Михаил Черноскутов, бэкенд-разработчик в Яндекс Путешествиях, разберёт реальный случай, где NullPointerException возник на final-поле с инициализацией new ConcurrentHashMap<>(). И расскажет, как Spring через CGLIB создаёт прокси, почему final-методы могут обойти AOP-перехват и что происходит с инициализацией полей при low-level-инстанциации 📟 А после докладов вас ждёт «Громкий вопрос» Это интеллектуально-юмористическая игра из одноимённого интернет-шоу. Каждый участник должен правильно ответить на поставленный вопрос. Но есть нюанс: игроки друг друга совсем не слышат! 🤯 🔶 Зарегистрироваться на Vertis Java Meetup Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🤩 Хотите узнать, о чём мечтали в детстве разработчики Яндекса? Мы тоже хотели, поэтому ко Дню защиты детей наши бэкенд-разработчики заполнили виртуальные анкеты. Мы задали вопросы, чтобы узнать об их детстве, первой написанной программе и школьной оценке по информатике. Спойлер: пятёрок по информатике было много, а преподавателем так никто и не стал 😄 👩‍⚕️ Давайте вместе посмотрим страницы из анкет в карточках выше! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🚀 Делимся записями докладов с Backend Talks от Яндекс 360 Инженеры Яндекс 360 каждый день строят высоконагруженные отказоустойчивые и масштабируемые системы, которые выдерживают больше 1 000 000 RPS: Диск, Телемост, Почту и другие цифровые сервисы. 💹 16 мая в Москве прошла Backend Talks от Яндекс 360 — конференция о разработке, технологиях и будущем. Мы собрали больше 300 гостей офлайн и подготовили для них программу сразу в двух залах: с классическими докладами и воркшопами. А также обменялись опытом, обсудили реальные кейсы и поиграли в настолки. О чём мы поговорили на конференции: 🟢 Направленный ациклический граф в PostgreSQL: как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей. Малик Минубаев, разработчик в B2B-платформе, рассказал, почему стандартные паттерны хранения иерархий не работают для ориентированного ациклического графа. А также сравнил несколько вариантов Closure Table с бенчмарками на реальной нагрузке 🟢 Как Яндекс Диск выдерживает сотни гигабит входящего трафика: устройство балансировки загрузок. Илья Абрамов, разработчик в Диске, разобрал, почему нам не подошёл подход «как у всех», и показал эволюцию алгоритма балансировки загрузок: от наивного Round-Robin до разработки собственного алгоритма 🟢 Как формировать технологический стек и не погибнуть в священных войнах: от хаоса к процессам и техрадару. Дмитрий Сафонов, руководитель команды разработки платформы микросервисов, рассказал, как строить стек для промышленной разработки и разрешать споры о технологиях. А также поделился опытом внедрения Техрадара в Яндекс 360 🟢 Зачем и как бэкендеру расти в карьере в 2026 году. Дмитрий Соломонов, руководитель группы B2B-разработки бэкенда Диска, рассказал, как развивать команду с помощью индивидуальных планов и выбора узкой специализации для разных уровней разработчиков. И поделился, как связать получение знаний с реальными задачами 🟢 Семь раз подумай, один раз пошардируй: как мы начали горизонтально масштабировать метаданные чатов Телемоста. Никита Звонарев, разработчик в Мессенджере, рассказал, что может предпринять команда, когда вертикально масштабироваться уже не получается, а сервису нужно функционировать дальше в условиях возрастающей нагрузки, и как при этом не устроить себе проблемы в будущем 🎙 Мы уже выложили записи докладов на ютуб и в VK Видео для тех, кто не смог посетить конференцию. 📷 А фотографии с мероприятия можно найти вот здесь. 🈯️ Спасибо, что были с нами на Backend Talks Яндекс 360 Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔎 Как мы строили облачную запись и конспектирование в Телемосте Меня зовут Илья Григорьев, я старший бэкенд-разработчик в команде Телемоста. Недавно мы разработали две фичи: AI-конспекты с Алисой Про и облачную запись на Диск. Хочу поделиться, как проектировали архитектуру, ускоряли сборку и спасали воркеры от излишней нагрузки. ❇️ Переход от спагетти к стейт-машинам При проектировании системы мы могли бы просто написать линейный код, который последовательно выполняет все этапы обработки. Но в таком случае любой сбой запускал бы процесс с самого начала и тратил впустую ресурсы на повторные операции, а также заметно увеличивал время ожидания для пользователя. Именно поэтому мы остановились на стейт-машинах, которые дают наглядную модель вместо запутанных условий и позволяют гарантированно возобновлять работу с последнего зафиксированного состояния. После каждого успешного перехода мы сохраняем прогресс в базу — и весь конвейер обработки становится надёжным. Ещё мы внедрили новый тип состояния — Waiting State, чтобы стейт-машина не запускалась между проверками и не занимала ресурсы бэкенда. ❇️ Оптимизация, слоты и сегменты Для кардинального ускорения сборки мы применили парадигму MapReduce. Итоговую видеозапись можно представить как совокупность непересекающихся во времени отрезков — сегментов. Что мы с этим сделали: 🟢 Разбили запись на независимые сегменты по 4–5 минут. Внутри них сетка участников статична — никто не заходит в конференцию и не выходит из неё, что упрощает финальную сборку кадра 🟢 Каждый сегмент разложили на слоты. Короткое видео одного конкретного пользователя в рамках определённого интервала Теперь процесс выглядит так: мы запускаем сотни независимых задач на сборку слотов, распределяем их по всему пулу воркеров и объединяем в сегменты. А в конце сводим всё это в единый файл. ❇️ Внезапный вызов Из-за перехода на MapReduce резко выросло количество задач. Одна конференция генерирует десятки и сотни мелких тасок, и при большом потоке записей воркеры перестают справляться с очередью. 💹 Чтобы разгрести этот завал, мы выполнили две вещи: 1️⃣ Масштабирование. Подобрали оптимальное соотношение CPU и RAM, что помогло расширить пул воркеров 2️⃣ Тонкую настройку FFmpeg. Оптимизировали параметры энкодинга, чтобы снизить нагрузку на процессор без потери качества ❗️ В итоге подготовка часовой записи сократилась в 30 раз 🔶 Читайте больше подробностей в статье на Хабре. Там я объяснил, как именно работает Waiting State и как мы красиво автоматизировали ретраи. А также показал, как выглядит работа с FFmpeg в Java, и рассказал, как мы ищем задержки в аудио- и видеоданных. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

☕ С днём рождения, Java! Поздравляем всех, кто пишет, поддерживает или ревьюит Java-код. Языку исполнился 31 год, и в честь этого мы хотим поделиться интересными фактами о нём, которые вы могли не знать: 🟢 Write Once, Run Anywhere — не просто маркетинг Благодаря JVM код действительно работает везде. И хотя изначально Java задумывался для бытовой электроники, в итоге он стал королём банков, бирж, биг-даты и Android-приложений. 🟢 Переломный релиз Java 8 (2014): лямбды, новый API для работы с датами и стримы. Последние до сих пор остаются самой узнаваемой фичей языка. 🟢 В Java редко добавляют новые ключевые слова Это происходит из-за обратной совместимости. Например, enum раньше могло быть именем переменной. Новые ключевые слова — только контекстно зависимые. 🟢 Победа кофеина Джеймс Гослинг придумал имя Java в честь сорта кофе, который пили в офисе. Правда, он чуть было не назвал язык Oak, но такое имя уже оказалось занято. 🈯️ С днём рождения, Java! 31 год — солидный возраст для языка, но он продолжает развиваться и удивлять. С праздником, разработчики! 😉 Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 Строим эффективный Feature Store на YDB Меня зовут Паша Попов, я руковожу группой разработки технологий эффективности Такси. Хочу рассказать историю про Avalon — наш Feature Store, который является масштабируемым и производительным хранилищем с низкой задержкой. В нём можно структурировать признаки по иерархии «каталог/файл», получать к ним быстрый доступ из рантайма и контролировать их жизненный цикл. А также автоматически отслеживать актуальность данных. 🟢 Всё началось с задачи: «Раз в сутки мы размечаем атрибуты пользователей. А дальше, в рантайме, хотим принимать решения в зависимости от того, проставлен атрибут на пользователя или нет». 🟢 Что нам нужно было сделать: дать сервисам универсальный способ получать обновляемые данные с низкой latency, без участия разработчиков или других команд. 🔍 Предшественник Avalon В Городских сервисах у нас был сервис с PostgreSQL под капотом для хранения бинарных признаков. Он задумывался как способ быстро и экспериментально размечать аудиторию. И уже на основе полученных результатов заказывать доработки в нужных сервисах. Но с ним возникло две проблемы: 1️⃣ Пользователи — аналитики и разработчики — хотели загружать слишком много данных. PostgreSQL нужно масштабировать вручную 2️⃣ Признаки в сервисе имели бинарную природу: отвечали на вопрос только «да» или «нет». Если мы хотим узнать, например, количество поездок водителя за всё время, то такой подход уже не поможет ➖ Так появился он — Avalon Мы создали инструмент, который позволяет удобно хранить, структурировать и быстро получать самые разные пользовательские признаки. Роль СУБД для него выполняет YDB, что позволяет достичь высокой отказоустойчивости и горизонтального масштабирования. При разработке системы у нас было несколько важных требований: 🟢 Она должна неограниченно масштабироваться 🟢 Должна быть возможность хранить не только бинарные значения, но и признаки с произвольной структурой 🟢 Должен быть удобный реестр признаков, чтобы понимать, кто ими пользуется Сейчас в системе хранится около 3 Тб данных и 6,5 млрд ключей. Всего используется 2048 шардов YDB. Нагрузка — 100 000 RPS на чтение, 30 000 RPS на запись, при этом задержка в P95 — около 5 мс. 🦾 Что под капотом 🟢 Точка входа в систему — сервис Avalon Proxy. Мы строили структуру так, чтобы данные хранились в абстрактных хранилищах, а для пользователя это было скрыто за прокси 🟢 Для масштабирования — UGCDB Framework. Key-value-хранилище задаёт определённые правила работы с данными и позволяет описывать их логическую схему 🟢 Шардирование из коробки — YDB 🟢 CDC (Change Data Capture). Для отслеживания изменения данных с течением времени 🔶 Читайте все подробности в статье на Хабре. Там я рассказал, какие задачи решает Change Data Capture, и поделился, как в Avalon работает хранение данных и происходит их обновление и получение в YDB. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🧬 Apache Flink + YTsaurus = ? Меня зовут Данил Сабиров, я руководитель группы развития потоковой обработки данных в Яндекс Go. Хочу рассказать, как мы с командой разработали коннектор между Apache Flink и YTsaurus под высокие нагрузки нашей платформы. ❇️ Зачем мы это затеяли У нас долгое время жили два контура обработки данных — потоковый и батчевый. Они читали одни и те же сырые события и считали одинаковые метрики, но иногда выдавали разные результаты. Real-time-пайплайн показывал рост GMV на 5%, а батчевый пересчёт — падение на 2%. Возникал закономерный вопрос: каким данным верить? Мы решили сделать стриминг единственным источником правды, а все трансформации доверить Apache Flink. Но он на тот момент не умел работать с YTsaurus. Готовой интеграции не было, а требования к нашей платформе жёсткие: сотни тысяч сообщений в секунду на запись, десятки тысяч lookup-запросов и E2E-обработка данных менее 5 секунд. Пришлось создавать коннектор с нуля 🤔 ❇️ Что мы сделали 🟢 Научили Flink писать в YTsaurus Построение RAW- и ODS-слоёв начинается с выгрузки данных. Нам нужно было, чтобы пайплайн надёжно и быстро сохранял потоки событий, поэтому мы приступили к разработке именно с Sink-коннектора. Запись в YTsaurus идёт в динамические таблицы — это локальный аналог HBase. Этот процесс обязательно оборачивается в транзакцию, куда мы добавляем изменения. Мы изучили исходники YTsaurus-клиента и нашли полезную особенность: добавленная в транзакцию модификация сразу улетает в базу, а не копится в памяти клиента. А чтобы не грузить сеть одиночными вызовами, мы реализовали батчинг. Отправляем модификации пачками и не ждём закрытия транзакции. 🟢 Разогнали чтение со 100 до 15 000 RPS Для построения ODM-слоя мы обогащали потоки (LEFT JOIN ... FOR SYSTEM_TIME AS OF) в реальном времени. Чтобы это работало с YTsaurus, нам нужно было сделать lookup-коннектор, который можно вызывать на каждый входящий ивент, что позволяет не копить сообщения. Но наш RPC-прокси в YTsaurus физически не успевал обрабатывать последовательные синхронные запросы с нужной скоростью. К счастью, Flink умеет делать асинхронные лукапы. Для этого существует класс AsyncLookupFunction, нам лишь потребовалось создать его наследника. Далее в методе open мы развернули ThreadPoolExecutor, в который попадали задачи на вызов синхронной реализации lookup-коннектора. А Flink взял на себя оркестрацию параллельных запросов. 🟢 Перевели вычисления на единый стандарт Flink отлично справляется с трансформациями в стриминге, так что мы заставили его пересчитывать историю прямо внутри инфраструктуры YTsaurus. Взяли ядро Flink и упаковали его как вычислительный движок прямо внутрь Map-операции. Механика работает следующим образом: 1️⃣ YTsaurus забирает на себя тяжёлую работу по чтению с дисков и оркестрации распределённого выполнения 2️⃣ База нарезает входные данные на сплиты и подаёт их бинарным потоком в stdin нашего процесса 3️⃣ Flink подхватывает этот поток, прогоняет через логику пайплайна и отдаёт результат в stdout 4️⃣ YTsaurus читает выходной поток и прозрачно складывает данные в финальные таблицы ❇️ Что в итоге Мы обеспечили консистентность данных, снизили задержки и можем использовать единый код для стриминга и батч-обработки. Кстати, мы выложили наш коннектор к YTsaurus в опенсорс. Можно свободно его загрузить, протестировать запись в динамические таблицы, настроить lookup-операции под свои пайплайны и забрать готовый YSON-форматтер. 🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, с какими проблемами мы столкнулись в процессе создания коннектора и как их решили. А также объяснил, какой профит даёт конечным разработчикам наш подход (несмотря на одно строгое ограничение), и поделился схемами, таблицами и выводами. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend