Cum am construit un sistem de notificări multi-canal pentru o platformă cu 50.000 utilizatori

Studiu de caz tehnic-narativ: email, SMS, push notifications, scalabilitate, retry, preferințe utilizatori și monitorizare.

Un sistem de notificări pare simplu la prima vedere. Trimiți un email, trimiți un SMS, trimiți o notificare push și utilizatorul primește mesajul. În realitate, într-o platformă cu zeci de mii de utilizatori, notificările devin rapid una dintre cele mai sensibile componente ale aplicației.

Dacă notificarea nu ajunge, utilizatorul poate rata o programare, o plată, o comandă, o alertă de securitate sau o acțiune importantă. Dacă notificarea ajunge prea târziu, valoarea ei scade. Dacă ajunge de două ori, utilizatorul își pierde încrederea. Dacă se trimit prea multe mesaje, platforma devine deranjantă. Dacă nu există loguri, echipa de suport nu poate răspunde la întrebarea simplă: „De ce nu am primit notificarea?”

Acest studiu de caz prezintă modul în care am proiectat și implementat un sistem de notificări multi-canal pentru o platformă cu peste 50.000 de utilizatori. Numele clientului și anumite detalii operaționale au fost anonimizate, însă problemele, arhitectura și soluțiile reflectă provocări reale întâlnite în aplicații business care au nevoie de comunicare rapidă, scalabilă și controlată.

Sistemul trebuia să trimită notificări prin trei canale principale: email, SMS și push notifications. În plus, trebuia să respecte preferințele utilizatorilor, să suporte volume mari, să gestioneze erori, să prevină dublurile și să ofere echipei interne vizibilitate completă asupra mesajelor trimise.

Contextul proiectului

Clientul opera o platformă digitală cu utilizatori activi zilnic. Platforma includea conturi de utilizator, acțiuni tranzacționale, documente, statusuri, evenimente importante și interacțiuni frecvente între utilizatori și sistem.

Înainte de proiect, notificările erau implementate direct în mai multe zone ale aplicației. Când se întâmpla un eveniment, codul trimitea emailul sau SMS-ul direct din fluxul respectiv. La început, această abordare a funcționat acceptabil. Pe măsură ce platforma a crescut, problemele au devenit tot mai vizibile.

Unele notificări întârziau. Altele se trimiteau de două ori. Uneori, dacă furnizorul de SMS nu răspundea, procesul principal era încetinit. Echipa de suport nu putea verifica ușor dacă un mesaj fusese trimis, livrat sau respins. Template-urile erau greu de actualizat. Preferințele utilizatorilor nu erau gestionate unitar. Iar adăugarea unui canal nou presupunea modificări în multe zone ale aplicației.

Clientul nu avea nevoie doar de „trimitere email și SMS”. Avea nevoie de o infrastructură de comunicare.

Problema inițială

Problema principală era lipsa unei arhitecturi dedicate pentru notificări.

Aplicația principală făcea prea multe lucruri simultan: procesa acțiuni de business, salva date, trimitea mesaje, trata erori de comunicare cu furnizori externi și încerca să păstreze istoricul notificărilor.

Această abordare avea mai multe riscuri.

În primul rând, performanța era afectată. Dacă trimiterea unui SMS dura mai mult, utilizatorul putea simți întârziere în aplicație.

În al doilea rând, fiabilitatea era redusă. Dacă un furnizor extern era temporar indisponibil, notificarea putea eșua fără mecanism clar de retry.

În al treilea rând, observabilitatea era slabă. Nu exista un panou clar în care echipa să vadă ce notificări au fost programate, trimise, livrate, eșuate sau retrimise.

În al patrulea rând, mentenanța devenea dificilă. Fiecare nou tip de notificare necesita cod nou în aplicația principală, iar logica era distribuită în mai multe module.

În al cincilea rând, nu exista o politică unitară de preferințe. Un utilizator putea dori email pentru anumite evenimente, SMS pentru evenimente critice și push pentru actualizări rapide. Sistemul vechi nu putea gestiona elegant aceste opțiuni.

Obiectivele proiectului

În etapa de analiză, am definit împreună cu clientul câteva obiective clare.

• Separare — trimiterea mesajelor nu trebuia să blocheze fluxurile importante ale platformei.
• Scalabilitate — vârfuri de trafic, campanii și evenimente masive într-un interval scurt.
• Fiabilitate — retry fără duplicate când un mesaj eșuează.
• Multi-canal — email, SMS și push printr-o arhitectură comună.
• Personalizare — preferințe pe canal și tip de eveniment.
• Trasabilitate — răspuns rapid la „a fost trimis?”, „pe ce canal?”, „ce eroare?”.
• Securitate — fără expunere inutilă a datelor sensibile, mai ales pe SMS și push.

Soluția propusă

Am propus construirea unui modul centralizat de notificări, separat logic de restul aplicației. Acesta urma să primească evenimente din platformă, să decidă ce notificări trebuie generate, să aplice preferințele utilizatorilor, să aleagă canalul potrivit, să trimită mesajele prin furnizorii disponibili și să păstreze istoricul complet.

Arhitectura propusă avea câteva componente principale:

• sistem de evenimente;
• coadă de mesaje;
• worker-e dedicate pentru procesare;
• motor de template-uri;
• modul de preferințe utilizator;
• conectori pentru email, SMS și push;
• mecanisme de retry;
• jurnal de notificări;
• dashboard intern pentru monitorizare;
• alerte pentru erori și volume neobișnuite.

Ideea centrală: aplicația principală nu mai trimite direct notificări. Ea publică un eveniment, iar sistemul de notificări se ocupă de restul.

De la acțiuni directe la arhitectură event-driven

În sistemul vechi, logica era de tipul: „s-a întâmplat X, trimite email acum.”

În noua arhitectură, logica a devenit: „s-a întâmplat X, publică evenimentul în sistem.”

De exemplu: utilizatorul își creează cont; o comandă este confirmată; un document este disponibil; o plată este procesată; un termen important se apropie; un status se modifică; o acțiune de securitate are loc.

Fiecare dintre aceste situații generează un eveniment. Sistemul de notificări primește evenimentul și decide ce mesaje sunt necesare.

Această separare a adus un avantaj major: aplicația principală a devenit mai curată, iar notificările au putut evolua independent. Dacă se adaugă un canal nou, nu trebuie modificată toată aplicația. Dacă se schimbă un template, nu trebuie redeploy complet pentru fiecare flux. Dacă un furnizor extern are probleme, procesul principal nu este afectat direct.

Cozi de mesaje și worker-e

Pentru scalabilitate, am introdus o coadă de mesaje. În loc ca notificările să fie procesate imediat în requestul utilizatorului, evenimentele sunt puse într-o coadă, iar worker-ele le procesează asincron.

Această decizie a fost critică pentru performanță. Dacă 10.000 de utilizatori trebuie notificați într-un interval scurt, aplicația principală nu trebuie să trimită 10.000 de SMS-uri sau emailuri direct. Ea generează evenimente, iar worker-ele procesează loturile controlat.

Worker-ele pot fi scalate. Dacă volumul crește, pornești mai multe instanțe de procesare. Dacă volumul scade, reduci resursele.

În plus, coada oferă reziliență. Dacă un furnizor extern este temporar indisponibil, mesajele nu se pierd. Ele rămân în sistem și pot fi retrimise conform regulilor definite.

Template-uri centralizate

O altă problemă importantă era gestionarea template-urilor. În vechiul sistem, textele notificărilor erau dispersate în cod. Modificarea unui mesaj necesita intervenție tehnică și risc de inconsistență.

Am creat un motor de template-uri centralizat. Fiecare tip de notificare avea template separat pentru email, SMS și push. De exemplu, notificarea pentru „comandă confirmată” avea:

• template email, cu text complet și design;
• template SMS, scurt și direct;
• template push, foarte concis;
• variabile dinamice (nume utilizator, cod comandă, dată);
• versiuni și statusuri;
• posibilitate de activare/dezactivare.

Această abordare a permis echipei să gestioneze mai ușor mesajele și să păstreze consistența între canale. Am introdus reguli clare: SMS-ul nu conține date sensibile, push-ul nu expune informații confidențiale pe ecranul telefonului, iar emailul poate include detalii doar atunci când este justificat.

Preferințe de notificare pentru utilizatori

Într-o platformă cu 50.000 de utilizatori, nu toți oamenii vor să primească aceleași mesaje pe aceleași canale.

Am implementat un modul de preferințe care permite configurarea notificărilor în funcție de tipul evenimentului și canal. De exemplu:

• email pentru rapoarte și documente;
• SMS pentru alerte critice;
• push pentru actualizări rapide;
• dezactivare pentru notificări promoționale;
• canale obligatorii pentru notificări de securitate.

Nu toate notificările trebuie să fie opționale. Unele mesaje tranzacționale sau de securitate trebuie trimise indiferent de preferințele comerciale, în funcție de natura platformei și de regulile aplicabile.

O notificare de marketing nu are același regim ca o alertă de securitate sau o confirmare importantă de cont.

Email, SMS și push: canale diferite, reguli diferite

Unul dintre cele mai importante lucruri în proiect a fost înțelegerea faptului că fiecare canal are propriile reguli.

Emailul este potrivit pentru mesaje detaliate: confirmări, documente, rapoarte, instrucțiuni. Este relativ ieftin și flexibil, dar poate ajunge în spam sau poate fi ignorat.

SMS-ul este potrivit pentru mesaje scurte și urgente: coduri, alerte, confirmări importante. Este mai costisitor și trebuie folosit cu atenție.

Push notification este potrivit pentru reacție rapidă în aplicații mobile sau web, dar depinde de permisiunile utilizatorului și de dispozitiv.

Am definit reguli pentru fiecare canal: când se folosește; ce tip de mesaj permite; ce limitări are; ce date poate conține; cum se tratează eșecurile; când se face fallback către alt canal.

De exemplu, dacă o notificare push critică nu poate fi livrată, sistemul poate trimite SMS sau email, în funcție de regulile definite.

Retry, fallback și prevenirea dublurilor

Un sistem de notificări serios trebuie să presupună că unele mesaje vor eșua. Furnizorul de SMS poate avea timeout. Serverul de email poate respinge temporar mesajul. Tokenul push poate fi expirat. Rețeaua poate avea întârzieri.

Am implementat mecanisme de retry cu reguli diferite pe canal. Nu toate mesajele trebuie retrimise la fel. Pentru unele notificări, retry rapid este util. Pentru altele, o retrimitere după câteva minute este suficientă. Pentru erori permanente, cum ar fi număr de telefon invalid, retry-ul nu are sens.

Am introdus și idempotency. Fiecare notificare are un identificator unic, iar sistemul verifică dacă mesajul a fost deja procesat. Astfel, dacă același eveniment ajunge de două ori, nu trimitem aceeași notificare de două ori.

Nimic nu deranjează mai mult decât un sistem care trimite aceeași alertă de trei ori.

Rate limiting și protecție împotriva abuzului

La 50.000 de utilizatori, trebuie să fii atent nu doar la livrare, ci și la volum. Un bug sau o configurare greșită poate genera prea multe notificări — aceeași alertă către mii de utilizatori sau valuri de SMS-uri costisitoare.

Am introdus rate limiting și protecții operaționale:

• limită de notificări pe utilizator într-un interval;
• limită pe tip de eveniment și pe canal;
• oprire automată pentru volume neobișnuite;
• alerte către echipa tehnică;
• mod de pauză pentru un anumit template;
• aprobări pentru campanii sau trimiteri masive.

Observability: dashboard pentru echipa internă

Unul dintre cele mai apreciate rezultate a fost dashboardul intern de notificări. Echipa putea vedea notificări programate, trimise, livrate, eșuate, în retry, erori pe furnizor, volum pe canal și pe tip de eveniment, cost estimat pentru SMS, timp mediu de procesare, coada de mesaje și mesaje blocate.

Pentru suport, a fost introdusă căutarea după utilizator. Dacă un client spunea „nu am primit SMS-ul”, echipa putea verifica rapid dacă mesajul a fost generat, trimis, respins, retrimis sau blocat de preferințe.

Această vizibilitate a redus mult timpul de investigare.

Securitate și protecția datelor

Notificările pot expune date dacă nu sunt gândite atent. Un SMS poate fi citit de cineva care are acces la telefon. O notificare push poate apărea pe ecran blocat. Un email poate fi redirecționat.

Am aplicat principiul minimizării datelor. Mesajele scurte nu conțin informații sensibile — direcționează utilizatorul către platformă, unde se autentifică și vede informația completă.

Am introdus reguli pentru template-uri, loguri și payloaduri. Datele sensibile nu sunt salvate inutil în loguri, iar accesul la dashboardul de notificări este controlat pe roluri. Pentru notificările de securitate, am separat mesajele de marketing și cele tranzacționale, astfel încât preferințele comerciale să nu blocheze alertele importante de cont.

Testarea sistemului

Testarea unui sistem de notificări multi-canal este mai complexă decât pare. Nu testezi doar dacă un email ajunge. Testezi scenarii precum: utilizator cu email valid; telefon invalid; fără token push; furnizor SMS indisponibil; eveniment duplicat; template dezactivat; preferință de canal dezactivată; fallback; retry după timeout; volum mare; mesaj critic vs. promoțional; utilizator inactiv.

Am construit teste pentru fluxurile principale și am rulat teste de volum înainte de lansare. Am verificat comportamentul worker-elor sub încărcare, astfel încât sistemul să poată procesa vârfuri fără să afecteze aplicația principală.

Lansarea controlată

Nu am lansat sistemul pentru toți utilizatorii din prima zi. Am început cu un grup restrâns de evenimente și utilizatori. Am monitorizat livrarea, erorile și timpii de procesare. Apoi am extins treptat tipurile de notificări și canalele.

În paralel, am păstrat pentru scurt timp anumite mecanisme vechi ca fallback, până când noul sistem a fost validat complet.

Rezultatele

După implementare, platforma a obținut o infrastructură de notificări mai stabilă, mai scalabilă și mai ușor de administrat.

• trimiterea notificărilor a fost separată de aplicația principală;
• timpul de răspuns al fluxurilor importante s-a îmbunătățit;
• notificările au devenit trasabile;
• echipa de suport putea verifica rapid statusul mesajelor;
• dublurile au fost reduse prin idempotency;
• erorile furnizorilor externi au fost gestionate prin retry;
• template-urile au devenit centralizate;
• preferințele utilizatorilor au fost respectate;
• costurile SMS au putut fi monitorizate mai bine;
• adăugarea unui nou tip de notificare a devenit mai rapidă;
• sistemul a putut gestiona volume mari fără blocarea aplicației.

Poate cel mai important rezultat a fost creșterea încrederii operaționale. Echipa nu mai trata notificările ca pe o cutie neagră. Avea vizibilitate, control și instrumente de intervenție.

Lecții învățate

• Notificările trebuie tratate ca infrastructură, nu ca funcționalitate minoră.
• Nu trimite notificări direct din fluxurile critice dacă volumul poate crește.
• Fiecare canal are reguli diferite și trebuie gestionat separat.
• Fără idempotency, vei avea duplicate.
• Fără loguri și dashboard intern, suportul va lucra pe presupuneri.
• Retry-ul trebuie proiectat inteligent, nu aplicat mecanic.
• SMS-ul trebuie folosit cu atenție — are cost și poate deranja utilizatorul.
• Notificările nu trebuie să expună date sensibile.
• Lansarea etapizată este mai sigură decât migrarea bruscă.
• Un sistem de notificări bun devine fundație pentru multe funcționalități viitoare.

Ce se poate adăuga ulterior

După prima versiune, sistemul poate fi extins cu: A/B testing pentru template-uri; preferințe mai detaliate pe categorii; centru de notificări în aplicație; notificări programate; campanii segmentate; analiză de engagement; prioritizare inteligentă; fallback automat între furnizori; multi-provider pentru SMS și email; rapoarte de cost pe canal; integrare cu CRM; automatizări bazate pe comportament.

O arhitectură bună permite aceste extinderi fără rescriere completă.

Concluzie

Construirea unui sistem de notificări multi-canal pentru o platformă cu 50.000 de utilizatori nu înseamnă doar integrarea cu un furnizor de email, SMS sau push. Înseamnă arhitectură, scalabilitate, fiabilitate, preferințe, retry, securitate, observability și control operațional.

Notificările sunt una dintre punțile principale dintre platformă și utilizator. Dacă sunt livrate corect, utilizatorul este informat, procesele se mișcă mai rapid, iar echipa internă lucrează mai eficient. Dacă sunt livrate prost, apar confuzie, frustrare și costuri operaționale.

În acest proiect, soluția a fost separarea notificărilor într-un sistem dedicat, bazat pe evenimente, cozi, worker-e, template-uri centralizate, preferințe utilizatori și monitorizare. Rezultatul a fost o platformă mai scalabilă și o echipă cu mai mult control.

Pentru companiile care cresc, notificările nu trebuie tratate ca un detaliu. Ele sunt parte din infrastructura digitală a businessului. Iar când utilizatorii sunt mulți, canalele sunt multiple și mesajele sunt importante, arhitectura face diferența dintre un sistem fragil și unul enterprise-ready.