Backend-разработчики Яндекса решат вашу архитектурную задачу. Если она будет сложной.
Поставить задачу
Это не очередной хакатон или контест.
Мы предлагаем вам придумать и отправить нам сложную архитектурную задачу, которую в прямом эфире вместе с вами обсудят и решат ведущие backend-разработчики Яндекса.

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

А еще просто потому что это круто и иногда полезно — знакомиться, вместе размышлять и решать архитектурные задачки.

Какой порядок действий?
  1. Внимательно ознакомьтесь с требованиями и примером задачи, которая им соответствует.
  2. Придумайте свою задачу.
  3. Зарегистрируйтесь сразу, а поставить задачу можно в течение 14 дней с момента регистрации.
Шаг 1
  1. Ожидайте — наши разработчики отсмотрят все задачи и выберут 3 самых нетривиальных для решения в прямом эфире.
  2. Мы заранее свяжемся с авторами этих задач и пригласим присоединиться к прямой трансляции очно в Москве или онлайн.
Шаг 2
В июне ведущие backend-разработчики Яндекса решат задачи в прямом эфире вместе с вами. Coming soon: дата прямой трансляции.
Шаг 3
Не беспокойтесь! В эфире разработчик увидит задачу впервые. Отбор проводят другие специалисты.

Спроектируйте бэкенд для облачного конструктора сервисов, позволяющего пользователям описывать желаемый сервис/бот/микросервис на естественном языке (например: «Сделай сервис, который принимает PDF, извлекает из него таблицы и сохраняет их в Google Sheets»), а LLM автоматически генерирует рабочий прототип backend-сервиса, который можно тут же развернуть, интегрировать с внешними API и управлять из пользовательского интерфейса.

Пользователь может:

Создать новый сервис текстовым запросом (prompt → LLM генерирует код + метаданные, схемы API, инструкции по деплою)
Уточнять или править свой сервис в виде диалога
Связывать получившийся сервис с внешними системами (webhook, OAuth-интеграции, custom plugins)
Разворачивать сервис в sandbox и прод-режимах
Мониторить статус, получать логи ошибок
Делать свой сервис приватным или публичным для других пользователей платформы

Технические требования

Входные и выходные данные, протоколы взаимодействия

1.

REST API + WebSocket/Server-Sent Events для асинхронных операций, OAuth2 или SSO для пользователей

2.

Взаимодействие с LLM:
POST /services/generate — принимает текстовое описание сервиса, возвращает task_id
GET /services/generate/{task_id}/status — лонгполлинг или WebSocket: «в процессе»/“готов“/“с ошибкой», результат — описание сгенерированного сервиса (OpenAPI spec, готовый dockerfile, скрипты интеграций, исходный код и т. д.)

3.

Деплой и sandbox:
POST /services/{service_id}/deploy — развернуть сгенерированный сервис
GET /services/{service_id}/status — статус инстанса.)
GET /services/{service_id}/logs — логи работы сервиса

4.

Интеграции:
POST /services/{service_id}/integrations — подключение сторонних сервисов по OAuth/webhook/plugin
POST /services/{service_id}/webhooks — создание входящих/исходящих хендлеров

5.

Публичный доступ:
GET /public/{service_id}/openapi.json — публичная/openapi спецификация для вызова
CRUD для управления своими сервисами, правами доступа, версиями

Ожидаемый профиль нагрузки

MAU: 100 000 пользователей
Сервисов на платформе (созданных юзерами): 1 000 000
RPS вызовов пользовательских сервисов (все вместе): 5 000
RPS на генерацию/модификацию сервисов через LLM: 50-100
Пик одновременных деплоев/перегенераций: 1 000
Объём логов/телеметрии: 500 GB/сутки
События вебхуков/интеграций: 100 000/сутки

SLA

Время холодного старта сервиса в sandbox: ≤ 10 сек.
Время генерации прототипа LLM (P99): ≤ 120 сек.
API управления платформой (P95): ≤ 200 мс.
Доступность работающего endpoint созданного сервиса (prod): ≥99.9%
Логирование ошибок и оповещение пользователя о сбоях: ≤30 сек.
Откат к предыдущей версии сервиса: ≤ 60 сек
Требования к задаче

Поставьте нам сложную архитектурную задачу на проектирование backend (а) сервиса, решающую некоторую пользовательскую или инфраструктурную задачу.

Общие требования к задаче:

  1. Задача должна быть решаемой в принципе
  2. Задача должна быть приближенной к реальному миру
  3. Приблизительный объем задачи по времени решения — 1 час

Обязательно напишите:
  1. Что на входе и выходе у сервиса. Форматы и протокол взаимодействия с внешними системами.
  2. Ожидаемый профиль нагрузки. (RPS, GB/sec и т. п.)
  3. SLA — ожидания по скорости ответа, обработки данных

Опционально можно добавить: Ограничения по ресурсам (CPU, RAM, HDD, SSD), требования по эксплуатации/отказоустойчивости и другие условия.

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

Backend в сервисах Яндекса

Поиск

Поиск — это то, с чего начался Яндекс. Он стал первым наукоёмким сервисом Яндекса и подстегнул развитие во всех технологических стеках. Сегодня через Поиск Яндекса проходит 66% интернет-трафика в России. Storage Поиска в erasure-кодировании обрабатывает 40 млн. запросов или 80M чтений в секунду с NVMe — это несколько петабайт данных.

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

Карты

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

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

Рекламные Технологии

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

В команде бэкенда мы создаем продуктовые фичи для рекламных продуктов, проектируем API, схемы данных и data flow. Каждый день мы решаем технически сложные задачи и работаем с колоссальной инфраструктурой: сотни тысяч CPU и нагрузка в миллион RPS — это технологически круто и масштабно.

Автономный транспорт

Мы разрабатываем беспилотные автомобили и роботов-доставщиков: от софта до железа, чтобы сделать поездки безопаснее, а доставку товаров — намного быстрее

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

FAQ

По каким критериям будут выбирать 3 задачи для прямого эфира?

Как и когда будет проходить прямой эфир?

Чтобы зарегистрироваться нужно сразу поставить задачу?

Отбирать задачи к эфиру и решать их будут одни и те же разработчики?

Нужно ли предлагать решение задачи?

За кем остаются интеллектуальные права на задачу?

Кому я могу задать вопросы?

2025, ООО Яндекс
Thu May 22 2025 15:03:57 GMT+0300 (Moscow Standard Time)