cCadence
OverviewCampaignsOps✦AI Agent
Cadence
How the ops view works
Operations

The loop, observable.

Dispatch queue, token bucket, webhook retries, dead letters — the async callback machinery, live. auto-refreshes every 2.5s.

CRM service
Online
Receipt events processed:
Last receipt: Pulling the ledger…
Channel service
Unreachable
Uptime:
Sim clock: · TPS limit:
Dispatch queue depth (max → then 429 backpressure)
Tokens available (bucket refills at /s)
Webhook retries (exp. backoff + jitter, at-least-once)
Dead letters (gave up after 3 attempts — never silently dropped)
Communications by state
QUEUED
SENT
DELIVERED
OPENED
READ
CLICKED
FAILED
SUPPRESSED
CONTROL HELDOUT
Forward-only state machine — duplicate and out-of-order receipts are recorded in the audit trail but never regress state.
Dead letter queue
Field note · reliability
How the callback loop stays correct
01 · Backpressure
Dispatch is throttled by a token bucket (provider TPS) with a bounded queue. When it fills, the channel returns 429 and the CRM backs off — nothing is dropped.
02 · At-least-once
Receipts are redelivered with exponential backoff + jitter until the CRM acknowledges them.
03 · Idempotent
The webhook dedupes on eventId, so retries and duplicate deliveries are harmless no-ops.
04 · Dead letters
Poison payloads and receipts that exhaust retries land in the dead-letter table above — never silently dropped.
At real scale: SQS/Kafka per campaign, batched receipts, columnar stats — same contracts, bigger pipes.