Каждый сервис владеет своей БД; gateway маршрутизирует запросы, а заказы и остатки согласуются событиями с идемпотентной обработкой и компенсирующими действиями.
Конструирование микросервисной платформы учёта товаров с API‑шлюзом и брокером сообщений
Каждый сервис владеет своей БД; gateway маршрутизирует запросы, а заказы и остатки согласуются событиями с идемпотентной обработкой и компенсирующими действиями.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Создать систему учёта товаров, построенную на микросервисной архитектуре.
- ProductService – сервис для работы с данными о товарах (добавление, удаление, обновление, получение, список).
- InventoryService – сервис для контроля складских остатков (количества товаров, резервирование).
- OrderService – сервис для обработки заказов (создание, отмена, оплата).
Необходимо реализовать API‑gateway, который будет единой точкой входа для всех клиентских запросов и маршрутизировать их к соответствующим микросервисам.
Также следует внедрить механизм обмена сообщениями между сервисами (например, с использованием RabbitMQ или другого брокера сообщений).
Ответ
Каждый сервис владеет своей БД; gateway маршрутизирует запросы, а заказы и остатки согласуются событиями с идемпотентной обработкой и компенсирующими действиями.
ProductService хранит каталог, InventoryService — наличие и резервы, OrderService — состояние заказа. Создание заказа публикует запрос резерва; склад атомарно проверяет доступное количество и отвечает успехом или отказом. Оплата подтверждает заказ, отмена или истечение срока снимают резерв.
События записываются через transactional outbox вместе с изменением БД. Потребители дедуплицируют event_id, используют retry и DLQ. Резерв имеет уникальный order_id и срок жизни. Gateway отвечает за аутентификацию, маршрутизацию и ограничения нагрузки, но не заменяет проверки прав в сервисах. Общая транзакция на три БД не требуется: состояние процесса ведёт saga.