The event envelope, and what can be said about one without touching a broker.
An event crossing a process boundary carries more than its payload: which module emitted it, which request caused it, and which tenant it belongs to. The first is for the reader of a log, the second keeps one correlation id across an asynchronous hop the way the RPC adapter does across a synchronous one (BOU-90), and the third is not optional — an event delivered to the wrong tenant is a data leak, not a bug in ordering.
FC/IS: pure. Nothing here connects to anything.
The event envelope, and what can be said about one without touching a broker. An event crossing a process boundary carries more than its payload: which module emitted it, which request caused it, and which tenant it belongs to. The first is for the reader of a log, the second keeps one correlation id across an asynchronous hop the way the RPC adapter does across a synchronous one (BOU-90), and the third is not optional — an event delivered to the wrong tenant is a data leak, not a bug in ordering. FC/IS: pure. Nothing here connects to anything.
Malli schema for an event.
:id is assigned by the publisher rather than the broker, so a consumer can
recognise a redelivery. At-least-once delivery means the same event arrives
twice sooner or later, and a consumer that cannot tell has no way to be
idempotent.
Malli schema for an event. `:id` is assigned by the publisher rather than the broker, so a consumer can recognise a redelivery. At-least-once delivery means the same event arrives twice sooner or later, and a consumer that cannot tell has no way to be idempotent.
(event {:keys [id type source payload published-at correlation-id tenant-id]})Build an event of type from source carrying payload.
id and published-at are supplied rather than generated: this namespace
is pure, and a random id or a clock reading here would make every test of it
untestable. The shell passes them in — see wagoe.events.shell.publisher.
Build an event of `type` from `source` carrying `payload`. `id` and `published-at` are supplied rather than generated: this namespace is pure, and a random id or a clock reading here would make every test of it untestable. The shell passes them in — see `wagoe.events.shell.publisher`.
(event-problem {:keys [id type source published-at] :as event})Why event cannot be published, or nil.
Checked before it reaches a broker, because an event that is malformed on the wire fails at the consumer — in another process, minutes later, with nothing to say where it came from.
Why `event` cannot be published, or nil. Checked before it reaches a broker, because an event that is malformed on the wire fails at the consumer — in another process, minutes later, with nothing to say where it came from.
(matches-tenant? tenant-id event)Whether event may be handled by a consumer scoped to tenant-id.
An event with no tenant is a system event and goes to everyone. An event with one goes only to that tenant — a subscriber must never see another tenant's events because it happened to be listening to the same topic.
Whether `event` may be handled by a consumer scoped to `tenant-id`. An event with no tenant is a system event and goes to everyone. An event with one goes only to that tenant — a subscriber must never see another tenant's events because it happened to be listening to the same topic.
(redelivery? seen-ids event)Whether event has been seen before, given the ids already handled.
At-least-once is what a broker can offer; exactly-once is what a consumer builds on top by keeping this set. Here so that it is testable and so the documentation for it has somewhere to live, rather than being a paragraph in an adapter.
Whether `event` has been seen before, given the ids already handled. At-least-once is what a broker can offer; exactly-once is what a consumer builds on top by keeping this set. Here so that it is testable and so the documentation for it has somewhere to live, rather than being a paragraph in an adapter.
(topic-problem topic)Why topic cannot be published to, or nil.
Topics become stream names, and a broker will happily create one called
nil or "". The publish succeeds, nothing consumes it, and the events
are gone — so this is a refusal rather than a warning.
Why `topic` cannot be published to, or nil. Topics become stream names, and a broker will happily create one called `nil` or `""`. The publish succeeds, nothing consumes it, and the events are gone — so this is a refusal rather than a warning.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |