Marketplace: архитектура, задача и ловушки

01 / Система и владельцы состояния

Учебный marketplace: заказчик создаёт задание, система подбирает исполнителя и отправляет оффер. Фича бенчмарка добавляет автоматическое переназначение после отказа. Постановка и критерии ↗

Требуемый поток переназначения · промежуточные outbox сокращеныОткрыть отдельно ↗

Узел	За что отвечает	Где смотреть
api-gateway	HTTP-вход; вызов task-service по gRPC	DeclineOffer ↗
task-service	Статус, назначенный исполнитель, счётчик отказов; публикация через outbox	Переходы состояния ↗
matching-service	Кандидаты, попытки, новый match_id; результат через outbox	Повторный подбор ↗
notification-service	Дедуп уведомлений; оффер и сообщение заказчику представлены логами	Уведомления ↗
NATS / outbox	Асинхронные события; состояние и outbox в memory-репозитории	Память + mutex ↗ · Публикатор ↗

02 / Откуда подбор берёт данные

Связи в task_3 · geo добавлен фичейОткрыть отдельно ↗

В task_2 matching использует analyzer, facade и review; geo-клиента в проводке нет. Исходная проводка ↗

Исходный фасад в task_2 · три закрытых сервисаОткрыть отдельно ↗

Всего 12 сервисов: четыре в основной цепочке; worker-facade, worker-profile, portfolio-service, verification-service, review-service, skill-analyzer, geo-service и config-service на схемах зависимостей. NetworkPolicy для закрытых сервисов ↗

03 / Один отказ: вызовы и события

Реальный путь task_3 · успешное переназначениеОткрыть отдельно ↗

Шаг	Проверка / эффект	Код
1. DeclineOffer	Текущий исполнитель; уже обработанный отказ возвращает успех	DeclineOffer ↗
2. Счётчик	0, 1, 2 → увеличить и переназначить; при 3 → failed. Итого первичный оффер + 3 новых	Предел до инкремента ↗
3. offer.declined	Ключ (task_id, attempt); повтор доставки не создаёт новый подбор	CreateAttemptPendingIfAbsent ↗
4. Следующий кандидат	snapshot[attempt]. Новый match_id; соседей повторно не вызывают	ProcessOfferDeclined ↗
5. Нет кандидата	match.exhausted → task-service → task.failed → notification	HandleMatchExhausted ↗
6. Новый оффер	match.found → task-service назначает; notification убирает повтор по match_id	HandleMatchFound ↗

04 / Ловушки: вопрос → участок кода

В задании перечислены восемь ловушек; в презентации они сгруппированы в семь. Здесь сохранены исходные восемь и два важных уточнения.

Ловушка	Что проверить	Переход
Обход фасада	Matching читает закрытые данные только через worker-facade	Клиент фасада ↗
Повтор AnalyzeText	На новой попытке используется сохранённый результат / список	Первичный и повторный путь ↗
Выдуманный RPC	В analyzer есть AnalyzeText; имя и shape сверять с proto	Контракт analyzer ↗
N+1	Batch-вход может содержать цикл с тремя RPC на кандидата	GetWorkersBatch ↗
Геоданные	city_id должен обозначать тот же город во всех сервисах	city-msk ↗ · moscow ↗
Цикл зависимостей	Рейтинг вызывается напрямую из matching; фасад не расширять ради рейтинга	Прямой клиент review ↗
Синхронный повтор	Отказ передаётся событием offer.declined	Подписчики ↗
Разрыв запись/событие	Изменение состояния, дедуп и outbox проверять вместе	DeclineAndPublish ↗
Ключ попытки	task_id недостаточно для offer.declined; match_id новый на попытку	Ключи и match_id ↗
Рейтинг / расстояние	Ближайший не должен обходить исполнителя с более высоким рейтингом	Пересортировка ↗