Pushes a venue's events to its subscribers, and refuses to grow their mailboxes without a bound.

Why this module exists

DpExchange.Core.Venue's DpExchange.Core.Venue.subscribe/2 doc has said this since the contract was written:

A venue pushing faster than its subscriber consumes drops beyond a stated bound and emits a :degraded notice saying so. Growing a mailbox silently until the node dies is the failure this avoids; dropping silently is the failure the notice avoids.

It was a guarantee no package provided. All five venues fanned out with a bare send/2 in five identical private fan_out/2 functions, none of which had ever looked at a subscriber's mailbox. A consumer reading the contract was told back-pressure was handled and declared; neither half was true. That is the failure this family names most often — a statement that stays entirely plausible while only its meaning is wrong — sitting in the contract itself rather than in a venue.

The exposure is not theoretical. dp_exchange_coinbase's level2 channel measured 4258 delta frames in the window that produced this family's coverage incident. A subscriber that stalls for thirty seconds against a stream like that accumulates a mailbox in the hundred-thousands, and the node dies with no notice, no log line and nothing in coverage/1 to suggest anything was wrong: the feed was delivering perfectly the whole time.

Newest is dropped, not oldest — and the contract used to say otherwise

The wording above used to read "drops oldest beyond a stated bound". A sender cannot drop the oldest message in another process's mailbox. Nothing in the BEAM lets one process remove a message another process has already been sent; the receiver owns its own queue. Written that way, the sentence described something no implementation could ever have honoured, which is part of why nothing implemented it.

What a sender can do is decline to add to a queue that is already past its bound, which is what this module does. So the contract now states the achievable guarantee. Dropping the newest is also the better trade for this data: a quote or a book delta that arrives while a consumer is thirty thousand messages behind is worthless by the time it would be read, and the frames it would push out are no fresher.

Checking is cheaper than the send it guards

Measured before it was written, on the machine this family develops on:

Process.info/2 : 0.029 us/call (empty mailbox)
Process.info/2 : 0.028 us/call (100k backlog)
send/2         : 0.097 us/call

:message_queue_len is a counter the process already maintains, so reading it is O(1) and does not walk the queue — the 100k-backlog figure is the one that proves it. At 0.3x the cost of the send/2 it replaces or permits, there is no case for sampling the check, latching it for N messages, or any of the other complications that would have been reasonable if it had turned out to cost more than the send. It runs on every message to every subscriber.

One notice per transition, never one per dropped message

A stalled subscriber that produced a notice per dropped message would emit them at the rate of the stream it cannot keep up with — into the same fan-out that is already overloaded, and to a notice subscriber that may be the very process that is behind. The cure would be worse than the disease.

So the caller carries the set of subscribers currently being dropped, and deliver/4 returns it back along with only the transitions: :dropping the first time a subscriber is found over its bound, :resumed the first time it is found back under. Both are worth a notice — a consumer needs to know when data loss started, and it needs to know when it stopped, because those two instants bracket exactly what it has to reconcile from a pull endpoint.

The set is rebuilt from what was observed on each call rather than edited in place, so a subscriber that dies or unsubscribes while over its bound leaves it without needing to be pruned.

Notices are never dropped

deliver/4 is for a venue's data stream. A Core.Notice goes out through the caller's own unbounded path, and must: the notice announcing that a subscriber is being dropped cannot be the first casualty of that same subscriber being dropped. Notices are low-volume by construction — link transitions, coverage changes, refusals — and no venue in this family has ever produced them at a rate that could bury a consumer.