# Bygde e‑post som en plattformfunksjon — tre leverandører med failover, leveringswebhooks, logging av sending og levering, maler og kampanjer — bak en oppstartskontroll som ikke lar plattformen starte uten minst én leverandør. 2025 **Situasjon.** E‑post bærer mye av tyngden på plattformen — verifisering, varslinger, sammendrag, kampanjer, det en bruker faktisk venter på. Og en e‑postleverandør er nettopp den typen avhengighet som svikter i det stille: konfigurasjonen ser grei ut, appen starter, og man oppdager først at noe er galt når et ekte menneske aldri får meldingen vedkommende ble lovet. Det er den verste måten å få vite det på. Med bare én leverandør blir det verre, fordi feilen er total og det er noen andre som må rette den. **Oppgave.** E‑post måtte behandles som en kapabilitet plattformen eier, ikke som et klientbibliotek den kaller — i stand til å overleve et driftsavbrudd hos en leverandør, i stand til å si hva som skjedde med en gitt melding, og høylytt ved oppstart i miljøene der stillhet er farlig. **Handling.** Tre leverandører står bak ett grensesnitt — SendGrid som primær, med SMTP2GO og Azure Communication Services bak — og failover mellom dem skjer automatisk, ikke som en konfigurasjonsendring gjort under press. Levering tas ikke for gitt: innkommende webhooks rapporterer hva hver leverandør gjorde med en melding, og begge sider registreres, i en sendelogg og en tabell for leveringshendelser, slik at «fikk denne personen verifiseringsmeldingen sin» er en spørring og ikke en gjetning. Maler holder meldingsinnholdet utenfor koden, og et eget skjema for masseutsendelser — 5 tabeller og 24 funksjoner — bringer kampanjer ut til brukersegmenter, som er et annet problem enn transaksjonell e‑post og ble bygget som et eget. Foran alt dette sender en oppstartskontroll en ekte melding gjennom hele stakken, styrt av et flagg: i utvikling logger den en advarsel og fortsetter, fordi ingen vil at den bærbare maskinen skal nekte å starte på grunn av en utløpt sandbox‑nøkkel, og i staging og produksjon er en feil fatal, og prosessen avslutter heller enn å produksjonssette et bygg som ikke kan sende e‑post. Selve sendeveien går gjennom en SSRF‑beskyttet klient med et tidsavbrudd på 30 sekunder, og den asynkrone leveringsveien har nye forsøk med backoff, slik at et kortvarig hikk ikke fører til at en melding går tapt. **Resultat.** En hel kategori stille feil gikk fra «en bruker merker det dager senere» til «produksjonssettingen stopper», og en leverandør med en dårlig ettermiddag ble til degradert drift i stedet for et driftsavbrudd. Prisen er tre integrasjoner å holde i gang i stedet for én, og leveringslogger som vokser og må ryddes — begge deler akseptert, fordi e‑post er kanalen plattformen ikke kan rute utenom. --- - Rolle: Backend‑ingeniør - Kategorier: [Backend‑utvikling](https://software.engineer.company/nb/categories/backend/), [API‑er og integrasjon](https://software.engineer.company/nb/categories/api/), [Skytjenester](https://software.engineer.company/nb/categories/cloud/), [Pålitelighet og sikkerhetskopier](https://software.engineer.company/nb/categories/reliability/), [Sikkerhet](https://software.engineer.company/nb/categories/security/) - Tjenester: [Backend- og API‑utvikling](https://software.engineer.company/nb/services/backend-development/), [Pålitelighet og overvåking](https://software.engineer.company/nb/services/site-reliability/), [Sikkerhet og tilgangsstyring](https://software.engineer.company/nb/services/security-access/)