Events for entity state changes

Question

When an entity is changed, I want to raise an event to notify potential consumers about the state changes. My question is, should I have

• an xxxChanged event for each attribute, or
• a single EntityChanged event that identifies which attributes changed?

Having more specific events seems better to me, as consumers can subscribe to only the relevant changes. The problem I run into is when I have consumers that care when any of a set of attributes change. I could have it consume AttributeAChanged and AttributeBChanged, but if both A and B change I really only need the consumer to run once.

I'm not sure if this is a problem with how I'm thinking about the events, or if I need a way on the consumer side to potentially consolidate triggers.

Answer 1

Both options are sub-optimal.

• In the first case, you are increasing the network traffic, which is usually pretty expensive in a microservice architecture, for many direct and indirect reasons.

• Second option is better, but only marginally so, because you are still sending useless traffic and triggering avoidable work.

Instead, a consumers should explicitly tell which attributes it is interested in.

(The subscription API could as well consolidate different entities (or even different events), enable buffering, merge consequent updates, prioritize consumers depending on load...)

Answer 2

but if both A and B change I really only need the consumer to run once

If the consumer needs to run once, then the change of these two fields counts, to the consumer, as one event.

An event is defined as a reason to take action. If you only need to take action once, then by definition there was only one event.

The problem I run into is when I have consumers that care when any of a set of attributes change.

It seems like you're trying to provide solutions for all possible consumer use cases you can think of that you might want to have in the future, rather than focusing on what concrete use cases you have before you now. That's rather impossible to answer, especially by internet strangers who have no clue about your business context.

If your approach is based on what the consumer needs (i.e. the consumer dictates requirements, you don't dictate to the consumer), then you simply have to see what it is your consumer needs, and use the system that is appropriate for their needs.
If instead you are the one dictating, (i.e. you build the system the way you want, and the consumer will deal with the API you create for them), then implement it however you see fit - you are dictating the system requirements after all.

Good tip: don't try to immediately write an all-encompassing solution, unless that is concretely asked of you. A Swiss Army knife has many solutions, but each individual solution is inferior compared to a specialized tool. The Swiss Army corkscrew is not as good as a dedicated corkscrew tool. The Swiss Army knife is not as strong as a dedicated knife. And so on.

Trying to write an all-encompassing solution often comes from not wanting to have to rewrite parts of your application. But rather than being averse to change (because the possibility of change is inevitable), rather try to minimize the impact of when you do have to change something.

This is the main goal of clean coding principles. If you stick to them, even though it may cost more effort in the short run, it will greatly simplify any change you have to make in the future. And because of that, when you practice clean coding, you won't need to be change-averse anymore, and therefore don't have to tackle the all-encompassing solution.