[jayd16]

Data races can occur with fat events because fat events don't usually store a snapshot of the entire world. They're often actually delta events, forcing the consumer to rely on caching (a racey affair) or just fall back to hitting the API anyway.

If you're having issues with thin events causing data inconsistency then the answer should be better data representation in your core API. If you had to solve it by cramming perfectly stale but self consistent data into a fat event, a better solution would be to persist such data and make it queryable, no?

But of course any way can be made to work. Any extra bit of data can be appended to the event details. Any number of separate DB and persistent queues can be maintained and backed up like the business depends on it.

In my experience thin events are just less bug prone because they're more simple. You're not worrying about stale data floating around an event queue or a client cache. You're not guessing what data the consumer needs. Having the event consumer pull data is usually a trivial cost difference.

Fat events have their advantages but I put them under premature optimization and YAGNI.

[SideburnsOfDoom]

> fat events because fat events don't usually store a snapshot of the entire world. They're often actually delta events, forcing the consumer to rely on caching (a racey affair) or just fall back to hitting the API anyway.

I think you're saying "I don't like fat events because they're not really fat events", well, sorry that's your experience, I don't think that's a valid criticism of the actual thing at all, just of your poor experience of it.

> Data races can occur with fat events.. hitting the API anyway.

That happens with thin events as a matter of course, right? You stated that thin events are "lot less prone to data races" and now you're saying that they're the same? Where's the fat-event-specific issue that you alluded to? Citation not provided.

> Having the event consumer pull data is usually a trivial cost difference.

As I have stated twice before, it's a non-trivial _reliability_ difference, and that's the key.

[jayd16]

>That happens with thin events as a matter of course, right?

No. If you send no data, what is the race? You can structure an API where there are no races. If you concede to API access the API can provide any sort of historical data necessary. The issue is with incomplete event data and assumptions around what the state was when the event was sent.

>As I have stated twice before, it's a non-trivial _reliability_ difference, and that's the key

You can state it until you're blue but the advantage _is_ usually trivial or there would be no debate. It just doesn't bite that often.

I would say the buggy and prone to rot coupling of baked in event data is a bigger concern for most.

That said, I'm making an argument about what is the best bet for dev time and it sounds like you're making an argument about what is best given infinite developer resources, an unchanging APIs, and full knowledge of what data the consumer needs.

[SideburnsOfDoom]

> No. If you send no data, what is the race? You can structure an API where there are no races.

You seem to be saying that the race is a problem when comparing 2 copies of the same data (yes) and that this is an issue for fat events (no, and misses the entire point).

A vague thin event contains at minimum an event type and an item id, e.g. "SoemthingHappendedToAnOrder id:123456" which is _ahem_ two pieces of data that are sent. Events containing "no data" are not a thing, don't be absolute.

So there's potential for a race or inconsistency when you correlate that with a http api which might or might not have that order. You can't entirely get away from that.

> You can structure an API where there are no races.

I do not think that you understand "the fallacies of Distributed Systems"

https://www.simpleorientedarchitecture.com/8-fallacies-of-di...

> It just doesn't bite that often.

Has not been my experience.

> That said, I'm making an argument about what is the best bet for dev time

Sure, if you want to write as many bugs as possible as fast as possible, go ahead. (yes, I realise that this is mischaracterising hyperbole, but you did same by saying "infinite developer resources" etc above)