Possibility to delay service reloads/restarts so repetitive actions in short time can be avoided

I maintain systems on which event-driven reloads or restarts of services occur frequently. This can lead to various events triggering multiple reloads of the same service within a short period of time (seconds). The order in which these events occur is non-deterministic, though. So, I was looking for a way to delay the reload or restart of a service so multiple of these triggers can be queued and the service is just changed once. I was surprised that I couldn't find any information on this as I wouldn't expect to be alone with this problem. Just as an example: One event that may trigger reloads of other services would be a change of IP addresses obtained via DHCP/DHCPv6/RA which may result in a reload of firewall rules, etc.

In order to work around this problem I wrote myself a little script as a wrapper around systemctl and systemd-run. So, if I want to delay or queue reload request for 5 seconds, the script utilizes systemd-run to create a transient timer unit to trigger the reload in 5 seconds. If a subsequent event calls the script a second later to queue a reload, a check will be performed first to see whether a timer for a reload of this unit is already active and if yes, nothing will be done and a repeated reload is avoided. The logic goes even further. E.g.,when a delayed restart of a unit is requested, it checks whether a reload timer for the same unit is already active and if yes, replace that with the restart timer. This has greatly reduced the number or actual reloads and restarts of services on my systems.

Thus, I'm wondering whether it would not be useful for others to implement such functionality in systemd itself that allows systemd to wait for a short period of time to collect multiple reload/restart requests and just execute them once. If there is already a better way to achieve this, I'd appreciate if someone could point me in the right direction.

Disclaimer: Of course, such behavior should be merely an option and not the default. In fact, I also have services where I don't use any delays, but then there are others where it's just not critical whether the job is triggered a little bit later as long as it's triggered at all.

The issue names no files, tests, or entry points. Start by investigating how systemd queues reload and restart requests, then determine the intended semantics and affected components before defining what an implementation and its tests would need to cover.