The major benefit that publishers gain from this type of system is the fact that subscribers no longer need to periodically poll the publisher to check for updates to content they are interested in. A single subscriber making requests at regular intervals does not incur a lot of load, but if there are thousands of subscribers all continually requesting updated content from the publisher at regular intervals, it’s easy to imagine how heavy the load can get on the publisher’s side.

This burden on the publisher wouldn’t be so bad if subscribers only made single requests once the content has changed, but the only way for subscribers to know that is to make a request to the provider, creating a Catch-22 situation. This is the point, and role, of the hub in this specification. Subscribers subscribe to the hub only once for a given feed, and when the publisher pushes updates to the hub, it will in turn notify the subscribers of the update. Although the hub may periodically poll the publisher’s feeds if the publisher does not notify the hub of updates, this is only a single request source for a potentially large number of subscribers.

On the other side of the fence, the largest benefit from the subscriber side is exactly the same as that of the publisher: there is no need to repeatedly poll the publisher for new updates.

In the past, if the subscriber wanted to get updated content from a publisher, it would need to periodically poll the publisher to obtain the content that it was interested in. In this polling request, the content may or may not have changed, so it was up to the subscriber to determine whether any update action was needed on its side. This is a highly inefficient system that wastes requests and processing resources for content that may not have even changed.

With the hub in place, however, the subscriber only needs to make a single request to subscribe to a publisher’s feeds, specifying the update URI that the hub should POST updates to when the publisher updates any content. The subscriber simply waits for something to be POSTed to that endpoint and processes it once it arrives.

Another core benefit to the distributed hub system stems from the fact that the hub will push out the same updated content to all subscribers. This means that any changes to the content will be viewed in the exact same way, no matter which source the user chooses to view that content with.

To put this in practical terms, let’s say we have two subscribers subscribing to an article and comment thread on a provider site. Without a hub to control the flow of updates to all of the interested parties, it is up to the subscribers to manage how often they look for new comments on the article. This might mean that one of the parties is seeing vastly different comments from the other, creating individual silos out of each site.

With the hub in place, once new comments are posted or updates to the article are introduced, the provider can simply update the hub, which in turn updates all subscribers to that content.

This model creates a uniform series of sites that all reap the benefits of sharing identical content.