Name the event "CustomerUpdate"
First, let's start with your event name. The purpose of the event is to describe what has already happened. This is different from a team that needs to issue instructions for something else.
Your event name "CustomerUpdate" sounds ambiguous in this regard, as it may describe something in the past or something in the future.
CustomerUpdated will be better, but even then, Updated is another ambiguous term and is not specific in a business context. Why was the client updated in this case? Is it because they changed their billing information? Moved home? Have they been upgraded from silver to gold? Events can be made as needed.
This may seem, in the first place, excessive, but the names of events become especially important as you remove data and context from the event payload, moving more to dark events ("option 3" from your question, which I will discuss below).
This does not mean that it is always useful to identify events at this level of detail, only that it is a path that is open to you at an early stage of the project, which can later pay dividends (or can lure you to thousands of types of events).
Returning to your actual question, let me take each of your options one at a time:
Name the event "CustomerUpdate" and include all information (updated or not) about the customer
Let this "template" convey the message Fat.
Bold messages represent the state of the described object at a given time with the entire context of the event present in the payload. They are interesting because the message itself is a contract between the service and the consumer. They can be used to transfer state changes between business domains, where it may be preferable that the entire event context be present when the consumer processes the messages.
Benefits:
- Self-consistency - can be completely consumed without knowledge of other systems.
- Ease of consumption (upsert).
Disadvantages:
- Brittle - the contract between the service and the consumer is connected with the message itself.
- It is easy to overwrite current data with old data if messages arrive in the wrong order.
- Large.
Name the event "CustomerUpdate" and include only information that is truly updated.
Allow this template to convey a Delta message.
Deltas are in many ways similar to bold messages, although they are generally more difficult to generate and consume. Since they are only a partial description of the event object, the delta also has a built-in “guess” that the consumer knows about the described event. For this reason, they may be less suitable for sending outside the business domain where the event object may not be well known.
Benefits:
- Smaller than bold messages
Disadvantages:
- Fragile - similar to Fat message, contract concluded in message.
- It is easy to overwrite current data with old data.
- Complex for generation and consumption
Name the event "CustomerUpdate" and specify the minimum information (Identifier) and / or URI to allow the consumer to receive information about this customer.
Let me call this post Skinny.
Skinny messages are different from other message templates that you defined, because the service / consumer contract is no longer explicit in the message, but it is understood that at some later point in time, the consumer will retrieve the event context. This separates the contract and messaging, which is good.
This may or may not lend itself well to internetworking of event domains, depending on how your enterprise is configured. Since the event payload is so small (usually only an identifier), there is no context other than the name of the event on which the consumer can base processing decisions; therefore, it becomes more important to make sure that the event is named appropriately, especially if there are several ways that a consumer might respond to a CustomerUpdated message.
In addition, it may not be good practice to include the actual address of the resource in these events - since events are things that have already occurred, event messages are usually unchangeable, and therefore any information in the event should be forever, if the events should be reproduced. In this case, the resource address can easily become obsolete and events will not be replayed.
Benefits:
- Disconnects the service contract from the message.
- Information about the event contained in the name of the event.
- Naturally idempotent (with time stamp).
- Usually tiny.
- Simple creation and consumption.
Disadvantages:
- The consumer must make an additional call to retrieve the context of events - requires explicit knowledge of other systems.
- The event context may become obsolete at the point where the consumer retrieves it, making this approach generally unsuitable for some real-time applications.
When creating an event, is the template most suitable?
I hope you already understood that the answer to this depends. I will stop here - yours - a great question, because you could probably write a book to answer it, but I hope you find this answer helpful.