Backend Talks

Марс — удивительная планета. Раньше астрономы изучали его, глядя в телескоп с Земли, с расстояния в десятки миллионов километров. А теперь туда отправляются роботы. Но Марс умело хранит свои тайны. Главная из них — есть ли жизнь на Марсе. Там уже найдены русла высохших рек и гигантские «колодцы», ведущие в подземный мир, где могут быть условия для жизни. Когда-нибудь там обязательно побывают люди. А пока поверхность Марса непрерывно наблюдают несколько орбитальных разведчиков, а на самой поверхности уже побывало много роботов, каждый из которых умнее предыдущего. Что же они там нашли?

Сервисы Яндекс 360 используют организации с разным количеством сотрудников: от 3 до 500 тыс. человек. Раньше наша оргструктура жила с лимитом в 10 тыс. участников на группу и архитектурой, в которой время любой операции росло экспоненциально с глубиной вложенности и упиралось в тайм-аут. А потом потребовалось поддержать группы с сотнями тысяч участников разных типов и вложенность в 15 уровней.

В докладе разберём, почему стандартные паттерны хранения иерархий не работают для DAG с множеством родителей, сравним несколько вариантов Closure Table с бенчмарками на реальной нагрузке и расскажем, как Closure Table со счётчиком путей и асинхронным пересчётом транзитивного замыкания позволила снять ограничения на размер групп, ускорить листинг участников и не заставлять пользователя ждать, пока граф пересчитывается.

Яндекс Диск оперирует огромными объёмами данных, где стандартные методы балансировки быстро упираются в архитектурные ограничения.


В этом докладе мы технически обоснуем, почему нам 
не подошёл подход «как у всех», и проследим эволюцию балансировки загрузок: от наивного Round-Robin 
до разработки собственного алгоритма.

Основной фокус сделаем на отказоустойчивости: 
вы узнаете, как математический аппарат рандеву-хеширования помогает элегантно перераспределять нагрузку при внезапном падении или добавлении узлов.

При создании любого IT-продукта важно правильно выбрать технологический стек. Ошибка на старте может обернуться серьёзными проблемами в будущем, особенно в крупных компаниях со множеством команд и продуктов.

В докладе на базе примеров из мира бэкенд-разработки на Java разберём, что важно учитывать при формировании технологического стека, как при этом не погрязнуть в священных войнах, а также обсудим, когда нужен и чем полезен техрадар.

Как разработчику расти не хаотично, а по понятной траектории? Покажем, как эта система помогает junior- и middle-разработчикам двигаться вперёд осознанно, а специалистам senior+ — усиливать экспертизу, приносить больше пользы и расти в профессии без обязательного перехода в лиды.

В докладе расскажем, как мы развиваем команду: используем индивидуальные планы, собираем матрицу компетенций для разных уровней и связываем обучение с реальными задачами.

Отдельно разберём, как встроить курсы и воркшопы в общую систему развития так, чтобы они действительно работали на результат.

Яндекс Мессенджер — не только B2B- и B2C-решение, но и инфраструктурный сервис: его используют ещё и для поддержки и чатов внутри других приложений. Например, в диалогах с продавцом на Маркете или с курьером в Еде.

Команда бэкенда встретилась с серьёзной технической проблемой: все потребители дают большую пишущую нагрузку на базу с метаданными. Когда запаса на вертикальное масштабирование больше нет, деваться некуда: нужно либо менять хранилище для данных, либо шардироваться.

В этом докладе расскажем, какое решение выбрали, как побороли свой страх и начали делать первые шаги в прекрасное будущее.

Марс — удивительная планета. Раньше астрономы изучали его, глядя в телескоп с Земли, с расстояния в десятки миллионов километров. А теперь туда отправляются роботы. Но Марс умело хранит свои тайны. Главная из них — есть ли жизнь на Марсе. Там уже найдены русла высохших рек и гигантские «колодцы», ведущие в подземный мир, где могут быть условия для жизни. Когда-нибудь там обязательно побывают люди. А пока поверхность Марса непрерывно наблюдают несколько орбитальных разведчиков, а на самой поверхности уже побывало много роботов, каждый из которых умнее предыдущего. Что же они там нашли?

Разберём, как спроектировать авторизатор для большой продуктовой экосистемы: начнём с доменной модели —субъекты, ресурсы, роли, разрешения — и разберёмся, как связаны между собой сущности.

Перейдём к архитектуре: какие сервисы нужно интегрировать в первую очередь, как устроить их взаимодействие, где хранить связи пользователей и ресурсов и когда стоит считать права «на лету», а когда  — кешировать.

Затронем практические аспекты работы в проде: масштаб (десятки миллионов пользователей и грантов), B2B-контекст, синхронизацию данных и дополнительные компоненты вроде аутентификации и аудит-логов.

В итоге вы поймёте, как подойти к проектированию авторизатора как базового компонента системы и на что обращать внимание, чтобы он оставался расширяемым и устойчивым к росту.

В формате воркшопа вместе соберём каркас решения и обсудим компромиссы, которые неизбежно возникают при проектировании таких систем.

Когда одной базы уже мало: как шардировать и не пожалеть.

Рано или поздно любая система упирается в пределы одной базы данных: вертикальное масштабирование перестаёт спасать, а нагрузка и объём данных продолжают расти. В этом зале разберёмся, как жить дальше, — через шардирование.

Обсудим базовые и продвинутые подходы: от простого «одна база → несколько» до полноценной шардированной архитектуры.

Поговорим про шардирование по дате, хешу ключа и через отдельный слой маршрутизации. А также —как выбрать ключ шардирования и не получить перекос нагрузки.

Разберём реальные сценарии шардирования с огромным числом ключей и гибридных подходов.

Отдельно обсудим недооценённые сложности: решардирование и его стратегии, перекосы нагрузки и влияние шардирования на архитектуру сервисов.