Avito Kitchen MVP Architecture

Overview

MVP платформы «Авито.Кухня» — маркетплейс доставки еды. Go-монолит платформы предоставляет три фасада API (публичный для web-клиента, закрытый для заведений, внутренний для провижининга) и фоновый вебхук-диспетчер, который доставляет заведениям события о заказах с гарантией at-least-once. Демо-сервис заведения — отдельный процесс, интегрирующийся с платформой как реальный ресторан.

Components

• browser — web-клиент. В MVP авторизации нет, пользователь идентифицируется заголовком X-User-Id (задел под авторизацию Авито).
• public-api — каталог заведений, меню, корзина, заказы пользователя (/api/v1).
• merchant-api — закрытый API заведений (X-Api-Key): меню, заказы, смена статусов; сюда же смотрит internal-эндпоинт регистрации.
• webhook-dispatcher — воркер: читает транзакционный outbox (webhook_deliveries), шлёт события заведению, ретраи с экспоненциальным backoff.
• postgres — единое хранилище платформы (PG 16).
• merchant-demo — демо-заведение: регистрируется при старте, публикует меню, принимает заказы, симулирует кухню таймерами.

Scenarios

• user-order: [BROWSE] меню -> [CART] checkout -> [WRITE] заказ NEW -> [PICKUP] outbox -> [WEBHOOK] заведению -> [ACCEPT] смена статусов -> [POLL] пользователь видит прогресс.
• merchant-onboarding: [REGISTER] идемпотентная регистрация -> [MENU] публикация seed-меню.
• webhook-failure: [TIMEOUT] две неудачные доставки -> [RETRY] backoff -> [FALLBACK] заведение подхватывает заказ опросом GET /merchant/orders?status=NEW.

Tradeoffs / Failure modes

Доставка событий — at-least-once: возможны дубли, поэтому обработчик заведения идемпотентен по orderId+event. Падение вебхук-канала не теряет заказы: они доступны через polling, статусная машина валидируется на платформе. Диспетчер и API пишут в одну БД — согласованность достигается транзакцией заказа и outbox-записи. При росте нагрузки первыми масштабируются public-api (реплики) и диспетчер (шардирование по merchant_id); меню читается чаще, чем пишется — кандидат на кеш.