Message queues alternative in mobile development

Question

please let me know if this StackExchange isn't the place for this and I will move the question.

I'm trying to write a mobile app that will have a 'notification' aspect. I have web development experience so my references will include that :)

A "post" gets into my backend API/database for which there will be subscribers (app users), I want to notify those subscribers of the post, my app would then fetch the post and store it locally on the device. If this was a web application/service, I would use a Message Queue like RabbitMQ with consumers subscribing to an exchange, when a new event gets fired (e.g. "new-post:123") relevant consumers would get the message and fetch "https://domain.com/post/123" and do whatever they want with that. Although post 123 would still stay in the database on the API side, the consumer wouldn't need to fetch that post again. So consumer doesn't need to poll or list all posts to check if there is any new posts.. etc.

What is the approach taken in mobile development for such a need? I don't think I can rely on push notification services like OneSignal to take the place of message queues as push notifications don't seem to be reliable at all! Notifications get lost when mobile is offline for longer periods, or are delayed. Message queues on the other hand are very reliable; messages are persisted in exchanges/routes until they're consumed.

Answer 1

It doesn't exist.

There isn't a queuing system on the planet that does not have real hard caps to the amount of messages that it can preserve. These might be insanely larges numbers, but they are real and do exist.

Neither is there a message system that can guarantee delivery. The best any message service can offer is best effort. Usually this is very reliable, but still best effort means that messages may not get delivered for any number of reasons.

As such plan to have dropped messages.

On the happy path your notification reaches the devices and spurns a sync with the main server using your internal message logs to update itself with every message since it last checked in. AKA. Event logs.

On the unhappy path the notification does not reach the device.

But the next one does and on syncing discovers the missed message. Better late than never.

And neither does the next notification after that...

But the user logs in to the client and on syncing discovers the X odd missed messages. Again better late than never, and chances are the user is looking at the screen, just the right time to inform them.

And the notifications keep getting missed on and on and on...

But the user logs in to the client. But a sync is impossible... the oldest message the client remembers is so far in the past it has dropped off the time horizon into ancient history, or prehistory. Either way retrieving all the queued messages won't 100% guarantee that the client reflects the server.

There are two options to resolve this:

• Not reflecting the server is fine, the number of messages required to do this would understandably be too large for the client to cache anyway. Just drop the current cache and load the new message set.
• Not reflecting the server is NOT fine. The client must have a consistent cache with the server. Purge the local cache and perform a complete resync, then process any message queued past that.

---

As an aside, you can have another process on your server push another notification after a period of inactivity. Particularly if it was expected that the client would connect within some window of time after receiving the original push.

However make sure you cap the number of retries, not to save your budget, but also to avoid pestering a client that has other plans.