2

To simplify the use case, let's say I have a mobile app available for Android and iOS, similar to Instagram, where users can upload photos that can be commented, liked or disliked by other users. When a user comments, likes or dislikes a photo you uploaded, you would get a real time notification on your phone telling you about the type of action, the name of the user and the photo it is about.
Users can follow each other, followers would also get a notification when a user they follow uploads a new photo.

I will use AWS SNS, so I need to decide about how to organize and use the topics. By default, SNS offers 10 million subscriptions per topic, and 100,000 topics per account. My app has less than 100,000 users and is not expected to reach 1 million users anytime soon. I guess the design would be very similar with Microsoft Azure ou Google Cloud (but with different constraints).

I see 4 options so far:

  1. I create only 1 topic, I publish all the notifications in it with details about what kind of action happened: all users subscribe to that topic and are notified about everything that happens. The mobile app has to filter the relevant notifications (according to some locally stored data like the IDs of the users the user follows, the IDs of his photos, etc.). I am new to mobile development, maybe I am wrong but I feel like it's a bad design to process all the notifications and query the local storage all the time.
  2. I create 1 topic per action: photo posted, photo commented, photo liked, photo disliked, and users select the topics they want to subscribe to. Still, the app needs to filter all the notifications for each selected topic.
  3. I create 1 topic per user where his actions will be published, and "followers" would be subscribed to appropriate topics (the users they follow). Doable now but the AWS limit being 100,000 I suppose there is a reason and it's maybe not the way big companies do. Also this only works between users who follow each other, ideally I want users to also be notified when random users comment/like/dislike their photos.
  4. Similar to point 3, I create 1 topic per user but this time I publish what other users do with his stuff (comment, etc.) in that topic (+ his followers posting new photos for instance), so he would be the only subscriber to that topic and would get only relevant notifications. There is still the 100,000 topics limit problem.

What do you guys think or how have you designed/implemented such system?

Maxime Laval
  • 131
  • 3
  • 1 and 2 sound like great ways to upset your users (why is this app using my data and battery life sending me notifications for other users?!). Better to have SNS send the events to an HTTP server (or alternatively a SQS). And have the server/queue workers route the events to the relevant users. – walpen Dec 08 '16 at 03:15
  • I agree about 1 and 2, it's what I was implying in my question ;-) I'll edit my question with what I ended up doing. – Maxime Laval Dec 08 '16 at 15:47

2 Answers2

1

So since you can not directly subscribe to an SNS topic from a device, I used Google Firebase and the way it works is devices get assigned a unique token which I map to SNS platform endpoints (meaning I need to use a database). So 1 device = 1 active endpoint (= 1 active token) at a time. My backend then decides to what endpoints send notifications according to the action, and at the end the devices/users only receive relevant notifications.

Maxime Laval
  • 131
  • 3
0

Actually scratch that last answer. You don't even need to do any of the above, you can store the platform endpoint ARN on your server for every user and just send notifications to that ARN when you have a notification for that user.

RibaldEddie
  • 3,168
  • 1
  • 15
  • 17