Push Notifications on the Cheap

One of the problems with feed updates, such as an RSS or a podcast feed, is that they're not real time. Each client, that subscribes to a feed, will continuously poll the server for updates (usually every thirty minutes). The two leading solutions to solve this problem are rssCloud and PuSH.

Real time notification can be somewhat of a challenge due to the fact that most clients are behind a firewall. Punching a hole through a firewall is too much to ask of the casual user, plus it could potentially open the client to security issues.

Even for a client that has solved the problem of negotiating the client's firewall, there's still a bandwidth issue. Each push notification server must maintain a connection with its subscribed clients so that it can notify them of updates; this is usually done via a socket which is a constantly-open IP connection. The problem with this is that there's a bandwidth cost to keep this connection open.

Push Without The Bandwidth Overhead Costs

A workaround that I'm visualizing can avoid any unnecessary bandwidth push notification costs charged to the publisher/aggregator by simply using Amazon's Simple Email Service (SES). Here's how it would work:

1. The client app would be configured to check a client's e-mail address for notifications.

2. Notifications would be sent to subscribers using SES.

3. When the client received the notification e-mail, it would then ping the publisher to receive the update.

The cost benefit of this is realized by shifting the notification bandwidth channel from the client and publisher notification server to the client and their mail server. Most data centers will charge their customers based on bandwidth, so there's a cost for a publisher to maintain a push notification channel with all of their clients. But, there is no cost for a client to maintain a connection with their mail server. In the past, new e-mail notification relied on client polling (usually once per minute). However, most modern mail clients now rely on the IMAP IDLE feature for immediate notification. New notifications would be received within a few seconds by having the subscriber's client implementing IMAP IDLE.

The e-mail account notification could be implemented two different ways. The publisher could maintain their own e-mail account which all of the clients check or, each client could maintain their own e-mail account. The former option would only work with a small number of clients. The latter option allows the publisher to manage traffic by pushing out notifications over a short timeframe to manage the "thundering herd" problem if scaling is an issue.

While this is not the most elegant solution, it eliminates all unnecessary bandwidth overhead costs involved with maintaining a notification channel. The only costs incurred by the publisher are for bandwidth used to publish the notifications and updates.