messaging
Messaging
A message system gives you one of two guarantees: at most once (nothing is stored, a message sent while nobody listens is gone) or at least once (stored and retried, so duplicates will arrive). Exactly-once delivery isn't on offer; exactly-once effects are something you build, with an outbox on the sending side and idempotent handling on the receiving side. Read the file for the job:
Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]
| The job | Read |
|---|---|
| A use case touches several systems and can half-succeed; per-aggregate ordering; whether you need a saga | FAILURE-AND-ORDER.md |
| Outbox and inbox tables in Postgres, the processor, scaling it, idempotent consumers, external calls | OUTBOX-INBOX.md |
| Queue vs log vs pub/sub, RabbitMQ topology, Kafka consumer groups, Redis channels | BROKERS.md |
Design-level questions (domain vs integration events, process managers, compensations, event sourcing) are in the domain-modeling skill's EVENTS.md; job queues, workers and 202 Accepted APIs are in the background-jobs skill.