undefined | Better HN

0 pointsjayd163y ago0 comments

But it's a lot less prone to data races and other upsides so it really is contextual to your needs.

I would also push back that it has more moving parts. You'll often need to pull information and getting pushed information as well can duplicate code on both the service side and client. In practice thin events are easier to get right, despite the extra API requests.

I also think the cases where there's some kind of outage but it's an outage such that the information in the event is enough is fairly rare. I would guess it's more rare than outages that also disable event triggering anyhow.

0 comments

SideburnsOfDoom3y ago

> But it's a lot less prone to data races

What's the reasoning for that statement? My other comments have detailed cases of data races, caused by using thin events, solved by using fat events, so I'm going to push back on that: In my experience, the idea that thin events are "less prone to data races" has not been true at all, and that data race is inherent in the model of "receive an event, go back and get more data over http about it". How would you qualify this as "a lot" - how much is that lot? Citations very much needed.

> I would also push back that it has more moving parts. You'll often need to pull information

"Often" is not always. You seem to be saying that when you don't get the signature benefit of fat events (not having to pull information) ... there's no benefit. Yes, that's a tautology, and also an encouragement to further refine the design until you do get the benefit.

> I also think the cases where there's some kind of outage but it's an outage such that the information in the event is enough

Are you speaking from experience here? Doesn't seem like it. I refer you to point c) here https://news.ycombinator.com/item?id=33392655 It helps reliability to shorten the list of services that your service depends upon being 100% up and responsive.

jayd16OP3y ago

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.

SideburnsOfDoom3y ago

> 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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

SideburnsOfDoom3y ago

> But it's a lot less prone to data races

> I would also push back that it has more moving parts. You'll often need to pull information

> I also think the cases where there's some kind of outage but it's an outage such that the information in the event is enough

jayd16OP3y ago

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

SideburnsOfDoom3y ago

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

> 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.

1 more reply

j / k navigate · click thread line to collapse