The short version
Pick the field that is different on every event, usually an id:paymentLinkId, orderId, appointmentId.
- Each distinct value sends its messages once, ever, per customer.
- The same value arriving again for that customer sends nothing.
- Two different values for the same customer send two messages, even at the same time.
An example
Your system records apayment_link_created event each time a payment link is
made, and the Transactional identifies each send by paymentLinkId.
Without that field, Boom could not tell a new payment link from a retry of an
old one, and would either message the customer every time your system retries
or only once for all of their links.
Choosing the field
- Use an id that your system creates once per thing, the same one you would use to look it up later.
- Do not use a field shared by many events, like the customer id, a status or an amount. A customer id would send only the first message the customer ever gets, and never again.
- Do not use a field that changes on a retry, like a timestamp or a request id. Every retry would send again.
Id, Boom picks it for you. If
your event has not arrived yet, type the field’s name; it only has to match
what your system will send.
Sending the field
Put the field in the event’sproperties:
externalId is a different thing: it identifies the event record itself, so
recording the same externalId twice stores it once. The field that
identifies each send is what stops a customer from getting the same message
twice.