Доставка пива, алгоритм «Октагон» и поиск компании в EDGE: какие архитектуры придумали на Avito Grill & Go

Обычно на митапах всё довольно предсказуемо: доклады, слайды, кофе-брейк и немного общения между ними. Но в прошлом году мы решили перевернуть привычный формат — собрать Go-сообщество и побрейнштормить архитектуру. Активность была похожа на System Design, но с фаном и мясом!

Так появился Avito Grill & Go. Формат зашёл настолько, что участники попросили повторить. И мы подумали: а почему бы не привезти его в Петербург?

В этот раз собрали 130 Go-разработчиков во дворике Union Bar и разделили их на команды. Ребята придумывали архитектуру необычных сервисов, рисовали её на ватмане и защищали перед остальными. Мы не пытались провести полноценное архитектурное интервью, а хотели скорее поговорить о технологиях, поштормить интересные решения и хорошо провести время.

Меня зовут Иван Нещадин, я тимлид в команде Arch+Bridge Авито. Расскажу, как прошёл этот эксперимент и какие архитектуры придумали участники — от способов распределить 50 зарядных портов между 3000 людьми до отказоустойчивого пивопровода и платформы для поиска компании.

Что такое Avito Grill & Go?

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

Весь вечер участники занимались Fast Food System Design. Их случайным образом распределили по 15 командам примерно по 10–12 человек. К каждой присоединился ментор из инженерной команды Авито: он давал вводные, помогал запустить обсуждение и следил за временем.

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

Гриль, пиво и тёплый вечер помогали разговориться, но главным поводом для споров всё равно оставались задачи.

PowerBankHub: 3000 человек и 50 зарядных портов

Начнём с кейса, в котором я сам был инженерным ментором. Представьте музыкальный фестиваль на 3000 человек, который идёт больше суток. Зарядная станция всего одна — и в ней 50 портов. Телефоны рано или поздно садятся у всех.

Простая очередь по принципу «кто первый пришёл, тот и заряжается» быстро сломается. Представьте, что будет, если один человек оставит телефон и уйдёт танцевать на два часа. Другой принесёт тройник и займёт порт для пяти друзей. У третьего уже 80%, но он продолжает заряжаться, пока рядом человек с 8% экономит последние проценты, чтобы вызвать такси.

То есть проектировать нужно не столько зарядную станцию, сколько механизм справедливого распределения дефицитного ресурса: кто получает доступ первым, как долго может удерживать слот и как защититься от абьюза.

Команда долго не могла выбрать один механизм и в итоге принесла на защиту сразу пять вариантов.

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

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

• HR Flow в BigTech. Чтобы добраться до розетки, нужно пройти полный найм: CV, HR-скрининг, алгоритмы, Go и System Design. Если в конце порт выбрал тебя — можно заряжаться. Латентность решения предсказуемо высокая, зато фильтрация строгая.

• MAX-планка. Пользователь регистрируется в мессенджере MAX, получает талон и встаёт в планку. Каждые 30 секунд очередь случайно перемешивается; устал стоять в планке — выпал из очереди.

• AppStore-квест. Для доступа нужно скачать приложение, которое уже удалено из стора. Если оно каким-то образом установлено, сервис требует отключить VPN, а без VPN приложение не работает.

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

Моя команда была максимально заряжена. А когда соседний стол начал при каждом упоминании технологии кричать «Kafka!», люди подхватили: рисовали плакаты с названиями технологий и поднимали их вверх. Вовлечённость была на сто процентов. Энергия этого стола отлично показала, как фановые задачи быстро снимают барьеры в общении. Кстати, мой отчёт можно прочитать по ссылке.

Ту же проблему соседняя команда решала уже не с розетками, а с музыкой.

Справедливый DJ: как не отдать вечеринку одному пользователю

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

Если просто воспроизводить заявки по порядку, появляется очевидная проблема: один фанат ретро может поставить двадцать треков из 80-х подряд, а другой человек — закольцевать одну мемную песню. При этом есть ещё и гости, которые музыку вообще не заказывают, но тоже находятся на вечеринке. Их предпочтения система формально не видит. Нужно придумать, как одновременно учитывать все заявки и не давать самым активным пользователям захватить эфир.

Решение: в основе — событийная система, где у каждой вечеринки есть свой id, участники и общая очередь треков. А чтобы было удобно ставить треки участники предложили сделать физический модуль на Arduino, который может управлять колонкой через Bluetooth или голосовое управление.

Очередь в реальном времени. Пользователь подключается к событию, добавляет музыку и голосует за чужие треки, а система в реальном времени пересчитывает их приоритет. Чтобы изменения сразу появлялись у всех участников, используем WebSocket, а саму логику разделяем на несколько сервисов: управление событиями, очередью, голосами и интеграциями с музыкальными платформами. Постоянное состояние храним в PostgreSQL, а данные, к которым обращаемся чаще всего, — актуальную очередь, рейтинг треков и лимиты пользователей держим в Redis.

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

Согласованность и масштабирование. При этом для самой очереди важна строгая согласованность и порядок, а для счётчиков голосов допустима небольшая задержка — так система остаётся отзывчивой даже во время пиков. По мере роста нагрузки сервисы можно масштабировать независимо (основная нагрузка на лайки и соединения для воспроизведения треков повлечёт за собой рост базы и инстансов бэкендов), а фоновые задачи и статистику при необходимости вынести в асинхронную обработку.

Виталий Иванин

Бэкенд-инженер (Е4) в команде SLA

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

Доставка пива с SLA 99,99%

За столом Константина Воливач, бэкенд-инженера (E6), проектировали внутренний сервис доставки пива в офис.

Задача: В офисе есть 50 разработчиков, они работают на пятом этаже, каждому полагается по три кружки пива в день, а основной запас хранится в холодильнике на первом. Лифт постоянно ломается. Среди требований к системе — доступность 99,99% и горизонтальное масштабирование при росте штата.

Решение: Можно было бы проектировать обычный сервис доставки. Но ребята решили воспринимать требования буквально и оптимизировать всю инфраструктуру целиком.

Убираем внешние зависимости. Первой зависимостью оказался холодильник. Решение — перенести офис на север и убрать затраты на охлаждение. Следующая внешняя зависимость — само пиво: поэтому на свободных втором и четвёртом этажах появляются хмелевая ферма и собственная пивоварня.

Доставка, кеш и безопасность. Проблему доставки между этажами команда решила прямыми пивопроводами до рабочих мест, а персональные мини-холодильники у разработчиков превратились в локальный Edge-кеш. Наконец, инфраструктуру нужно защищать — поэтому ребята придумали, что на охрану пива можно поставить медведя. Он не даст ни одной пинте затеряться.

Архитектура. Смешно здесь именно буквальное прочтение архитектурных понятий: внешний поставщик превращается в собственный продакшен, транспортная магистраль — в настоящий трубопровод, Edge cache — в холодильник рядом с пользователем, а security layer — в медведя. Это весьма карикатурная архитектура, но она соответствует всем исходным требованиям. 

У Николая Губина, Senior Backend Engineer в Архитектуре, была другая версия той же задачи.

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

Система ограничений: вечеринка может быть испорчена, если кто-то будет бесконечно употреблять напитки, потому участники команды добавили в систему Белочку, которая следит за лимитами.

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

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

Ребята собрались очень душевной командой из людей с разным опытом и быстро разделили роли: кто-то фиксировал идеи, кто-то готовился к защите, а кто-то шутил странные шутки. При этом все делились опытом и предлагали решения. С самого начала решили делать технически достоверную, по-настоящему рабочую архитектуру, но про шутки тоже не забывали. В итоге получился проект, которым мы остались довольны!

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

Festival Meetup Flow: 50 000 пользователей при EDGE и офлайн-окнах

Если за предыдущими столами участники активно интегрировали в архитектуру фановые механики, то команда Станислава Королёва столкнулась с задачей, где на первый план вышли реальные проблемы Highload и сетевой инфраструктуры. 

Задача: ребята проектировали сервис Festival Meetup Flow — веб-платформу, которая помогает интровертам находить компанию на крупных музыкальных фестивалях.

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

Теперь ограничения. Фестиваль идёт три дня, на площадке 12 сцен и 150 событий. В приложении — до 50 000 активных пользователей, причём до 5000 человек могут одновременно искать компанию непосредственно перед выступлением хедлайнера. Сотовая сеть перегружена: скорость падает до EDGE, а пользователи периодически оказываются офлайн на 10–40 минут.

За 45 минут разобрать хранение профилей, матчинги, геолокацию, синхронизацию и поведение клиента без сети невозможно, поэтому команде пришлось сначала определить границы решения и часть вопросов сознательно вынести в Out of Scope.

Решение: Базовую архитектуру построили вокруг локальных Edge-серверов непосредственно на территории фестиваля — так критичный путь меньше зависит от качества внешней связи. Перед сервисами поставили API Gateway, взаимодействие с основным сервисом спроектировали через REST. Для данных выбрали PostgreSQL с репликацией Master-Slave, для медиаконтента — MinIO; геолокацию и временные матчи связали с веб-хуками и внешними push-уведомлениями.

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

Станислав Королёв

Бэкенд-инженер (E4)

Участники довольно быстро пришли к идее поставить серверы локально на площадке именно из-за проблем со связью. При этом вопросы хранения профилей и полноценной работы в офлайне оказались достаточно большими, чтобы сознательно оставить их за рамками 45-минутной сессии.

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

Из офлайн-настолки в онлайн-сервис

Заключительный кейс, о котором стоит рассказать, родился из бытового наблюдения и увлечения настольными играми. Михаил Рогозин, тоже бэкенд-инженер (Е4), принёс на ивент физическую карточную игру, суть которой в том, чтобы накинуть наиболее подходящий мем на ситуацию, и предложил ребятам решить вполне конкретную продуктовую и техническую проблему.

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

За 45 минут полноценно спроектировать архитектуру сложной онлайн-игры с синхронизацией состояний между участниками практически невозможно. Поэтому команда Михаила сосредоточилась прежде всего на ключевых механиках и основных архитектурных решениях.

Обсуждение началось с хранения данных в S3 и доставки контента через CDN, затем перешло к кешированию и балансировке нагрузки. Итоговую архитектуру, к которой пришла команда, можно посмотреть на схеме ниже.

Что в итоге

Самое крутое в Avito Grill & Go — это даже не придуманные архитектуры и схемы, а то, как быстро незнакомые люди превращаются в команду, начинают спорить, шутить и вместе искать решения.
Ради этого мы и собираем Go-сообщество. Чтобы знакомиться, делиться опытом и иногда позволять себе немного инженерного безумия.
Спасибо всем, кто был с нами в Петербурге! Судя по количеству споров, смеха и просьб повторить, вечер удался. А значит, ещё увидимся!

Например, на Avito Infraween Party Avito Infraween Party 31 октября в Москве? Поделимся инфраструктурными страшилками и болями, а ещё устроим метание списанных железок на дальность.