Capabilities
Messaging & Reliability
Outbox, inbox, and eight broker transports behind one abstraction — exactly-once effects over at-least-once delivery.
The moment an event must leave your service, two classic bugs are waiting: the dual write (database saved, message never sent — or the reverse) and the duplicate delivery (one event, two side effects). Relay ships both halves of the answer.
What ships: the outbox (integration events staged in the same PostgreSQL transaction as your state change, relayed to the broker by a background processor), the inbox (idempotent, exactly-once processing of at-least-once delivery), end-to-end reliable flow with dead-letter queues, retention and backlog maintenance, error policies (kill-switch, rate, circuit, backpressure), claim-check for large payloads, and partitioning.
Transports are pluggable behind IMessageBroker / IMessageConsumer:
RabbitMQ, Kafka, Azure Service Bus, Amazon SQS, NATS, Pulsar, ActiveMQ (NMS)
and in-memory for tests. Swapping brokers is configuration, not a rewrite.
The stories behind it: The Payment That Published But Never Happened, The Email That Sent Itself Five Times, and The Partner Who Spoke a Different Language.
Learn by building
The tutorials for this area, in order — each with a runnable sample.
011The Outbox PatternA command often needs to do two things: change its own state (save the order) and tell other services about it (publish OrderPlaced).
012Messaging & TransportsThe outbox stages events; a transport carries them.
013The Inbox PatternThe outbox guarantees at-least-once delivery — which means the same message can arrive twice (a broker redelivery, an outbox re-publish after a crash).
014Reliable Messaging (End to End)The previous three articles built the pieces; this one assembles them into the complete, reliable, cross-service flow: