a) When a lower number of buckets is configured, no new activities will be added to the higher-numbered buckets. If the bucket is in process of being collected, it will be collected to completion and will forever no longer exist (all columns will be deleted from it). I suppose if the bucket isn't being collected at the time that the number of buckets is decreased, it can end up being ignored by the pollers indefinitely. Roughly at the most `collectionPollingFrequency` seconds amount of activities would appear to be "lost". That could be a problem. Might need something in place to rescue those. I don't imagine it would be necessary to lower the amount of buckets, though ? I guess if your load decreases, but still you can just lower the amount of activity nodes and increase the number of concurrent collections allowed for nodes.

b) When a larger number of buckets is configured, allocation of activities into those new buckets will begin immediately, and pollers will immediately start to scan and collect. Should be OK. However, when allocation starts into a new buckets configuration, this algorithm accepts the fact that activities are temporarily subject to race conditions (i.e., it is possible that activityType+route combinations aren't always allocated in the same bucket, as the modulus has changed). This is the case until all previous activities are collected. I have accepted this potential issue in favour of not locking and rebalancing all the routed activities into the new buckets.