Каталог товаров в кабинете продавца
Каталог — основной инструмент продавца для работы с ассортиментом. Товары попадают в него разными путями: через API, из Excel-файла или через карточку товара в кабинете. В каталоге их можно смотреть, фильтровать и выполнять массовые действия, например удалять или архивировать
Добавлять новые фильтры и действия, следить за тем, чтобы выборка по миллионам товаров одного продавца оставалась быстрой, и договариваться о контрактах с фронтендом кабинета
Хранение и поиск более 2 миллиардов товарных предложений
Мы храним оферы в динамических таблицах распределённой платформы данных YT, а полнотекстовый поиск по ним реализуем на отдельном поисковом сервисе. При таких объёмах привычные решения перестают работать, и почти каждая задача превращается в вопрос про схему данных, шардирование и стоимость запроса
Данные в системе не лежат мёртвым грузом: мы принимаем поток обновлений оферов, и здесь счёт идёт уже на сотни тысяч запросов в секунду. То есть у нас две очень разные нагрузки — чтение из кабинета продавца и поток обновлений на запись. Схема хранения должна выдерживать обе нагрузки. Вы будете развивать схему хранения, ускорять чтение и запись, улучшать качество и скорость поиска по ассортименту
Генерация и обработка Excel-файлов с товарами
Для многих продавцов Excel — основной способ работы с ассортиментом: они скачивают шаблон, заполняют его и загружают обратно. В одном файле может быть до миллиона товаров, поэтому задача не сводится к тому, чтобы «прочитать таблицу»: нужно уметь обрабатывать такие объёмы, не съедая всю память, валидировать данные и понятно сообщать продавцу, что именно он заполнил не так
Вы будете развивать генерацию шаблонов и разбор загруженных файлов: добавлять новые колонки и правила валидации, поддерживать подсказки и выпадающие списки прямо в таблице, ускорять обработку больших файлов
Передача данных о товарных предложениях в личный кабинет
Данные об оферах нужны почти на каждой странице кабинета продавца, поэтому наш сервис — один из самых нагруженных в Маркете. Сейчас это от 60 до 500 запросов в секунду, и каждый из них влияет на то, как быстро откроется страница у продавца
Расширять API под новые сценарии кабинета, держать латентность в рамках, разбираться с нагрузкой и кешированием
Переход на общую платформу исполнения запросов и stateless-архитектуру
Мы переводим сервисы на внутреннюю платформу оркестрации запросов. Вместо того чтобы каждый сервис сам ходил по соседям, обход описывается декларативным графом: платформа сама делает сетевые запросы, распараллеливает независимые вызовы, занимается балансировкой и service discovery, даёт единообразные логи, трейсы и мониторинги. Сервисы при этом упрощаются — в них остаётся бизнес-логика, а данные приходят на вход
Параллельно мы выносим состояние в отдельное хранилище с реляционной моделью поверх YT, чтобы все сервисы, кроме самого хранилища, стали stateless. Это большая архитектурная работа на живой системе под нагрузкой, и её нельзя делать с остановкой сервиса — только постепенно и незаметно для продавцов
Больше о бэкенде в Яндексе — в канале Yandex for Backend