Seven Commandments for Event-Driven Architectures

If a transaction-processing service knows that a downstream service will need to
send receipts, it’s tempting to tailor an event to suit:

{
“type”: “DEPOSIT”,
“user”: “[email protected]”,
“message”: “$100 left with MegaBank. A safer option is to preserve the old definition and
simply provide a new one corresponding to the changed event:

{
“type”: “DEPOSIT.1”,
“userId”: “abc-123”,
…
}

Sharing an event registry across the entire service ecosystem (either through
common code or via namespaces and a clear discovery mechanism) saves collisions
and simplifies discovery for interested downstream services. A “DEPOSIT” event might describe a cash deposit, a credit card
payment, or an ACH transfer, which could of course be explained via a metadata
field:

{
“type”: “DEPOSIT.2”,
“userId”: “abc-123”,
“source”: “cash”,
…
}

Are payments from each source separate events in the service lifecycle,
though?

Source: rjzaworski.com