Notifier scalability #11
Description
The notifier needs a lot of work to make it scalable. Consider a situation where you have N enrollments assigned to a set and you update a declaration in that set. All N enrollments need to be notified. If this set is, for example, your entire fleet, N could get quite large. Right now the notifier immediately notifies the enrollments and blocks while doing so. Some improvement suggestions:
- Send notifications asynchronously (separate go routine service)
- Have worker threads that consume a notification channel.
- Maintain an internal queue of notifications to be sent — perhaps an ordered map of enrollment IDs — that the worker threads can "pop" from.
- De-dup notifications over a time frame. I.e. only send DM commands every X seconds/minutes. This allows time for potentially duplicate notifications to be subsumed in the existing queue.
- Only send a reasonable amount of DM command enqueueing at once. 20-50 max (if using the URL-based queueing of NanoMDM, for example)