Skip to content

x/messaging Primer

Beta (app-facing service layer) — API is stable within a minor version. Subordinate packages (x/messaging/mq, x/messaging/pubsub, x/messaging/scheduler, x/messaging/webhook) remain experimental. Check Release Posture and Extension Maturity before adopting in production.

Open this page after x/* Family when the work is clearly about messaging-family ownership instead of the smallest runnable path.

x/messaging is the canonical app-facing entrypoint for queue, pubsub, scheduler, and webhook orchestration at the family level.

Start from x/messaging for family-level decisions, then verify subordinate package maturity before depending on x/messaging/mq, x/messaging/pubsub, x/messaging/scheduler, or x/messaging/webhook directly. Check x/messaging/module.yaml, Release Posture, and Extension Maturity before production use.

  • the task is message send orchestration
  • the change is app-facing queue, pubsub, scheduler, or webhook wiring
  • the work needs a family-level messaging entrypoint instead of a lower-level primitive
  • the task is application bootstrap
  • the work is really stable-root abstraction design
  • the task is already known to be narrow low-level work in x/messaging/mq, x/messaging/pubsub, x/messaging/scheduler, or x/messaging/webhook

First files to read in the current repository

Section titled “First files to read in the current repository”
  1. x/messaging/module.yaml
  2. x/messaging/entrypoints.go
  3. specs/extension-taxonomy.yaml

Use the family-level aliases and constructors before opening subordinate packages directly:

  • messaging.NewInProcBroker plus BrokerMessage and BrokerSubscription for in-process pubsub wiring
  • messaging.NewWebhookService, messaging.NewWebhookMemStore, and VerifyWebhookHMAC for webhook flows
  • messaging.New for the app-facing messaging service
  • messaging.NewMemReceiptStore for receipt persistence in examples and tests
  • messaging.NewLogSMSProvider, NewLogEmailProvider, and HTTP provider constructors for delivery adapters
Start in x/messaging when the work is aboutDrop into a narrower sibling only when the work is already about
family-level app-facing queue, pubsub, scheduler, or webhook orchestrationdurable queue primitives and worker coordination in x/messaging/mq
deciding the messaging entrypoint a service should open firstin-process broker primitives in x/messaging/pubsub
keeping orchestration explicit without redefining the canonical app pathscheduling primitives in x/messaging/scheduler
messaging-family ownership questions that are still broader than one protocol primitiveinbound verification or outbound delivery mechanics in x/messaging/webhook

x/messaging matters because it keeps readers from jumping into a sibling package too early. The family entrypoint exists so messaging work can start from the right scope before narrowing.