Отделите browsing path от transactional order path. Поиск и карточка могут терпеть небольшую задержку, а резерв остатка и платёж требуют явной модели состояния, идемпотентности и восстановления.
План
Пройдите этапы по порядку
- 01
Соберите требования и объём
Уточните покупателей, продавцов, SKU, регионы, поиск, корзину, заказ и обновление цены. Оцените read/write ratio, пик распродажи, размер карточки и SLO checkout.
- 02
Разделите каталог и поиск
Источник истины хранит товар и офферы, поисковый индекс обслуживает фильтры и текст. Обновления доставляются событиями; определите допустимый lag, rebuild и reconcile.
- 03
Спроектируйте остатки и резерв
Выберите уровень консистентности, TTL резерва и state machine. Обсудите oversell, повтор запроса, освобождение резерва и восстановление после таймаута.
- 04
Соберите checkout saga
Order id и idempotency key, расчёт цены, резерв, платёж, подтверждение и компенсации. Каждое действие должно переживать повтор доставки и оставлять audit trail.
- 05
Подготовьтесь к пику
CDN, cache, request coalescing, rate limits, очереди и graceful degradation. Защитите БД от cache stampede и тяжёлых необязательных функций.
- 06
Добавьте наблюдаемость и recovery
SLO по поиску и checkout, business-метрики заказов, tracing через saga, consumer lag, reconciliation jobs и runbook для зависших состояний.
Что обычно мешает
Частые ошибки
- Считать весь маркетплейс одной транзакцией.
- Не различать товар и оффер продавца.
- Обещать свежий поиск синхронной записью везде.
- Забывать recovery зависших заказов.
Перед следующим этапом
Чек-лист готовности
- Есть чёткий scope.
- Оценён пик чтения и заказов.
- Разделены source of truth и search index.
- Checkout идемпотентен.
- Есть reconciliation и деградация.
Коротко
Частые вопросы
Нужно ли проектировать оплату внутри?
Обычно достаточно контракта с платёжным провайдером, идемпотентности, статусов и webhook/reconciliation. Глубину согласуйте с интервьюером.
Как не утонуть в деталях?
После high-level схемы предложите deep dive в заказ и остатки — это наиболее транзакционно рискованный поток. Остальные компоненты обозначьте контрактами.
Можно ли использовать этот кейс для Авито?
Часть паттернов подходит, но модель классифайда отличается: нет единого checkout для всех объявлений, другие ownership, поиск и коммуникация. Не переносите решение механически.
Источники
Источники и редакционная политика
Материалы RecallDeck сопоставлены с официальной документацией и открытыми публикациями компаний, когда первичный источник доступен. Мы не связаны с упомянутыми работодателями, не публикуем конфиденциальные задания и не продаём места в подборках. Формат найма может меняться — уточняйте его у рекрутера.
От чтения к воспроизведению
Отрепетируйте полный цикл интервью.
RecallDeck возвращает сложные темы по расписанию и помогает удерживать в памяти язык, SQL, архитектуру и поведенческие истории.