A completely different way to solve the polling problem is to wrap the DB. The wrapper exposes the same interface the DB would. Have everything talk to the DB wrapper. The wrapper talks to the DB saying whatever was said to it.

You might even use a traffic sniffer for this. That way nothing needs to be reconfigured. Just find a way to send it out as a stream.

The advantage here is now nether the DB nor the updating processes need to know what values are tied to events. Only the wrapper does.

Now the wrapper can send out events to registered listeners. Do this over rest and the listener can be on any box.

You could have the wrapper filter down to just what the observer cares about to keep traffic down but to make sure this doesn't slow the DB if there are many observers you may want to dedicate one box for an unfiltered feed.

This is closer to how big data people solve this problem. Depending on your real needs consider this approach.

A completely different way to solve the polling problem is to wrap the DB. The wrapper exposes the same interface the DB would. Have everything talk to the DB wrapper. The wrapper talks to the DB saying whatever was said to it.

You might even use a traffic sniffer for this. That way nothing needs to be reconfigured. Just find a way to send it out as a stream.

The advantage here is now nether the DB nor the updating processes need to know what values are tied to events. Only the wrapper does.

Now the wrapper can send out events to registered listeners. Do this over rest and the listener can be on any box.

You could have the wrapper filter down to just what the observers care about to keep traffic down but to make sure this doesn't slow the DB if there are many observers you may want to dedicate one box for an unfiltered feed.

This is closer to how big data people solve this problem. Depending on your real needs consider this approach.