Best practices to send large volume of sms using Pinpoint.

0

Hi,

Our use case requires us to send a large number of sms in a short time span, around 30000/5 minutes for which we already have a short code. These are not promotional messages but important alerts for our users so delivering in time matters a lot.

Now, I've already gone through the following articles a) https://aws.amazon.com/blogs/messaging-and-targeting/queueing-amazon-pinpoint-api-calls-to-distribute-sms-spikes/ b) https://aws.amazon.com/blogs/messaging-and-targeting/how-to-manage-global-sending-of-sms-with-amazon-pinpoint/ and still have a few doubts.

Assuming the default limit of 100MPS for short code, we might be able to achieve our goal if we can tackle the following questions

  1. How to ensure that we are firing 1 api call per second if we refer to article 'a' above?
  2. Also how to we utilise the maximum TPS without throttling, with reference to article 'a' above?
  3. Is monitoring the logs the only way to find out status of messages at carrier level?
  4. For which type of errors(at both carrier level and pinpoint level) should we retry sending the messages?

Any reference/guidance to go about building a solution for our use case would be deeply appreciated.

1 Answer
0

Hello, Please find the answers below:

  1. How to ensure that we are firing 1 api call per second if we refer to article 'a' above?

As mentioned in the document, it specifies on how to limit the API calls by using the SQS queueing mechanism along with the lambda function. You can implement a similar mechanism which allows consuming queue messages at fixed-rate.

  1. Also how to we utilise the maximum TPS without throttling, with reference to article 'a' above?

To maximize the Transactions Per Second (TPS) without throttling, you can use Batch API Calls i.e, instead of sending individual API calls for each message, batch them together. Group multiple messages into a single API call to reduce the number of requests made to Amazon Pinpoint. This can significantly improve efficiency and throughput. Also you can use Parallel Processing i.e, you can design your system to process multiple messages in parallel. This can be achieved by increasing the number of Lambda function instances processing messages from the SQS queue concurrently.

  1. Is monitoring the logs the only way to find out status of messages at carrier level?

Yes, currently inorder to find the status of the messages, the only possible way is to monitor the logs. It provides the details about messages whether they are delivered or failed due to any error.

  1. For which type of errors(at both carrier level and pinpoint level) should we retry sending the messages?

Kindly refer the following document for the different types of SMS errors that generally occur: [+]. https://repost.aws/knowledge-center/sns-unknown-error-phone-sms

You can implement the retry mechanism on all the errors that you are receiving. Please refer the below document which specifies on how to retry unsuccessful sms deliveries.

[+]. https://aws.amazon.com/blogs/messaging-and-targeting/how-to-utilise-amazon-pinpoint-to-retry-unsuccessful-sms-delivery/

AWS
answered 3 months ago
  • Hi, thanks a lot for the detailed response. I think I have clarity on 3 and 4. Coming to your answer for question 2, my concern is question 1 again. We will have batches of phone numbers for each API call and my concern is w.r.t. parallel processing of requests. Consider a scenario where I have 3 lambdas, concurrently consuming from SQS. If they all fire an API call with their respective batches, I'm sure at least two of them would be within the same second. Won't pinpoint throttle my requests at that point? In the end the "originator short-code" would be same for all API calls so won't I end up exceeding my TPS?

    Or am I missing something here?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions