Jak obroniliśmy klientów: historia jednego przejścia między agregatorami mailingowymi

Kontekst: serwis wysyłkowy i jego ewolucja

Tworzyliśmy serwis wysyłkowy dla dużego projektu — centralny punkt wysyłki wiadomości e-mail i SMS dla wszystkich usług wewnętrznych. Samą architekturę szczegółowo opisaliśmy w artykule o serwisie wysyłkowym opartym na Laravelu.

Ta historia ma jednak osobny wątek — kolejne migracje między dostawcami usług wysyłkowych. Warto opowiedzieć o nim oddzielnie.

Etap 1: Mailchimp

Początkowo do wysyłania wiadomości e-mail używaliśmy Mailchimpa. Było to wygodne i niezawodne rozwiązanie:

• Przejrzyste API.
• Webhooki do otrzymywania statusów doręczenia.
• Obsługa szablonów.
• Czytelna analityka.

Wszystko działało. Zmieniła się jednak sytuacja geopolityczna: spodziewano się zablokowania Mailchimpa dla użytkowników z Rosji. Musieliśmy pilnie znaleźć alternatywę.

Etap 2: DashaMail

Zintegrowaliśmy DashaMail — rosyjskiego dostawcę usług wysyłkowych, który spełniał nowe wymagania.

Co ważne, DashaMail zapewniał wszystkie kluczowe funkcje:

• API umożliwiające integrację.
• Webhooki do otrzymywania statusów wysyłki.
• Obsługę szablonów z możliwością przekazywania dodatkowych parametrów.

Serwis wysyłkowy nadal działał bez utraty funkcjonalności. Klienci otrzymywali wiadomości, zespół wsparcia miał dostęp do statusów, a szablony działały prawidłowo.

Równolegle inny zespół w firmie rozpoczął jednak prace nad własnym, wewnętrznym systemem wysyłkowym.

Etap 3: Zadanie od biznesu — migracja na wewnętrzny system wysyłkowy

Gdy wewnętrzny system był gotowy, biznes zlecił nam przeniesienie serwisu wysyłkowego z DashaMail na własne rozwiązanie.

Uzasadnienie biznesowe było zrozumiałe: własny system oznacza oszczędności na abonamentach zewnętrznych dostawców. Przystąpiliśmy więc do analizy zadania.

Analiza: co ustaliliśmy

Dokładnie zbadaliśmy wewnętrzny system wysyłkowy i porównaliśmy go z obecnym rozwiązaniem. Wyniki okazały się niepokojące.

Problem 1: Brak API

Wewnętrzny system obsługiwał wyłącznie protokół SMTP i nie udostępniał API.

Co oznaczało to w praktyce?

• Musielibyśmy ograniczyć część funkcji serwisu wysyłkowego: możliwość wskazywania różnych nadawców, różnych adresów do odpowiedzi, priorytetów wiadomości oraz odbiorców kopii.
• Nie moglibyśmy elastycznie zarządzać wysyłką za pomocą API.
• Stracilibyśmy możliwość precyzyjnego dostosowywania ustawień do różnych typów wiadomości.

Problem 2: Brak webhooków, a co za tym idzie — statusów

Wewnętrzny system nie przekazywał statusów wysyłki przez webhooki.

Oznaczało to, że:

• Zespół wsparcia nie mógłby ustalić, czy wiadomość została wysłana.
• Gdyby klient zgłosił, że nie otrzymał wiadomości, nie moglibyśmy tego zweryfikować.
• Zniknęłaby przejrzystość procesu wysyłki, którą wcześniej zbudowaliśmy w naszym serwisie.

Problem 3: Brak obsługi szablonów z dodatkowymi parametrami

Serwis wysyłkowy korzystał z szablonów, do których przekazywaliśmy dodatkowe parametry w nagłówkach wiadomości. Pozwalało to personalizować wiadomości i dodawać dane techniczne.

Wewnętrzny system nie obsługiwał takiego sposobu przekazywania parametrów. Musielibyśmy przebudować szablony, tracąc przy tym część funkcjonalności.

Problem 4: Niewystarczająca wydajność pod obciążeniem

To był najpoważniejszy problem. Odtworzyliśmy bieżący wolumen wysyłek i spróbowaliśmy obsłużyć go za pomocą wewnętrznego systemu w środowisku testowym.

Wynik: system nie radził sobie z obciążeniem.

Nie była to teoretyczna obawa, lecz potwierdzony fakt. Gdybyśmy przenieśli wysyłkę wiadomości do klientów na wewnętrzny system, ucierpieliby klienci firmy:

• Wiadomości byłyby dostarczane z opóźnieniem.
• Część wiadomości mogłaby w ogóle nie dotrzeć.
• Zespół wsparcia nie byłby w stanie skutecznie wyjaśniać incydentów.

Nasze rozwiązanie: raport i kompromis

Nie powiedzieliśmy po prostu „nie”. Przygotowaliśmy szczegółowy raport i przekazaliśmy go stronie biznesowej. Raport zawierał:

• Porównanie funkcjonalności DashaMail i wewnętrznego systemu wysyłkowego.
• Wyniki testu obciążeniowego.
• Opis ryzyka dla klientów.
• Propozycję rozwiązania kompromisowego.

Propozycja

Zaproponowaliśmy, aby nie przenosić wszystkich wysyłek na wewnętrzny system, lecz wykorzystywać go wyłącznie do określonych zadań:

• Wiadomości infrastrukturalne — na przykład e-maile do programistów, powiadomienia techniczne i alerty wewnętrzne.
• Wiadomości do klientów — pozostawić w DashaMail lub w przyszłości przenieść do innego zewnętrznego dostawcy, który radzi sobie z obciążeniem i udostępnia statusy wysyłki.

Pozwalało to:

• Obniżyć koszty — część ruchu trafiała do wewnętrznego systemu. Podczas ataków DDoS i okresów dużego obciążenia mogło to oznaczać znaczną liczbę wiadomości.
• Nie narażać klientów na problemy — krytyczne wiadomości były wysyłane przez sprawdzonego dostawcę.
• Zachować funkcjonalność — statusy, szablony i webhooki.

Rezultat: serwis wysyłkowy obsługujący wielu dostawców

Po analizie i rozmowach z biznesem serwis wysyłkowy przeszedł na model obsługujący wielu dostawców.

Jak działa to teraz?

• Serwis obsługuje kilku dostawców jednocześnie.
• Dla każdego typu wysyłki można wybrać odpowiedniego dostawcę wysyłającego wiadomości przez API.
• Dla każdego szablonu można skonfigurować osobny kanał wysyłki.

Dało nam to elastyczność, której nie moglibyśmy uzyskać przy ścisłym uzależnieniu od jednego dostawcy.

Czego nauczyła nas ta historia

1. Analiza przed wdrożeniem jest niezbędna

Gdybyśmy po prostu wykonali polecenie biznesu i przenieśli wszystko na wewnętrzny system wysyłkowy, skutkiem byliby:

• Niezadowoleni klienci.
• Przeciążony zespół wsparcia.
• Utrata zaufania do serwisu.

Analiza i testy obciążeniowe zapobiegły katastrofie.

2. „Nie” nie jest odpowiedzią. Odpowiedzią jest kompromis

Nie odrzuciliśmy zadania. Zaproponowaliśmy rozwiązanie, które odpowiadało zarówno potrzebom biznesu, jak i klientów: częściowe oszczędności bez ryzyka pogorszenia jakości.

3. Wewnętrzne rozwiązanie nie zawsze jest gotowe do pracy w środowisku produkcyjnym

Własny system wysyłkowy to dobry kierunek. Jeśli jednak nie radzi sobie z obciążeniem i nie zapewnia wymaganych funkcji, nie można powierzać mu krytycznych wysyłek.

Nie oznacza to, że rozwiązanie jest „złe” — po prostu nie jest jeszcze gotowe do tego konkretnego zastosowania.

4. Wielu dostawców to większa elastyczność

Uzależnienie od jednego dostawcy jest ryzykowne. Jeśli jego usługa przestaje działać lub zmieniają się warunki współpracy, cierpi na tym biznes. Korzystanie z kilku dostawców zapewnia redundancję i elastyczność.

Podsumowanie

Ta historia pokazuje, że decyzji technicznych nie można podejmować wyłącznie na podstawie oszczędności. Czasami oszczędności na dostawcy usług wysyłkowych przekładają się na straty wynikające z problemów klientów.

Zaproponowaliśmy kompromis, chroniąc interesy klientów firmy. W efekcie uzyskaliśmy serwis, który stał się bardziej elastyczny i niezawodny niż przed realizacją tego zadania.