Section 9: From Outbox to Pixel - Deep Dive: Idempotent Web Push Delivery

Executive Summary: We follow a notification intent from Section 8's outbox row to Maya's screen. CDC relays intents into Kafka; each (notification, device) pair is claimed with a leased conditional put in a delivery ledger, then encrypted, signed and sent per the Web Push RFCs, and driven to a terminal state. The one gap no transaction closes, a crash after the push service accepted the message, is covered by the Topic header and client-side dedupe: at-least-once delivery the user sees as once.

Section 8 left 12,400 watches on B0EXAMPLE4 TRIGGERED, each with an outbox row. That's durable intent, not a notification. Between row and screen sit a log relay, a bus, our senders, a push service we don't own, a maybe-closed browser and a service worker that may run twice.

Interviewer: "The prompt said exactly once. Can you deliver that?"

You: "Not end to end. The push service and the browser are outside our transaction boundary. Once FCM answers 201, I can't atomically record that I sent. I can build at-least-once delivery the user sees as once. That's effectively-once, and it's the claim I'll defend."

The Path, End to End

The relay. A Debezium-style CDC process tails the shard's write-ahead log and publishes each outbox row to notification-intents, keyed by user_id. We rejected the evaluator calling the sender directly (a crash after commit loses the notification) and dual-writing DB then Kafka (a crash between writes splits them). The log records what committed, so tailing it can't invent or lose an intent, but it is at-least-once, so the sender must tolerate duplicates.

The sender loads Maya's two push subscriptions (Chrome laptop, Firefox desktop) and handles each (notification_id, install_id) pair separately: about 14,900 pushes across the burst (12,400 × 1.2).