sendgridsendgrid-api-v3

To use Azure Queue for SendGrid, or not?


I am looking to use SendGrid to send emails based on some trigger(S) within an application. Should the application invoke SendGrid API calls to send emails, or should it send emails to Azure Queue and have some other process send the email from Azure, like an Azure micro service?


Solution

  • Some years late to the party, but here are my thoughts:

    It depends on your context, and the question is not specific to SendGrid, rather it is a more generic architectural question, whether to use synchronous or asynchronous flow.
    One aspect could be the latency/availability. you should check latency and SLA of the SendGrid API you are using, and compare that to the response times available when just queuing a message. If you would hit a bottleneck with SendGrid for example, then you might need to spread out your load into one or multiple queues and let consumers eventually process them.
    Another one could be whether you need instant feedback if the sending succeeded or not. In the sync approach, you send the email (call any API) immediately, and if that gives you some error, you'll know it right there and then. In the async / queue flow, the processing might happen later in time. Yet another aspect could be what level of monitoring you wish to have - if any - on your transactional messages sent out. Do you track the execution of triggers in your app, or you fire-and-forget and you treat it as "sent"? If using a queue, you can centralize kind of an overview over it in your consumer worker, but whether you need this or would be overkill depends on your use case.

    In general, however, for simple cases, I think just sending to the API right away does the job, and you will "naturally" start to feel when you need more complex flow.