ADR-0002: Маркетингові дані — окрема схема на shared RDS

Статус: accepted · 2026-06-06 · власник @Vladbandurin

Контекст

ADR-0001 визначив, що abitly-marketing володіє власним сховищем (pattern C: ізольований read-model + marketing-only records). Лишалося обрати рівень ізоляції. RDS studsearch-prod — свідомо спільна інстанція на 3 prod-сервіси (cost-driven) і документований SPoF (databases).

Власник обрав C2 (окрема схема на існуючій RDS), не C1 (окрема інстанція) — консистентно з наявною cost-sharing-філософією.

Рішення

Дані abitly-marketing живуть у новій схемі marketing у тій самій DB abitly_prod_db, поряд з abitly / public / studsearch.

Щоб C2 не посилив SPoF — обов’язкові guardrails:

• Окрема схема, нуль cross-schema DDL. abitly-marketing чіпає лише marketing; з abitly — тільки SELECT для синку read-model, без гарячих cross-schema join у рантаймі.
• Високооб’ємні engagement-події (sent / delivered / opened / clicked / bounced / complained, AI-логи) → analytics lake-house (S3/Iceberg), НЕ в RDS. У marketing-схемі — лише операційний стан: read-model контактів, сегменти, визначення кампаній, згода, suppression, статус відправки, атрибуція.
• Bounded connection pool для marketing — щоб не вичерпати конекшени, спільні для 3 prod-сервісів (db-issues фіксує connection slots як спільний ризик).

Наслідки

• (+) Дешево, без нової інстанції; консистентно з наявною ізоляцією по схемах.
• (−) Blast radius лишається спільним: outage RDS = маркетинг теж лежить (прийнятно — маркетинг не критичний для продуктового uptime).
• (−) Дисципліна обов’язкова: один необережний bulk-insert engagement-подій у RDS замість lake-house зведе ізоляцію нанівець. Тому подієвий потік фізично відведено в lake-house.
• Перегляд: якщо marketing write-load почне впливати на prod → міграція схеми marketing на окрему інстанцію (C1).