Побудувала пошту з failover і журналом доставки

Ситуація. На електронну пошту на платформі покладено багато: верифікація, сповіщення, дайджести, кампанії — усе те, на що користувач справді чекає. А поштовий провайдер — саме та залежність, яка ламається тихо: конфігурація виглядає нормально, застосунок запускається, і про проблему дізнаються лише тоді, коли жива людина так і не отримує обіцяного листа. Гіршого способу дізнатися про збій не придумаєш. Коли провайдер один, усе ще гірше: збій повний, а виправити його може лише хтось інший.

Завдання. Пошту треба було сприймати як можливість, що належить самій платформі, а не як клієнтську бібліотеку, яку вона викликає, — таку, що переживе збій провайдера, зможе сказати, що сталося з конкретним листом, і голосно заявить про проблему під час запуску в тих середовищах, де мовчання небезпечне.

Дія. Три провайдери сховано за одним інтерфейсом — SendGrid як основний, SMTP2GO та Azure Communication Services у резерві за ним, — і перемикання між ними відбувається автоматично, а не через зміну конфігурації, внесену під тиском. Доставку не беруть на віру: вхідні вебхуки повідомляють, що кожен провайдер зробив із листом, і обидві сторони фіксуються — у журналі надсилань і в таблиці подій доставки, — тож відповідь на питання «чи отримала ця людина лист для верифікації» дає запит, а не здогад. Завдяки шаблонам тексти листів живуть поза кодом, а окрема схема broadcast — 5 таблиць і 24 функції — доставляє кампанії сегментам користувачів: це задача, відмінна від транзакційної пошти, тож і будували її як окрему. На вході до всього цього стоїть стартова перевірка, яку вмикає прапорець: вона надсилає справжній лист через увесь стек. У середовищі розробки вона лише записує попередження в журнал і працює далі, бо ніхто не хоче, щоб ноутбук відмовлявся запускатися через прострочений ключ пісочниці, а в staging і production збій фатальний: процес завершується, щоб не розгорнути збірку, яка не здатна надсилати пошту. Сам шлях надсилання проходить через клієнт із захистом від SSRF і тайм‑аутом 30 секунд, а асинхронний шлях доставки має повторні спроби з backoff, тож через короткочасний збій повідомлення не губиться.

Результат. Цілий клас тихих збоїв перейшов із розряду «користувач помітить через кілька днів» у розряд «розгортання зупиняється», а невдалий день у провайдера тепер означає роботу в деградованому режимі, а не аварію. Ціна — три інтеграції замість однієї, які треба підтримувати в робочому стані, і журнали доставки, що ростуть і потребують чищення, — на обидві поступки пішли свідомо, бо пошта — це канал, який платформа не може обійти.