verschied. Lambdas (Likes, Posts, Follow, Login, ...)
1. Events werden in die Event Queue geschrieben
2. Lambdas verarbeiten die Events parallel und schreiben bei hohem Workload in eigene Queues, Lamdas um die einzelnen Events aufzuteilen. Bei vielen Einträgen kommt hier eine eigene Queue die dann die Last von verschiednene Notifications nochmals auf andere Lambdas aufteilt. Eventuell angegeben als Notifications Lambda Service. die Lambda wird direkt von AWS gestartet, wenn eine Nachricht in der Queue liegt – ohne HTTP-Server
3. DynamoDB speichert die Daten persistent ab. DynamoDB speichert meine Einträge sofort, aber auch ob für den User schon eine ungelesene Nachricht existiert, dass nicht hunderte Notifications aufscheinen.
4. API Gateway stellt die Daten der App / Frontend zur Verfügung. Eventuell mit GraphQL und einem AppSync, um Messages an den User zu senden. Aber auch Websockets.
Ziel ist es hier die HTTP Subscriptions aus dem FE ein wenig zu vermeiden. Frontend/APP subscribed zu AppSync oder Websocket. Das heißt sobald ein Eintrag in der DynamoDB hereinkommt, sendet GraphQL AppSync oder Websocket diesen MutationRequest zum User/Account
Die Idee wäre hier auch den Login oder Sessionstart als Event zu nutzen der hier die nächste Lambda anstößt für ein Notifications Update
Eine andere Option wäre ein Redis Setup auf einem EC2. Vielleicht beim Gespräch dazu mehr