Respond To Asynchronous Notifications

Goal

We need to send asynchronous text and email messages in specific scenarios. For example, the requester of a Saayam Request must be notified after their request is successfully created. Volunteers chosen to lead or participate in a Saayam request need a similar notification via text message or email. When a user is notified this way, it would be convenient for them to be guided to the related request page or be able to directly respond to the message to perform actions. This document explores different options on how a user can respond to asynchronous notifications, particularly SMS messages.

Update

The team has decided to start with Option 2 in implementing the asynchronous notification functionality.

Option 1: Ask users to log in to their Saayam account for further actions

Description:
The default method is to ask the user to log in to their Saayam account, where they can perform any further actions.

Pros:

• Communication remains one-way only. It is easier for the service side to generate these messages without worrying about possible future operations on them.
• Correlating a message with its responses is not necessary. For this kind of fan-out message, we can use simple services, including SNS and SES, which only have limited functionalities in handling incoming messages. Specifically, SNS does not support two-way SMS, and SES can only dump incoming emails to other AWS services like S3 without correlating them to emails previously sent by SES.

Cons:

• Users need to do more work, including logging into their accounts and navigating to the notification section before performing any action, which can be discouraging.

Option 2: Put a link inside messages that directs the user to the corresponding notification page (Current Approach)

Description:
We can include a link in the message we send. When a volunteer receives an async notification and wants to accept the request, they can click the link, which should direct users to the corresponding notification page. Users will need to log in first to see the notification and be able to accept/reject requests from there.

Pros:

• It saves time by eliminating the need to manually open a new page to log in and navigate to their notifications page to accept requests. Clicking a link from the message can be easy enough for a user not to be discouraged.
• The backend services only need minimal work. The link will be the same as the one used to navigate to a specific notification page on Saayam’s web app.
• Adding a link will not depend on the notification services we use. We can continue using simple services like SNS and SES.

Cons:

• We need to authorize the user on the linked page to prevent the usage of forged or leaked links, which adds some work for both the backend and the user clicking the link.

Option 3: Use AWS Pinpoint for two-way SMS messages

Description:
AWS Pinpoint supports two-way SMS messaging. We can create a project in AWS Pinpoint receiving SMS replies from users, then use a lambda function to handle replies by setting the lambda function as the destination of the two-way messaging.

Pros:

• Minimum work for users. Volunteers only need to reply with certain words to accept or reject requests.
• Using an AWS service makes it easier to integrate with other services in Saayam, including the SQS + lambda messaging.
• Pinpoint can handle millions of users, so scalability won’t be an issue.

Cons:

• More development work on cloud and backend service. We need a lambda function to receive SMS replies and parse the message body. Then, we need another backend endpoint to handle parsed reply messages.
• There is no correlation between replies and request messages, which means that we only receive what a volunteer responded to, “Confirm,” for example, without knowing which request they are confirming. The user needs to add some unique ID to indicate what they are confirming, or each volunteer can only be asked with one request every 24 hours so that we always know which one they are confirming/rejecting.
• There may be security issues as the users don’t need to log in. The phone number can be phishing or stolen, or the entire reply may be forged.

Option 4: Use 3rd party library (e.g., Esendex) to achieve two-way SMS messages

Description:
Other than AWS pinpoint, some 3rd party libraries/APIs support two-way SMS messaging.

Pros:

• Still minimum work for users.
• Some APIs can be directly integrated into the spring boot project and handle replies using backend logic only.

Cons:

• Can incur unexpected costs using 3rd party business services.
• It may not be able to integrate with some AWS services we are now trying to use, like SNS or SES.
• The correlation between requests and replies remains an issue. I’m not sure if these APIs can connect replies with messages sent.
• Using a backend endpoint to handle replies can be as or more vulnerable to security issues than the AWS option.