Это YouTube-канал сообщества бэкенд-разработчиков от Яндекса. Рассказываем о наших командах, технологиях и приглашаем на митапы и конференции от Яндекса. dmotliai
Чтобы пользователи оставались довольны, разработчикам часто приходится искать компромисс между качеством и скоростью поисковой системы. Но что, если 50% выручки (GMV) приносят всего несколько сотен запросов — можно ли сделать так, чтобы они выполнялись максимально точно и быстро?
👨💻 Об этом на примере поиска в Яндекс Лавке расскажет Алексей Щекалёв, ML-разработчик, на митапе Яндекс Tech Tour в Казани.
💹 Немного спойлеров о его докладе «LLM Cache в поиске Яндекс Лавки»
Классический пайплайн поиска (кандидаты → фильтрация → ранжирование) хорошо работает, пока ассортимент стабилен. Но в Лавке каждую неделю появляются новые товары: от цветов до корма для животных. Модели просто не знают о новинках, и candidate generation начинает сбоить.
Решение — LLM Cache, но не в привычном смысле генерации текста, а как инструмент предрасчёта релевантных товаров под самые частые запросы.
❇ В чём суть
Мы заранее, в офлайн-режиме, просканировали декартово произведение «запрос × ассортимент» и для каждого подобрали оптимальное число кандидатов. А готовые списки разместили в шардированном кеше.
В рантайме поиск теперь в первую очередь обращается к этому каталогу, что не только снимает нагрузку, но и решает проблему нового ассортимента. Кроме того, мы получаем значительный выигрыш в скорости.
❇ Из доклада вы узнаете:
🟢 Как мы внедрили LLM Cache в наш пайплайн
🟢 Как построить шардированный кеш для миллионов пар «запрос × товар»
🟢 В чём отличие от типичной схемы ANN + rerank
❇ Что ещё будет на Яндекс Tech Tour
Мы покажем внутреннюю кухню инфраструктуры и продуктовой разработки в Яндекс Еде, Маркете и Лавке. Будем много вайбкодить, обсуждать реальные задачи на кейс-лабах и слушать хардовые доклады. А ещё поделимся опытом разработки и работы с фреймворками на C++, Java, Golang.
💹 Как текст в логах замедляет браузер и что можно с этим сделать?
Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера и улучшаю опенсорсные решения, которые там используют.
История началась со стажировки, на которой я взялся сократить полные пути в логах до имени path/to/filename → filename. Казалось бы, простейшая задачка, но она потянула за собой целую цепочку проблем: от увеличения размера DLL до необходимости залезть в исходный код компилятора Clang, чтобы добавить в него новый макрос.
Это рассказ о том, как я решил проблему полных путей в логах, после чего получил офер на позицию мидл-разработчика. И наглядный пример того, как небольшие оптимизации помогают двигать вперёд большие проекты.
❇ Зачем вообще сокращать полные пути до имени файла?
При запуске того же Браузера в ОЗУ загружаются разные файлы, которые необходимы для работы программы. И чем больше размер требуемых файлов, тем дольше будет идти старт приложения. Это особенно больно для пользователей без SSD. Попробуете угадать, какой процент таких среди аудитории Яндекс Браузера? Ответ: 27%.
Размер сборки приложения влияет не только на запуск, но и на объём регулярных обновлений. Следовательно, мы не должны увеличивать ключевые файлы без крайней необходимости.
Но этот подход дал обратный эффект! DLL увеличилась, потому что при одновременном использовании обоих макросов логирования в одном файле в DLL запишутся две разные строки: имя файла для модифицированного макроса LOG и полный путь для другого макроса FROM_HERE. Получается, что суммарный размер строк стал больше, а не меньше. Выходит, чтобы решить задачу, надо улучшить оба макроса одновременно.
❇ В статье на Хабре я разбираю:
🟢 Небольшое изменение, ускорившее старт Браузера на 2% 🟢 Что такое __builtin_FILE() и чем он отличается от обычного __FILE__ 🟢 Как я создал __builtin_FILE_NAME() в Clang, когда понял, что нужного макроса не существует 🟢 Почему уменьшение DLL без негативных эффектов — это успех
🔶 Читайте полную версию статьи на Хабре: habr.com/ru/companies/yandex/articles/952410/ Там я подробно рассказываю, как повлиял на инструмент, которым пользуются разработчики по всему миру.
Привет! А у нас новость: команда Яндекс 360 зовёт бэкенд-разработчиков и архитекторов на митап.
🧬 На нём разберём архитектуру облачной записи встреч, наведём порядок в API и покажем, как простые решения спасают сервисы.
🗺 Санкт-Петербург 📆 13 ноября, 19:00–23:00
В программе:
🟢 Илья Григорьев, разработчик бэкенда Телемоста. Покажет на реальном примере, как проектировать большие стейт-машины, и поделится хитростями для многократного ускорения асинхронной обработки медиаданных
🟢 Артемий Коцюбенко, разработчик протокольных сервисов Почты. Объяснит на примере реального сервиса, почему архитектурная простота очень важна и что может пойти не так, если не придерживаться этого принципа
🟢 Никита Ломакин, разработчик в команде Техплатформы. Расскажет, почему важно следить за качеством API, и поделится практиками, которыми пользуются в Яндекс 360 и которые позволят сделать ваш API более качественным и удобным
✨ А после докладов вас будут ждать афтерпати и нетворкинг.
Иногда в системах возникают коварные ситуации: проверки состояния показывают, что всё хорошо, но по факту ничего не работает. Это называется «серый отказ».
На связи Александр Душеин, технический лидер команды архитекторов Yandex Cloud. Давайте разбираться, как возникают серые отказы и как Zonal Shift помогает с ними справиться.
❇ Что-то может пойти не так на уровне сети
Один из вариантов серого отказа — сбой в сетевой связности, когда в одних направлениях она работает, а в других нет. Например, могут сбоить каналы интернет‑провайдеров.
Целевые ресурсы бэкенда в повреждённой зоне доступности могут по‑прежнему отвечать на все проверки Health Check и показывать зелёный статус. При этом они перестают обрабатывать весь трафик или начинают генерировать ошибки.
Эта ситуация может нарушить работу системы, ведь сетевой балансировщик всё ещё будет рассчитывать на бэкенд со сбоями и статусом «Всё ок!».
❇ Иногда что-то ломается на уровне приложения
На уровне L7 ситуация с серыми отказами становится серьёзнее. Частичная деградация связности может привести к дополнительному ухудшению запросов между зонами: трафик из больной зоны начинает переливаться в здоровую. И наоборот.
🧬 Для управления такими ситуациями мы создали Zonal Shift
Это инструмент для управляемого закрытия конкретной зоны доступности на конкретном балансировщике. Он пригодится не только в ситуации частичных отказов, но и при необходимости закрыть балансировку в зоне доступности, чтобы провести учения или регламентные работы.
Zonal Shift поддерживает два режима:
🟢 Полное закрытие всех балансировщиков в зоне доступности
🟢 Закрытие тех, на которые клиент сам повесил признак «Можно потушить»
Для сетевого балансировщика этот признак позволит сразу перераспределить трафик в другие зоны. Функциональность Zonal Shift поддерживается и на уровне L7, так что в более сложной схеме также можно избежать каскадного сбоя из‑за амплификации. Мы можем явно выключать балансировку на бэкенды в зоне доступности, а семантически это работает аналогично сетевой балансировке (NLB).
При этом важно помнить, что Zonal Shift закрывает не зону, а балансировку трафика в неё. Например, если у клиента есть Kubernetes в нескольких зонах доступности, то микросервисы также будут размещены в них и будут общаться между собой горизонтально.
❇ Что важно учесть
Мы изучили графики и журналы по следам инцидентов и заметили, что настройки балансировки часто бывают неоптимальны. Это приводит к сбоям в работе сервисов, поэтому мы сформулировали правила на уровне NLB:
🟢 Делать проверки готовности целевых ресурсов с интервалом не более 3 секунд
🟢 Указывать корректный порог работоспособности и неработоспособности. Значения должны быть строго больше одной проверки
🟢 Следить за тем, чтобы реализация проверок не требовала много ресурсов для генерации ответа. Тогда не будет повышенной нагрузки
В ней же мы рассказываем, какие именно настройки балансировщиков критически важны для защиты от серых отказов, и делимся подробными инструкциями по отказоустойчивости.
Это открытое мероприятие Яндекса, на котором разработчики делятся опытом, рассказывают, что прячется под капотом сервисов, и честно отвечают даже на самые каверзные вопросы.
📆 1 ноября в Москве вместе с экспертами обсудим практики разработки и заглянем в закулисье сервисов Яндекса.
В программе:
🟢 Александр Демиденко, старший разработчик бэкенда Yandex Cloud. Выступит с докладом про Userspace Networking на Go
🟢 Игорь Панасюк, Go-разработчик Плюса и Финтеха. Расскажет про новый сборщик мусора в Go 1.25
🟢 Степан Пестерников, CTO Яндекс Игр. Покажет, как в сервисе используют KV-хранилища и кеши
🟢 Александр Никитин, старший разработчик Яндекс Маркета. Расскажет про трассировку логики вычислений с помощью debug tree
✨ А после докладов, конечно же, устроим афтерпати с глинтвейном и уютным нетворкингом.
Редакторы кода и инструменты для разработчиков — это целая индустрия. Когда-то переименование переменной казалось подвигом, а сегодня IDE делают десятки сложнейших трансформаций, и при этом программа остаётся корректной.
Это и многое другое Кирилл Мокевнин обсудил в выпуске подкаста «Организованное программирование» с Дмитрием Ивановым, руководителем платформы SourceCraft, Yandex B2B Tech.
А ещё внутри:
🟢 Почему IntelliJ IDEA стала революцией: тайна рефакторинга
🟢 История создания Kotlin: JetBrains против Scala и медленного Java
🟢 Почему редакторы тормозят: что не так с Java и UI
🚀 Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем
За годы работы инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются миллионы людей и тысячи предприятий. Мы знаем, что такое highload и отказоустойчивость не из книжек и докладов, а из реальной многолетней практики.
В этом проекте мы хотим поделиться опытом и рассказать, как решаем наши задачи и как создаём архитектуру высоконагруженных систем.
В выпусках обсуждаем:
🔴 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения
🔴 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым
🔴 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит такая модель на практике и как использовать её для эффективной коммуникации с различными командами разработки, вовлечёнными в проект
🔴 Серия 4. Практика. Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной
🔴 Серия 5. Практика. Взаимодействие со смежными системами. Сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать
Наши разработчики создают Диск, Почту, Телемост, Мессенджер, Календарь и другие знакомые вам сервисы. Ими пользуются более 95 миллионов людей ежемесячно, а сервисы держат нагрузки более 1 миллиона RPS, наши базы данных хранят петабайты метаинформации.
📺 Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:
Десятки минут компиляции, вечные проблемы с includes, ещё и ваш namespace постоянно кто-нибудь использует? Всё это — наследие эры заголовочных файлов. Но что, если уже сегодня можно собирать проекты в 2–7 раз быстрее и наконец спрятать всё лишнее от пользователей?
На C++ Zero Cost Conf 2025 Антон Полухин, руководитель группы разработки общих компонент в Техплатформе Городских сервисов Яндекса, рассказал о C++-модулях и способах интегрировать их в уже существующий проект.
Из его доклада вы узнаете три стратегии внедрения модулей от монолитного подхода (как в GCC) до гибких «умных заголовков» (как в Boost). А ещё:
🟢 Как превращение #include <iostream> в import std меняет процесс сборки
🟢 Как ваши namespace impl и detail могут быть по-настоящему приватными
🟢 Как мигрировать на модули постепенно и не ломать обратную совместимость
🟢 Какие подводные камни вас ждут (ADL, макросы, системы сборки) и как их обойти
Если вы работаете с C++ и хотите быть в курсе современных трендов, тратить меньше времени на сборку и больше — на код, то этот доклад будет вам полезен.
Уже скоро мы встретимся офлайн, но если у вас не получится быть в Москве в этот день, не переживайте: всё самое важное будет доступно! Мы подготовили онлайн-студию с контентом, отличающимся от офлайн-формата: bigtechnight.ru/online/?utm_source=tg&utm_medium=u…
🙌 Вас ждут выступления спикеров из компаний-организаторов и лидеров индустрии. Представим разные форматы: дискуссии, интервью, истории разработчиков и интерактив с аудиторией.
Программа включает две студии:
🤯 Hard — обсуждение управления командами, использования ИИ в разработке и реализации крупных проектов.
🤯 Soft — развлекательное шоу с неформальной атмосферой, где разработчики поделятся своими историями, хобби и side-проектами.
Если хотите охватить как можно больше интересных и полезных тем, можно переключаться между студиями.
📆 Онлайн-трансляция пройдёт 12 сентября с 18:00 до 21:00 мск. Напоминаем, что трансляция начнётся в день мероприятия, но рекомендуем заранее отметить дату в календаре!
Бывает, вы начинаете с аккуратной микросервисной архитектуры, но через пару лет оглядываетесь и понимаете, что ваш REST-гейтвей стал монолитом с недельным релизным циклом. Вот и у нас вышло именно так.
👨💻 Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру. В этом посте расскажу, почему в конце 2023 года наша команда решила перестроить архитектуру и внедрить GraphQL-федерацию.
➖ Немного предыстории
В 2015-м autoru-api, гейтвей Авто.ру, был простым REST-шлюзом: авторизация, проксирование запросов в бэкенды, минимум логики. Но за годы в системе появилось 300 000 строк кода, который поддерживали более 40 разработчиков из 8 команд. Микросервисная архитектура потеряла свои плюсы: релизы в прод выходили долго и стали блокировать друг друга.
➖ Почему GraphQL-федерация
Суть подхода — разделить системы на независимые подграфы (по одному на каждый бизнес-домен) и объединить их через Apollo Router на Rust. Ключевые преимущества:
🟢 Изоляция изменений. Правки в одном домене не влияют на другие (и это самое главное!)
🟢 Простота гейтвея. Теперь это один эндпойнт: /graphql для авторизации и маршрутизации
🟢 Гибкость запросов. Router объединяет информацию, а клиенты получают только нужные данные
Конечно, у нас не получился каноничный GraphQL: мы не можем просить конкретные поля прямо из БД. Во-первых, у нас мало где реализована плоская схема хранения, мы часто держим сущность в jsonb-столбце. Во-вторых, такая фича влечёт проблемы с разграничением доступа. Но хорошая новость в том, что мы к этому и не стремились 🙂
➖ Чего мы достигли:
🟢 Значительно снизили time to market
🟢 Существенно повысили уровень изоляции компонентов: заблокировать коллегам релиз теперь очень сложно (но при желании всё ещё возможно 🤪)
🟢 Перестали расширять код гейтвея: в 2024 году он увеличился на 18 тысяч строк против 50 годом ранее
Сейчас перевели около 1% трафика, но планы амбициозные: переход оферов, каталога и поиска.
📟 Эта статья — сокращённый вариант моего доклада на Scala-митапе 2025. Посмотреть выступление целиком можно здесь: vkvideo.ru/video-226874299_456239085
Yandex for Backend
😆 Что скрывается за быстрым поиском в Лавке
Чтобы пользователи оставались довольны, разработчикам часто приходится искать компромисс между качеством и скоростью поисковой системы. Но что, если 50% выручки (GMV) приносят всего несколько сотен запросов — можно ли сделать так, чтобы они выполнялись максимально точно и быстро?
👨💻 Об этом на примере поиска в Яндекс Лавке расскажет Алексей Щекалёв, ML-разработчик, на митапе Яндекс Tech Tour в Казани.
💹 Немного спойлеров о его докладе «LLM Cache в поиске Яндекс Лавки»
Классический пайплайн поиска (кандидаты → фильтрация → ранжирование) хорошо работает, пока ассортимент стабилен. Но в Лавке каждую неделю появляются новые товары: от цветов до корма для животных. Модели просто не знают о новинках, и candidate generation начинает сбоить.
Решение — LLM Cache, но не в привычном смысле генерации текста, а как инструмент предрасчёта релевантных товаров под самые частые запросы.
❇ В чём суть
Мы заранее, в офлайн-режиме, просканировали декартово произведение «запрос × ассортимент» и для каждого подобрали оптимальное число кандидатов. А готовые списки разместили в шардированном кеше.
В рантайме поиск теперь в первую очередь обращается к этому каталогу, что не только снимает нагрузку, но и решает проблему нового ассортимента. Кроме того, мы получаем значительный выигрыш в скорости.
❇ Из доклада вы узнаете:
🟢 Как мы внедрили LLM Cache в наш пайплайн
🟢 Как построить шардированный кеш для миллионов пар «запрос × товар»
🟢 В чём отличие от типичной схемы ANN + rerank
❇ Что ещё будет на Яндекс Tech Tour
Мы покажем внутреннюю кухню инфраструктуры и продуктовой разработки в Яндекс Еде, Маркете и Лавке. Будем много вайбкодить, обсуждать реальные задачи на кейс-лабах и слушать хардовые доклады. А ещё поделимся опытом разработки и работы с фреймворками на C++, Java, Golang.
📆 Когда и где: 15 ноября в Казани
🔶 Регистрируйтесь на Яндекс Tech Tour: dev.go.yandex/events/foodtech-tour?utm_source=tg&u…
🈯 Ждём вас!
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
1 week ago | [YT] | 3
View 0 replies
Yandex for Backend
💹 Как текст в логах замедляет браузер и что можно с этим сделать?
Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера и улучшаю опенсорсные решения, которые там используют.
История началась со стажировки, на которой я взялся сократить полные пути в логах до имени path/to/filename → filename. Казалось бы, простейшая задачка, но она потянула за собой целую цепочку проблем: от увеличения размера DLL до необходимости залезть в исходный код компилятора Clang, чтобы добавить в него новый макрос.
Это рассказ о том, как я решил проблему полных путей в логах, после чего получил офер на позицию мидл-разработчика. И наглядный пример того, как небольшие оптимизации помогают двигать вперёд большие проекты.
❇ Зачем вообще сокращать полные пути до имени файла?
При запуске того же Браузера в ОЗУ загружаются разные файлы, которые необходимы для работы программы. И чем больше размер требуемых файлов, тем дольше будет идти старт приложения. Это особенно больно для пользователей без SSD. Попробуете угадать, какой процент таких среди аудитории Яндекс Браузера? Ответ: 27%.
Размер сборки приложения влияет не только на запуск, но и на объём регулярных обновлений. Следовательно, мы не должны увеличивать ключевые файлы без крайней необходимости.
❇ Использование имени вместо пути только в одном из двух C/C++-макросов (en.cppreference.com/w/cpp/preprocessor/replace.htm…) логирования (LOG и FROM_HERE) вначале показалось идеей без минусов…
Но этот подход дал обратный эффект! DLL увеличилась, потому что при одновременном использовании обоих макросов логирования в одном файле в DLL запишутся две разные строки: имя файла для модифицированного макроса LOG и полный путь для другого макроса FROM_HERE. Получается, что суммарный размер строк стал больше, а не меньше. Выходит, чтобы решить задачу, надо улучшить оба макроса одновременно.
❇ В статье на Хабре я разбираю:
🟢 Небольшое изменение, ускорившее старт Браузера на 2%
🟢 Что такое __builtin_FILE() и чем он отличается от обычного __FILE__
🟢 Как я создал __builtin_FILE_NAME() в Clang, когда понял, что нужного макроса не существует
🟢 Почему уменьшение DLL без негативных эффектов — это успех
🔶 Читайте полную версию статьи на Хабре: habr.com/ru/companies/yandex/articles/952410/
Там я подробно рассказываю, как повлиял на инструмент, которым пользуются разработчики по всему миру.
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
2 weeks ago | [YT] | 4
View 0 replies
Yandex for Backend
🎙 Приходите на Backend Talks
Привет! А у нас новость: команда Яндекс 360 зовёт бэкенд-разработчиков и архитекторов на митап.
🧬 На нём разберём архитектуру облачной записи встреч, наведём порядок в API и покажем, как простые решения спасают сервисы.
🗺 Санкт-Петербург
📆 13 ноября, 19:00–23:00
В программе:
🟢 Илья Григорьев, разработчик бэкенда Телемоста. Покажет на реальном примере, как проектировать большие стейт-машины, и поделится хитростями для многократного ускорения асинхронной обработки медиаданных
🟢 Артемий Коцюбенко, разработчик протокольных сервисов Почты. Объяснит на примере реального сервиса, почему архитектурная простота очень важна и что может пойти не так, если не придерживаться этого принципа
🟢 Никита Ломакин, разработчик в команде Техплатформы. Расскажет, почему важно следить за качеством API, и поделится практиками, которыми пользуются в Яндекс 360 и которые позволят сделать ваш API более качественным и удобным
✨ А после докладов вас будут ждать афтерпати и нетворкинг.
🔶 Регистрируйтесь по ссылке: events.yandex.ru/events/backendtalks_yandex360?utm…
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
2 weeks ago | [YT] | 4
View 1 reply
Yandex for Backend
💹 Видишь сбой? И я не вижу. А он есть
Иногда в системах возникают коварные ситуации: проверки состояния показывают, что всё хорошо, но по факту ничего не работает. Это называется «серый отказ».
На связи Александр Душеин, технический лидер команды архитекторов Yandex Cloud. Давайте разбираться, как возникают серые отказы и как Zonal Shift помогает с ними справиться.
❇ Что-то может пойти не так на уровне сети
Один из вариантов серого отказа — сбой в сетевой связности, когда в одних направлениях она работает, а в других нет. Например, могут сбоить каналы интернет‑провайдеров.
Целевые ресурсы бэкенда в повреждённой зоне доступности могут по‑прежнему отвечать на все проверки Health Check и показывать зелёный статус. При этом они перестают обрабатывать весь трафик или начинают генерировать ошибки.
Эта ситуация может нарушить работу системы, ведь сетевой балансировщик всё ещё будет рассчитывать на бэкенд со сбоями и статусом «Всё ок!».
❇ Иногда что-то ломается на уровне приложения
На уровне L7 ситуация с серыми отказами становится серьёзнее. Частичная деградация связности может привести к дополнительному ухудшению запросов между зонами: трафик из больной зоны начинает переливаться в здоровую. И наоборот.
🧬 Для управления такими ситуациями мы создали Zonal Shift
Это инструмент для управляемого закрытия конкретной зоны доступности на конкретном балансировщике. Он пригодится не только в ситуации частичных отказов, но и при необходимости закрыть балансировку в зоне доступности, чтобы провести учения или регламентные работы.
Zonal Shift поддерживает два режима:
🟢 Полное закрытие всех балансировщиков в зоне доступности
🟢 Закрытие тех, на которые клиент сам повесил признак «Можно потушить»
Для сетевого балансировщика этот признак позволит сразу перераспределить трафик в другие зоны. Функциональность Zonal Shift поддерживается и на уровне L7, так что в более сложной схеме также можно избежать каскадного сбоя из‑за амплификации. Мы можем явно выключать балансировку на бэкенды в зоне доступности, а семантически это работает аналогично сетевой балансировке (NLB).
При этом важно помнить, что Zonal Shift закрывает не зону, а балансировку трафика в неё. Например, если у клиента есть Kubernetes в нескольких зонах доступности, то микросервисы также будут размещены в них и будут общаться между собой горизонтально.
❇ Что важно учесть
Мы изучили графики и журналы по следам инцидентов и заметили, что настройки балансировки часто бывают неоптимальны. Это приводит к сбоям в работе сервисов, поэтому мы сформулировали правила на уровне NLB:
🟢 Делать проверки готовности целевых ресурсов с интервалом не более 3 секунд
🟢 Указывать корректный порог работоспособности и неработоспособности. Значения должны быть строго больше одной проверки
🟢 Следить за тем, чтобы реализация проверок не требовала много ресурсов для генерации ответа. Тогда не будет повышенной нагрузки
🔶 А ещё мы подготовили чек‑лист для работы с ALB-сервисами. Ищите его в статье на Хабре: habr.com/ru/companies/yandex/articles/952350/
В ней же мы рассказываем, какие именно настройки балансировщиков критически важны для защиты от серых отказов, и делимся подробными инструкциями по отказоустойчивости.
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
3 weeks ago | [YT] | 2
View 0 replies
Yandex for Backend
🍁 Приглашаем на осенний Я.Субботник по Go
Это открытое мероприятие Яндекса, на котором разработчики делятся опытом, рассказывают, что прячется под капотом сервисов, и честно отвечают даже на самые каверзные вопросы.
📆 1 ноября в Москве вместе с экспертами обсудим практики разработки и заглянем в закулисье сервисов Яндекса.
В программе:
🟢 Александр Демиденко, старший разработчик бэкенда Yandex Cloud. Выступит с докладом про Userspace Networking на Go
🟢 Игорь Панасюк, Go-разработчик Плюса и Финтеха. Расскажет про новый сборщик мусора в Go 1.25
🟢 Степан Пестерников, CTO Яндекс Игр. Покажет, как в сервисе используют KV-хранилища и кеши
🟢 Александр Никитин, старший разработчик Яндекс Маркета. Расскажет про трассировку логики вычислений с помощью debug tree
✨ А после докладов, конечно же, устроим афтерпати с глинтвейном и уютным нетворкингом.
🔶 Мероприятие пройдёт 1 ноября в Москве и онлайн. Количество офлайн-участников ограничено — рекомендуем регистрироваться заранее: events.yandex.ru/events/ya-subbotnik-go-01-11-2025…
🈯 Go согреемся, обсудим!
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
3 weeks ago | [YT] | 3
View 0 replies
Yandex for Backend
Дев-тулинг: прошлое и будущее
Редакторы кода и инструменты для разработчиков — это целая индустрия. Когда-то переименование переменной казалось подвигом, а сегодня IDE делают десятки сложнейших трансформаций, и при этом программа остаётся корректной.
Это и многое другое Кирилл Мокевнин обсудил в выпуске подкаста «Организованное программирование» с Дмитрием Ивановым, руководителем платформы SourceCraft, Yandex B2B Tech.
А ещё внутри:
🟢 Почему IntelliJ IDEA стала революцией: тайна рефакторинга
🟢 История создания Kotlin: JetBrains против Scala и медленного Java
🟢 Почему редакторы тормозят: что не так с Java и UI
🎧 Смотрите и слушайте выпуск на ресурсах:
🎵 Яндекс Музыка: music.yandex.ru/track/142671063
💬 VK Видео: vkvideo.ru/video-224967259_456239174
📹 Ютуб: https://youtu.be/mIbtxa27K4E?feature=...
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
3 weeks ago | [YT] | 0
View 0 replies
Yandex for Backend
🚀 Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем
За годы работы инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются миллионы людей и тысячи предприятий. Мы знаем, что такое highload и отказоустойчивость не из книжек и докладов, а из реальной многолетней практики.
В этом проекте мы хотим поделиться опытом и рассказать, как решаем наши задачи и как создаём архитектуру высоконагруженных систем.
В выпусках обсуждаем:
🔴 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения
🔴 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым
🔴 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит такая модель на практике и как использовать её для эффективной коммуникации с различными командами разработки, вовлечёнными в проект
🔴 Серия 4. Практика. Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной
🔴 Серия 5. Практика. Взаимодействие со смежными системами. Сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать
Наши разработчики создают Диск, Почту, Телемост, Мессенджер, Календарь и другие знакомые вам сервисы. Ими пользуются более 95 миллионов людей ежемесячно, а сервисы держат нагрузки более 1 миллиона RPS, наши базы данных хранят петабайты метаинформации.
📺 Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:
➕ Наш сайт: 360.yandex.ru/roadtohighload/?utm_source=telegram&…
➕ VK Видео: vkvideo.ru/playlist/-17796776_82
➕ Ютуб: www.youtube.com/playlist?list...
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
4 weeks ago | [YT] | 6
View 0 replies
Yandex for Backend
🧬 Как (и зачем) внедрять в свой проект C++-модули
Десятки минут компиляции, вечные проблемы с includes, ещё и ваш namespace постоянно кто-нибудь использует? Всё это — наследие эры заголовочных файлов. Но что, если уже сегодня можно собирать проекты в 2–7 раз быстрее и наконец спрятать всё лишнее от пользователей?
На C++ Zero Cost Conf 2025 Антон Полухин, руководитель группы разработки общих компонент в Техплатформе Городских сервисов Яндекса, рассказал о C++-модулях и способах интегрировать их в уже существующий проект.
Из его доклада вы узнаете три стратегии внедрения модулей от монолитного подхода (как в GCC) до гибких «умных заголовков» (как в Boost). А ещё:
🟢 Как превращение #include <iostream> в import std меняет процесс сборки
🟢 Как ваши namespace impl и detail могут быть по-настоящему приватными
🟢 Как мигрировать на модули постепенно и не ломать обратную совместимость
🟢 Какие подводные камни вас ждут (ADL, макросы, системы сборки) и как их обойти
🔶 Полное видео выступления Антона смотрите по ссылке: https://www.youtube.com/watch?v=fhKos...
Если вы работаете с C++ и хотите быть в курсе современных трендов, тратить меньше времени на сборку и больше — на код, то этот доклад будет вам полезен.
🔶 А остальные доклады с конференции можно тоже посмотреть в плей-лист: www.youtube.com/playlist?list...
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
1 month ago | [YT] | 1
View 0 replies
Yandex for Backend
😎 big tech night online
Уже скоро мы встретимся офлайн, но если у вас не получится быть в Москве в этот день, не переживайте: всё самое важное будет доступно! Мы подготовили онлайн-студию с контентом, отличающимся от офлайн-формата: bigtechnight.ru/online/?utm_source=tg&utm_medium=u…
🙌 Вас ждут выступления спикеров из компаний-организаторов и лидеров индустрии. Представим разные форматы: дискуссии, интервью, истории разработчиков и интерактив с аудиторией.
Программа включает две студии:
🤯 Hard — обсуждение управления командами, использования ИИ в разработке и реализации крупных проектов.
🤯 Soft — развлекательное шоу с неформальной атмосферой, где разработчики поделятся своими историями, хобби и side-проектами.
Если хотите охватить как можно больше интересных и полезных тем, можно переключаться между студиями.
📆 Онлайн-трансляция пройдёт 12 сентября с 18:00 до 21:00 мск. Напоминаем, что трансляция начнётся в день мероприятия, но рекомендуем заранее отметить дату в календаре!
😌 Зарегистрируйтесь на сайте чтобы получить ссылку на трансляцию: bigtechnight.ru/online/?utm_source=tg&utm_medium=u…
И посмотрите программу онлайн-студии: bigtechnight.ru/online/?utm_source=tg&utm_medium=u…
Подписывайтесь на нас в Telegram: t.me/+aN8Rc-4YJtVlZWZi
1 month ago | [YT] | 1
View 0 replies
Yandex for Backend
🚗 Как в Авто.ру перестроили свой Gateway
Бывает, вы начинаете с аккуратной микросервисной архитектуры, но через пару лет оглядываетесь и понимаете, что ваш REST-гейтвей стал монолитом с недельным релизным циклом. Вот и у нас вышло именно так.
👨💻 Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру. В этом посте расскажу, почему в конце 2023 года наша команда решила перестроить архитектуру и внедрить GraphQL-федерацию.
➖ Немного предыстории
В 2015-м autoru-api, гейтвей Авто.ру, был простым REST-шлюзом: авторизация, проксирование запросов в бэкенды, минимум логики. Но за годы в системе появилось 300 000 строк кода, который поддерживали более 40 разработчиков из 8 команд. Микросервисная архитектура потеряла свои плюсы: релизы в прод выходили долго и стали блокировать друг друга.
➖ Почему GraphQL-федерация
Суть подхода — разделить системы на независимые подграфы (по одному на каждый бизнес-домен) и объединить их через Apollo Router на Rust. Ключевые преимущества:
🟢 Изоляция изменений. Правки в одном домене не влияют на другие (и это самое главное!)
🟢 Простота гейтвея. Теперь это один эндпойнт: /graphql для авторизации и маршрутизации
🟢 Гибкость запросов. Router объединяет информацию, а клиенты получают только нужные данные
Конечно, у нас не получился каноничный GraphQL: мы не можем просить конкретные поля прямо из БД. Во-первых, у нас мало где реализована плоская схема хранения, мы часто держим сущность в jsonb-столбце. Во-вторых, такая фича влечёт проблемы с разграничением доступа. Но хорошая новость в том, что мы к этому и не стремились 🙂
➖ Чего мы достигли:
🟢 Значительно снизили time to market
🟢 Существенно повысили уровень изоляции компонентов: заблокировать коллегам релиз теперь очень сложно (но при желании всё ещё возможно 🤪)
🟢 Перестали расширять код гейтвея: в 2024 году он увеличился на 18 тысяч строк против 50 годом ранее
Сейчас перевели около 1% трафика, но планы амбициозные: переход оферов, каталога и поиска.
🔶 Подробности читайте в статье на Хабре:habr.com/ru/companies/yandex/articles/935948/
Там же схемы архитектуры и 7 поучительных сложностей, которые мы преодолели.
📟 Эта статья — сокращённый вариант моего доклада на Scala-митапе 2025. Посмотреть выступление целиком можно здесь: vkvideo.ru/video-226874299_456239085
Подписывайтесь на нас в Telegram: t.me/yandexforbackend
2 months ago | [YT] | 3
View 0 replies
Load more