# Byggde e‑post som en förmåga i plattformen — tre leverantörer med failover, webhooks för leveranser, loggning av utskick och leveranser, mallar och kampanjer — bakom en startkontroll som vägrar starta utan en leverantör. 2025 **Situation.** E‑post väger tungt på plattformen — verifiering, aviseringar, sammandrag, kampanjer, det som en användare faktiskt väntar på. Och en e‑postleverantör är precis den sortens beroende som fallerar i det tysta: konfigurationen ser bra ut, appen startar, och du upptäcker att något är trasigt först när en verklig person aldrig får meddelandet som utlovades. Det är det sämsta sättet att få veta det. En enda leverantör gör det värre, eftersom felet då blir totalt och någon annans att åtgärda. **Uppgift.** E‑post behövde behandlas som en förmåga som plattformen äger snarare än ett klientbibliotek som den anropar — som klarar ett avbrott hos en leverantör, som kan redogöra för vad som hände med ett visst meddelande och som säger ifrån högljutt vid uppstart i de miljöer där tystnad är farlig. **Handling.** Tre leverantörer sitter bakom ett gemensamt gränssnitt — SendGrid som primär, med SMTP2GO och Azure Communication Services bakom — och failover mellan dem sker automatiskt i stället för som en konfigurationsändring under press. Leveransen tas inte för given: inkommande webhooks rapporterar vad varje leverantör gjorde med ett meddelande, och båda sidorna registreras, i en utskickslogg och en tabell för leveranshändelser, så att ”fick den här personen sitt verifieringsmejl” blir en databasfråga i stället för en gissning. Mallhanteringen håller meddelandetexterna utanför koden, och ett separat schema för massutskick — 5 tabeller och 24 funktioner — levererar kampanjer till användarsegment, vilket är ett annat problem än transaktionell e‑post och byggdes som ett sådant. Framför alltihop skickar en kontroll vid uppstart ett verkligt meddelande genom hela stacken, bakom en flagga: i utveckling loggar den en varning och fortsätter, eftersom ingen vill att den egna laptopen vägrar starta på grund av en utgången sandlådenyckel, och i staging och produktion är ett fel fatalt och processen avslutas i stället för att ett bygge som inte kan skicka e‑post driftsätts. Själva sändningsvägen går genom en SSRF‑skyddad klient med en timeout på 30 sekunder, och den asynkrona leveransvägen har omförsök och backoff så att en tillfällig störning inte tappar ett meddelande. **Resultat.** En hel kategori av tysta fel flyttades från ”en användare märker det dagar senare” till ”driftsättningen stoppas”, och en leverantör som har en dålig eftermiddag blev ett nedsatt driftläge i stället för ett avbrott. Priset är tre integrationer att hålla vid liv i stället för en, och leveransloggar som växer och måste rensas — båda accepterade, eftersom e‑post är den kanal som plattformen inte kan gå runt. --- - Roll: Backendingenjör - Kategorier: [Backendutveckling](https://engineer.company/sv/categories/backend/), [API:er och integration](https://engineer.company/sv/categories/api/), [Molntjänster](https://engineer.company/sv/categories/cloud/), [Tillförlitlighet och säkerhetskopiering](https://engineer.company/sv/categories/reliability/), [Säkerhet](https://engineer.company/sv/categories/security/) - Tjänster: [Backend- och API‑utveckling](https://engineer.company/sv/services/backend-development/), [Tillförlitlig drift och övervakning](https://engineer.company/sv/services/site-reliability/), [Säkerhet och behörighetshantering](https://engineer.company/sv/services/security-access/)