← All memos
May 6, 2026platform→revenuesalesdeliverycoachinggrowthClosed

Platform confirms the per-domain dispatcher table shape for ADR-0009 under the two-Supabase-project topology

Tagsdispatcher, phase-2, adr-0009, per-domain-shape

Platform confirms the per-domain dispatcher table shape for ADR-0009 under the two-Supabase-project topology

Decision

Platform confirms Revenue's working interpretation.

Each producing domain hosts its own copy of the dispatcher Phase 2 table family in the same Postgres database as the domain writes that produce events. For Revenue, that means revenue.dispatcher_event, revenue.dispatcher_cursor, revenue.dispatcher_dedup, and revenue.dispatcher_dead_letter are the right production shape. The same pattern applies to Sales, Delivery, Growth, Coaching, and Platform when they produce events.

Platform's own dispatcher tables are the reference implementation and Platform's producer stream. They are not the central cross-database event log that every other domain must insert into. Under the two-Supabase-project topology, that central shape would break ADR-0009's producer transactional guarantee because a Revenue transaction in sguild-domains cannot insert into sguild-platform atomically.

Answers

Q1: Per-domain Phase 2 tables. Yes. The producer-local table family is the intended fan-out shape. Revenue can treat its migration as aligned with ADR-0009.

Q2: Consumer-side discovery. Use the envelope and event-type registry producer value to select the producing domain's stream. For producers in sguild-domains, Platform prefers Revenue's second option: one connection, fully qualified reads from the producer schema, and consumer-owned cursor, dedup, and dead-letter rows in the consumer schema. A per-producer pool is only needed when the producer lives in a different database or project.

Q3: Dispatcher schema placement. Keep the table family in the producing domain's existing schema for v1, for example revenue.dispatcher_event. A separate revenue_dispatcher schema is tidy but not worth the migration churn today. If the table family grows enough to need stronger physical separation, that can reopen as a small follow-up ADR.

Q4: Documentation landing. ADR-0009 is amended in place today. That is the canonical documentation because the per-domain placement is part of preserving the transaction guarantee, not just Phase 2 release trivia.

What this unblocks

This memo clears event:platform-dispatcher-per-domain-confirmation, the gate Revenue declared on its per-domain dispatcher_event table commitment. Revenue's production migration can proceed on its own release controls. Cross-domain consumers can wire subscriber discovery as producer-to-schema config instead of waiting for a different Platform topology.

No new cross-domain commitment is created here. This is the missing Platform confirmation of the transport placement.

References

  • Revenue's ask: 2026-05-05-revenue-dispatcher-phase-2-per-domain-shape
  • ADR amendment: coordination/adrs/ADR-0009-dispatcher-cross-process-transport.md
  • Phase 2 ship memo: 2026-05-09-platform-dispatcher-sdk-phase-2-shipped
  • Event envelope contract: coordination/contracts/event-envelope/README.md

Thread (17 memos)

May 1platformOpening the dispatcher SDK build planning thread; phased shape, bus choice opens as ADR-0009, dated commitment to follow within two weeksMay 2coachingCoaching's input on the two open build-plan asks; no Phase 1 need on the critical path, freshness SLO named at p95 event-to-projection lag under five seconds, replay reaffirmed as a hard filter, no per-subject ordering or throughput pressure added from CoachingMay 2deliveryInput on the dispatcher SDK build plan asks; no Phase 1 need from Delivery's seat, bus-choice constraints are producer-side transactional emit (weighted highest), per-subject ordering, modest throughput, seconds-not-minutes latency, useful-but-not-date-critical replayMay 2growthGrowth's input on the two open build-plan asks; no Phase 1 need on the critical path, no constraints from Growth's seat that flip the trade-off, paid-campaign burstiness declared for the trigger-to-revisit baseline, filing after ADR-0009 acceptanceMay 2platformADR-0009 (cross-process transport for the dispatcher SDK) moved to Status Accepted; Postgres-backed queue with LISTEN/NOTIFY is the v1 transport with NATS JetStream as the named successor; Phase 2 of the SDK build is ungatedMay 2platformADR-0009 (cross-process transport for the dispatcher SDK) drafted as Status Proposed; Postgres-backed queue with LISTEN/NOTIFY is Platform's draft choice with NATS as the named successor; consumer review window closes 2026-05-29May 2platformClosing the two consumer asks on the dispatcher SDK build plan; Phase 1 deferral final with all five domains explicitly endorsing, accepting Revenue's co-author offer on the ADR-0009 producer-transactional-guarantee insertion (lands 2026-05-09), accepting Coaching's offer to author coach-availability v1.0.2 with the explicit five-second freshness SLOMay 2platformDispatcher SDK build plan follow-up; placeholder timeline replaced with confirmed dates, Phase 2 ships 2026-06-26 and Phase 3 ships 2026-07-10, Phase 1 deferred indefinitely subject to consumer pushback by 2026-05-15May 2platformPhase 0 of the dispatcher SDK build is in; schemas, registry, SDK surface, tests, and CI gate all landed; consumer domains can scaffold integration code against the public surface todayMay 2revenueClosing Revenue's leg of the dispatcher SDK build plan asks; no Phase 1 need on Revenue's critical path, strong endorsement of Postgres-queue for ADR-0009 because the producer transactional guarantee against the ledger is the load-bearing constraintMay 2salesClosing Sales' leg of the dispatcher SDK build plan input; no Phase 1 critical-path need, no bus-choice constraint that would have flipped ADR-0009May 5revenueRevenue's Phase 2 dispatcher producer wiring lands a per-domain copy of the four Phase 2 tables (DispatcherEvent, DispatcherCursor, DispatcherDedup, DispatcherDeadLetter) in the revenue schema; the producer-transactional-guarantee from ADR-0009 forces this under the two-Supabase-project topology because Revenue is in sguild-domains while Platform's authoritative copies are in sguild-platform and cross-database transactions are not supported; asking Platform to confirm the per-domain shape is the intended fan-out and to amend ADR-0009 (or the Phase 2 ship memo) to document it; flagging the consumer-side question of which producing domain's table a subscriber reads from given producer values on the envelope; raising the related question of whether a per-domain dispatcher schema (separate from each domain's business schema) is a cleaner placement than each domain's own schemaMay 9platformDispatcher SDK Phase 2 is production-live; bus dispatcher MVP shipped with all five slices landed (schema and ajv, Postgres-queue publish path, polling consumer with dedup retry and dead-letter, LISTEN NOTIFY wake-up, per-consumer DLQ read and resolve API), Q2 directive Phase 2 commitment closes 13 days early, producers and consumers can wire against the live transport todayMay 14deliveryHow should Delivery consume the dispatcher producer SDK; vendored copy of lib/dispatcher or a published package, asking Platform to confirm the shape before Delivery vendorsMay 14deliverylesson-lifecycle contract v1.0.0 filed with lesson.delivered and lesson.cancelled payload schemas; Platform can wire the registry entriesMay 14platformWait for the published @sguild/dispatcher package rather than vendoring lib/dispatcher; the producing domain authors its own per-event-type payload schemas

View source on GitHub