Does your network bandwidth ever feel like this congested freeway? Do you ever have a subscription that gets so many messages that it really cannot process them all? If you answered yes, why haven’t you tried using conflated subscriptions?

Conflated subscriptions help to reduce the bandwidth for a subscription and may reduce the processing resources required for that subscription as well. They work just like conflated topics, which are defined in the AMPS config, but with a couple of differences. The differences are you can set the conflation interval on a per subscription basis and you can subscribe to any topic, not just conflated topics. This is great if you have multiple subscriptions that may have different intervals in which they need to process data.

Let’s look at an example where conflated subscriptions might be useful. Imagine there is an application which displays selected stocks with their current prices. This display refreshes every two seconds. Since the application only refreshes the display every two seconds, it only needs new data every two seconds, rather than a full stream of the price changes. On the other hand, a trading desk might need the full stream of messages and therefore will not set a conflation interval or conflation key(s) on their subscriptions.

To accomplish this, the display application can place a subscription that updates the price based on the tickerId with a conflation interval of two seconds and a conflation key of tickerId.

For example, in Python:

client = AMPS.Client("myConflatedClient")
client.connect(uri_to_amps)
client.logon()
command = AMPS.Command("subscribe").set_topic('prices') \
              .set_options('conflation=2s, conflation_key = [/tickerId]')
message_handler = messageHandler()
client.execute_async(command,message_handler)

AMPS will hold the data for each distinct tickerId for two seconds before sending a message to the application. For example, AMPS will receive the following messages within the conflation interval:

{"tickerId":"IBM","price":150.34}
{"tickerId":"IBM","price":149.76}
{"tickerId":"MSFT","price":70.76}
{"tickerId":"IBM","price":149.32}
{"tickerId":"MSFT","price":70.94}
{"tickerId":"IBM","price":151.10}

Any messages that are received by AMPS with the same tickerId will be replaced until the two second interval is reached and then the data is sent to the subscriber. Only the last message for each conflation_key is delivered by AMPS at the end of the interval:

{"tickerId":"IBM","price":151.10}
{"tickerId":"MSFT","price":70.94}

This means the application does not have to process many updates that will ultimately never end up being displayed, it will not waste time parsing unecessary updates and an up to date price is always shown on the refresh interval. This will free up some of your bandwidth and let you unleash the horses under the hood of your other subscribers. This also means that your application may not receive messages strictly in the order published, but will receive the last message for each distinct conflation key during the interval.

Even More Power

Conflated subscriptions are new in AMPS 5.2. They’re just one of the ways that AMPS can provide conflation. Conflated subscriptions are the simplest to demonstrate, since they don’t require changes to the AMPS configuration. Conflated subscriptions require AMPS to calculate conflation individually for each subscription that requests conflation. If several applications (or several instances of an application) all need conflation at the same interval, use a Conflated Topic instead. The results are the same for each individual subscriber, but AMPS keeps track of conflation for the topic as a whole rather than an individual subscription, which is more efficient. Conflated topics are also available in older versions of AMPS, so if you’re on an earlier version, conflated topics are the available option.