It&#x27;s a problem in theory, not in practice. The notion of throwing away old data (or coalescing new with old) is relevant to slow queues. It turns out to be irrelevant with ZeroMQ.<p>First, message rates with ZeroMQ are often hundreds of thousands per second. The architecture must be designed so that no buffers, anywhere, overflow. If they do, you have a problem, usually a slow subscriber. Throwing out older data doesn&#x27;t cure the problem. What ZeroMQ does is punish the slow subscriber by dropping so that the publisher doesn&#x27;t crash. It&#x27;s not recovery for the subscriber, it&#x27;s protection for the publisher (and thus for other subscribers).<p>Second, trying to delete old messages is complex and sometimes impossible (if they&#x27;re already in system buffers). The design of ZeroMQ&#x27;s internal pipes has one writer and one reader, without locks. For the writer to mess with the reader would slow down everything and introduce risk of bugs. Dropping new incoming data is the only way anyone has ever found to keep things running at full speed.<p>These design choices were often delicate and counter-intuitive, yet they have turned out to be mostly accurate.