0
votes

I have the following use case scenario for which I am considering aws services to see how I can come up with a scalable solution. Thanks in advance for your help!

Scenario: Users can sign up to an application(which is named say 'Let's Remind' or something else) using their email and phone. The app does one thing that is to send email and sms alerts to user. User can create n number of tasks for which he wants to be reminded. For instance he can set up a monthly reminder for paying card dues. Currently the value of n is from 5 to 10 per user. The notifications are flexible meaning it can be daily, weekly, monthly, bi-weekly. User can also specify the start date of a notification. The end date is the date when the event is due (for instance the day the card payment is due). Once this date is expired the notification is rendered inactive for the current month. For weekly,daily,bi-weekly notifications, the notifications are deleted once the event date is passed. These are not recurring in nature. For monthly recurring events such as payment of apartment rent etc, notification itself is not deleted but rendered inactive after the event due date. Once the next event cycle (typically next month billing cycle for payments use case) starts, the notification comes back to life and starts all over again. Use can delete any event anytime he wants. If an event is deleted, the notifications for that event will be deleted as well.

First of all, I hope the use case is clear. Now here's my thoughts so far about solving this use case -

1) Use SNS since I need to send email and sms both. SES only supports emails. 2) When a user registers for the app, create 2 subscriptions(one for his email and one for his sms endpoint) and also create a topic for the user(maybe a dynamically generated random userid) 3) Once user creates an event (e.g. reminder for monthly apartment rental), store the event data such as userid, startdate, duedate, frequency, isactive in a dynamodb table. 4) Create a lambda function that will wake up when an entry is written to the dynamodb table (step 3); it will do the following - i) it will read the event data from the dynamodb table ii) determine the next date of the notification to be sent based on the current date and event data iii) For active events (check isActive column of the dynamodb record) create a scheduled cron expression rule based on ii above in cloudwatch events and add the target as the user's topic (created in step 2 above). For now, the notification message is static.

I have some doubts/queries about step iii - Is it possible to create cloudwatch event cron rule dynamically and add the user's topic as target dynamically as I described? Or is it better to trigger a second lambda function dedicated for sending messages to the user's topic using SNS notification? Which approach will be better for this use case? If user base grows large, is it recommended to create one topic per user? Am I on the right track with my approach above in general from a scalability point of view? If not, can anyone suggest any better idea for implementing this use case?

Thanks in advance!

1
This may work for a small set of users. But when your user base grows, this won't work.Yeshodhan Kulkarni
So, what approach or aws services would you suggest? Any related link or article will be helpful.chakrar
I have edited the question with more details. Does anyone have any idea if my approach would work in this case? Thanks.chakrar

1 Answers

0
votes

This will not work. For SNS email subscriber to receive email notification sent via SNS it has to first confirm the subscription. You cannot just create subscriptions on the fly and send them email notification

I don't think SNS fits your use case. You would be better off sending email notifications using SES.

You can write your scheduling logic in Lambda though