[echelon]

There's a third type of event:

- Entire Object.

You send the entire state of the entire object that changed. Irrelevant fields and all.

This makes business logic and migrations easier in dependent services. You can easily roll back to earlier points in time without diffing objects to determine what state changed. You don't have to replay an entire history of events to repopulate caches and databases. You can even send "synthetic" events to reset the state of everything that is listening from a central point of control.

I've dealt with all three types of system, and this is by far the easiest one to work with.

[SideburnsOfDoom]

How does this differ from a "fat event" ?

[echelon]

Thin event (1): person object XYZ changed.

Thin event (2): address object ABC changed.

Delta event (1): person object XYZ's name changed to "Bob"

Delta event (2): address object ABC's address line 2 was deleted and zip code was changed to "12345"

Fat event (1): person object XYZ changed, and here's everything we think person-consuming systems will care about

Fat event (2): address object ABC changed, and here's everything we think address-consuming systems will need

Entire object (1): { person: { token: "XYZ", name: "Bob", email: "[e-mail]" age: 42, likes: ["ice cream", ...], ... }, updated_at: T, updated_by: U, version: 3, ... }

Entire object (2): { address: { token: "ABC", line_1: "1234 Some Place Rd.", line_2: null, city: "Everywhere", state: "NA", zip: "12345", ... }, updated_at: T, updated_by: U, version: 5, ... }

[SideburnsOfDoom]

since the "fat event" ones are vaguely defined here, they could be arbitrarily close to or far from the "Entire object" cases. How does it differ? Maybe it does not.

[echelon]

Your team decides what parts of the model to expose in its events and it becomes an API in its own right.

You might change the names of fields, move them to places that don't reflect where they live on a nested model, etc. It requires a lot more thought and maintenance.

That isn't to say the choice can't be correct. All of these approaches have pros and cons.