One way of controlling the "pace" on the publishing side is to take advantage of the latency budget QoS. That way, if the DDS implementation you use takes advantage of this QoS, you know that the messages will not be sent right away but that the middleware will pace transmission to try buffering for an amount of time driven by the LATENCY_BUDGET.
Another way of controlling burst is provided on the subscribing side and that is the HISTORY. This QoS allows you to define how many sample the middleware should save for a specific topic instance. As a result this QoS allows you to avoid missing intermediate updates that might come burstly.
Finally, some DDS implementations, and here I can only speak for OpenSplice DDS, provide the ability to do traffic shaping, further providing control over bursty behaviour.