ADR-0009: Multi-tenant credentials поставщиков
Status: accepted Date: 2026-04-17 Deciders: команда проекта
Контекст
API поставщиков (начиная с ETM) выдают данные, зависящие от учётной записи: индивидуальные прайсы по договору, доступность складов, специальные условия.
Модель с одной системной учёткой на поставщика приводит к ряду ограничений:
- Лишает клиентов их индивидуальных условий (мы видим только “общую” проекцию).
- Ограничивает rate budget одной учёткой.
- Не позволяет клиенту “отвязать” свои данные от нас (отозвать своё, не нарушая работы остальных).
Альтернативы:
- A: Одна системная credential.
- B: Только клиентские credentials, без системной.
- C: Системная + клиентские, явная модель в домене.
Решение
Variant C: первоклассная сущность SupplierCredential со scope system | customer и привязкой к Customer для customer-scope.
Расщепление SupplierOffer на:
SupplierOffer— товарная канва (характеристики, mpn, lifecycle, media), нейтральная к credential;SupplierOfferObservation— наблюдения (цены, остатки, условия), привязанные к конкретной credential.
Pricing engine выбирает observation по приоритету: own customer credential → системная credential → fallback (pricing_mode=unknown).
Rate budget — per-credential. Catalog discovery может round-robin’ить по credentials с явным allowed_use=shared_for_catalog.
Хранение секретов и схема авторизации определяются отдельным решением по credentials storage и encryption.
Последствия
Плюсы
- Клиенты получают свои реальные цены и условия.
- Множитель rate budget пропорционален числу клиентских credentials с разрешением на shared use.
- Возможность отозвать клиентские credentials без влияния на остальных.
- Естественный аудит “от чьего имени мы делали запрос”.
- Privacy: данные клиента A не утекают клиенту B.
Минусы
- Серьёзное усложнение модели данных и pricing engine.
- Дополнительный слой безопасности (Vault, аудит, ротация).
- Управление credentials — новая операционная задача (UI, runbook, поддержка).
- Сложнее отлаживать pricing — нужно видеть, какая credential выбрана.
Нейтральные последствия
- ETM уже отлично подходит под эту модель (login per договор).
- Часть клиентов может не давать credentials — для них работает системная credential.
Рассмотренные альтернативы
A: Одна системная credential
Не покрывает индивидуальные условия. Потенциальные риски: клиент видит цены, не соответствующие его договору; мы упираемся в rate limit одного аккаунта.
B: Только клиентские credentials
Невозможно работать с анонимными / B2C пользователями. Невозможно делать предварительные интеграции до получения первого клиента.