Let's consider different cases, depending on subscription cache usage. Let's consider two Orion nodes (A and B) without loss of generality, both sharing the same MongoDB instance.
Using subscription cache (i.e. -noCache is not set)
The subscription creation request is dispatched to some of the nodes (let's assume it is node A). Node A will persist the subscription in the shared DB and in the local (i.e. node A) subscription cache. Note that node B doesn't get aware of the new subscription until next subscription cache refresh, which means. That is as much an interval of seconds equal to -subCacheIval parameter.
Let's consider now an update (on an entity/attribute which matches subscription conditions to trigger notification) arrives. Depeding to which node the load balancer dispatches the update and the moment in which it arrives (with regards to subscription creation request time) it can happen one of the following cases:
Update arrives at node B, before next subscription refresh (i.e. as much as -subCacheIval seconds). Given that node B doesn't know anything about the subscription, notification is not sent.
Update arrives at node B, after next subscription refresh (i.e. as much as -subCacheIval seconds). Node B is aware of the new subscription as a consecuence of the refresh, so the notification is sent.
Update arrives at node A, no matter wether before or after next subscription refresh. Node A was the one creating the subscription, so its cache is up to date since the very begining. Thus, the notification is sent.
Colorary: waiting -subCacheIval after subscription creation will ensure that subscription has been propagated to all CB nodes, thus notification will be always sent. However, note that setting a too small -subCacheIval value could have negative effects. The trade-off is analyzed in the Orion performance documentation section.
Finally, regarding throttling, pay attention to the following remark in the Orion implementation notes:
In addition, Orion implements throttling in a local way. In multi-CB configurations, take into account that the last-notification measure is local to each Orion node. Although each node periodically synchronizes with the DB in order to get potentially newer values (more on this here) it may happen that a particular node has an old value, so throttling is not 100% accurate.
Thus, if you need precise throttling, it is better to implement it at notifier reception endpoint than using the one provided by Orion.
Not using subscription cache (i.e. -noCache is set)
In this case, subscription evaluation is always done querying the DB. Thus, no matter which node (either A or B) created the subscription, as it is stored in DB. Thus, no matter if A or B processes the update, as it will check in the DB for matching subscriptions and notification is always sent in that case.
However, note that this mode (not using subscription cache) could have severe performance drawbacks (especially in the case of using pattern-based subscriptions) so it is not recommended.
I'm not fully sure, but the throttling issue decribed for the other scenario probably doesn't happen in this case.
