You can limit this by limiting how quickly Relays send UDP notifications to clients, or not use UDP at all and instead use command polling, though I wouldn’t generally recommend that approach.
It seems that limited the speed of UDP notifications is a very good thing for large environments where this is likely to be an issue and helps mitigate exactly the problem you are referring to with SANs and WANs.
Also, to clarify, it sounds like you are asking for scheduling around notifications for updates at the Relay level so that Relays in one region would tell clients about new things on one schedule, while Relays in another location would tell clients about new things on a different schedule due to the region specific timing of business hours.
One problem with this approach is if the Relay doesn’t notify any clients of any changes at all until a window is hit, that means the amount of changes and the number of clients that will be notified at that window coming will be much more significant than it would be otherwise, so you will still need to limit the UDP notifications as mentioned above, otherwise this situation will be even worse. What you really need is to spread this out more evenly over time, by slowing down UDP or using command polling.
BigFix by default wants to get changes to clients as quickly and efficiently as possible, this is a case of BigFix working too well and overwhelming a WAN due to lack of Relay behind it or a SAN due to increased Disk IO.
Client Settings for Relays to Limit UDP speed:
_Enterprise Server_ClientRegister_BatchCount
( unique value of (it as integer) of values of settings "_Enterprise Server_ClientRegister_BatchCount" of clients | 100 )
_Enterprise Server_ClientRegister_BatchDelay
( unique value of (it as integer) of values of settings "_Enterprise Server_ClientRegister_BatchDelay" of clients | 1000 )