Search code examples
amazon-sqsserverless-frameworkamazon-snsserverlessaws-serverless

How to handle "resend" email in SNS and SQS


I have an SNS topic called onboard-user. A lot of microservices subscribe to this topic

for ex:

Emai microservice - to send the email

System preferences microservice -To set the defaults

There is a queue in these microservices that subscribes to the onboard-user SNS topic.

Now, if the email to the user needs to be resent, how should it be handled? onboard-user should not get a new message in that case as that has its own purpose and we would not want all of the microservices listening to it to be notified.

Having an alternate SNS topic for send emails doesn't sound like such a good idea and an overkill. what's the right way to handle it?


Solution

  • Why would an email need to be resent? Due to a transient error or due to some business logic initiated by an end user? The solution depends on the problem. I would argue that if you detect the case where a message needs to be recent that you either: (A) maintain separate resend email SQS queue OR (B) put a new message on the existing email queue with a field indicating that this is a resend.

    Since SQS is pretty cheap, I could lean towards (A).