AWS SNS gebruik ik wanneer meerdere onderdelen van een systeem moeten kunnen reageren op dezelfde gebeurtenis, zonder dat de producer hoeft te weten wie daar uiteindelijk iets mee doet.
Voor mij zit daar ook direct de kracht van SNS. Je maakt communicatie losser gekoppeld en voorkomt dat één service steeds meer verantwoordelijkheden en directe integraties krijgt.
Wat is AWS SNS?
AWS Simple Notification Service is een managed publish-subscribe dienst van AWS.
Een producer publiceert een bericht naar een topic. Vervolgens kan AWS dat bericht doorzetten naar één of meerdere subscribers.
Denk bijvoorbeeld aan:
AWS Lambda
SQS
HTTP endpoints
E-mail
Andere AWS-integraties
Daardoor kan één gebeurtenis meerdere processen starten zonder dat de producer iedere consumer afzonderlijk hoeft aan te roepen.
Wat vind ik belangrijk bij SNS?
De producer hoeft de consumers niet te kennen
Dat vind ik een van de belangrijkste voordelen.
Wanneer een bepaald event plaatsvindt, moet de producer alleen verantwoordelijk zijn voor het publiceren daarvan.
Welke systemen daarna luisteren, hoort daar wat mij betreft niet thuis.
Dat houdt services kleiner en voorkomt onnodige afhankelijkheden.
Gebruik SNS niet als vervanging voor goede eventmodellering
Een topic aanmaken is technisch eenvoudig.
De moeilijkere vraag is wat je daadwerkelijk publiceert.
Ik probeer events daarom altijd betekenis te geven vanuit het domein. Niet alleen vertellen dat iets technisch veranderd is, maar duidelijk maken wat er functioneel gebeurd is.
Fan-out is waar SNS sterk wordt
SNS vind ik vooral interessant wanneer meerdere processen op hetzelfde event moeten reageren.
Bijvoorbeeld wanneer één gebeurtenis uiteindelijk leidt tot:
Een e-mail
Een administratieve verwerking
Logging of auditing
Een ander asynchroon proces
Dan wil je niet dat de producer al die verantwoordelijkheden zelf gaat orkestreren.
Hoe ik AWS SNS gebruik
Ik gebruik SNS vooral als distributielaag binnen event-driven processen.
Een backendservice publiceert een gebeurtenis en SNS zorgt ervoor dat verschillende subscribers daarop kunnen reageren.
Conceptueel ziet dat er bijvoorbeeld zo uit:
Backend → SNS Topic → meerdere consumers
Daarmee houd ik de primaire flow bewust eenvoudig.
Wanneer betrouwbaarheid en onafhankelijke verwerking belangrijk worden, combineer ik SNS liever met queues dan dat iedere consumer direct afhankelijk wordt van het topic.
Dat geeft iedere consumer meer controle over zijn eigen verwerking, retries en foutafhandeling.
Waar ik AWS SNS heb gebruikt
Bij Marvia heb ik meerdere jaren gewerkt binnen een SaaS-platform waarin AWS onderdeel was van de backendarchitectuur. Daar heb ik onder andere gewerkt met AWS Lambda, SES en SNS in combinatie met microservices en andere cloudcomponenten.
SNS paste daar goed bij processen waarin verschillende onderdelen van het platform onafhankelijk moesten kunnen reageren op gebeurtenissen.
Die ervaring heeft mij vooral geleerd dat SNS het meest waardevol wordt wanneer je het gebruikt om verantwoordelijkheden uit elkaar te trekken, niet alleen omdat publish-subscribe technisch eenvoudig beschikbaar is.
Mijn ervaring met AWS SNS
Mijn ervaring met SNS komt voornamelijk uit backend- en microserviceomgevingen waarin asynchrone communicatie belangrijk is.
Ik zie SNS vooral als een praktische manier om fan-out te realiseren binnen AWS.
Tegelijkertijd kijk ik altijd naar wat het systeem daadwerkelijk nodig heeft.
Voor complexere eventstromen, grotere hoeveelheden events of situaties waarin ordering, replay en uitgebreide eventhistorie belangrijk worden, kijk ik eerder naar technologieën zoals Kafka.
SNS hoeft voor mij niet alles op te lossen.
Juist wanneer het probleem relatief simpel is, vind ik het sterk.
Veelgestelde vragen die ik krijg over AWS SNS
Wanneer kies je SNS?
Wanneer één gebeurtenis door meerdere onafhankelijke consumers verwerkt moet kunnen worden zonder directe koppeling tussen producer en consumer.
Wat is voor jou het grootste voordeel van SNS?
De eenvoud van fan-out. Eén producer publiceert één keer en meerdere processen kunnen daar onafhankelijk op reageren.
Combineer je SNS met SQS?
Ja. Dat vind ik vaak een sterke combinatie wanneer iedere consumer zijn eigen verwerking, retries en buffering nodig heeft.
Wanneer zou je Kafka kiezen in plaats van SNS?
Wanneer eventhistorie, replay, hoge throughput of complexere eventstromen belangrijk worden. SNS gebruik ik liever wanneer het probleem eenvoudiger is.
Is SNS hetzelfde als een queue?
Nee. SNS distribueert berichten naar subscribers. Een queue bewaart berichten totdat een consumer ze verwerkt. In de praktijk kunnen die twee juist heel goed samenwerken.