# Побудувала пошту з failover і журналом доставки Побудувала електронну пошту як можливість платформи — три провайдери з резервним перемиканням, webhooks доставки, логування надсилання й доставки, шаблонізацію та кампанії — за перевіркою під час запуску, яка не дасть застосунку стартувати без жодного з них. 2025 **Ситуація.** На електронну пошту на платформі покладено багато: верифікація, сповіщення, дайджести, кампанії — усе те, на що користувач справді чекає. А поштовий провайдер — саме та залежність, яка ламається тихо: конфігурація виглядає нормально, застосунок запускається, і про проблему дізнаються лише тоді, коли жива людина так і не отримує обіцяного листа. Гіршого способу дізнатися про збій не придумаєш. Коли провайдер один, усе ще гірше: збій повний, а виправити його може лише хтось інший. **Завдання.** Пошту треба було сприймати як можливість, що належить самій платформі, а не як клієнтську бібліотеку, яку вона викликає, — таку, що переживе збій провайдера, зможе сказати, що сталося з конкретним листом, і голосно заявить про проблему під час запуску в тих середовищах, де мовчання небезпечне. **Дія.** Три провайдери сховано за одним інтерфейсом — SendGrid як основний, SMTP2GO та Azure Communication Services у резерві за ним, — і перемикання між ними відбувається автоматично, а не через зміну конфігурації, внесену під тиском. Доставку не беруть на віру: вхідні вебхуки повідомляють, що кожен провайдер зробив із листом, і обидві сторони фіксуються — у журналі надсилань і в таблиці подій доставки, — тож відповідь на питання «чи отримала ця людина лист для верифікації» дає запит, а не здогад. Завдяки шаблонам тексти листів живуть поза кодом, а окрема схема broadcast — 5 таблиць і 24 функції — доставляє кампанії сегментам користувачів: це задача, відмінна від транзакційної пошти, тож і будували її як окрему. На вході до всього цього стоїть стартова перевірка, яку вмикає прапорець: вона надсилає справжній лист через увесь стек. У середовищі розробки вона лише записує попередження в журнал і працює далі, бо ніхто не хоче, щоб ноутбук відмовлявся запускатися через прострочений ключ пісочниці, а в staging і production збій фатальний: процес завершується, щоб не розгорнути збірку, яка не здатна надсилати пошту. Сам шлях надсилання проходить через клієнт із захистом від SSRF і тайм‑аутом 30 секунд, а асинхронний шлях доставки має повторні спроби з backoff, тож через короткочасний збій повідомлення не губиться. **Результат.** Цілий клас тихих збоїв перейшов із розряду «користувач помітить через кілька днів» у розряд «розгортання зупиняється», а невдалий день у провайдера тепер означає роботу в деградованому режимі, а не аварію. Ціна — три інтеграції замість однієї, які треба підтримувати в робочому стані, і журнали доставки, що ростуть і потребують чищення, — на обидві поступки пішли свідомо, бо пошта — це канал, який платформа не може обійти. --- - Роль: Backend‑інженер - Категорії: [Backend‑розробка](https://engineer.company/uk/categories/backend/), [API та інтеграції](https://engineer.company/uk/categories/api/), [Хмарні технології](https://engineer.company/uk/categories/cloud/), [Надійність і резервне копіювання](https://engineer.company/uk/categories/reliability/), [Безпека](https://engineer.company/uk/categories/security/) - Послуги: [Backend- та API‑розробка](https://engineer.company/uk/services/backend-development/), [Надійність та моніторинг (SRE)](https://engineer.company/uk/services/site-reliability/), [Безпека та керування доступом](https://engineer.company/uk/services/security-access/)