| I think it's a straw man to say "we couldn't eliminate all API calls, so fat events are useless" - even removing 1 dependency at a time is a win. In my experience, you generally can do this, and that was the approach taken for reliability improvement. > it’s very difficult to efficiently create event bodies that contain everything that all receivers are going to need. "everything that all receivers need" seems like another straw man, a "you won't get it perfect so don't try to improve". I've seen it work well enough to be worthwhile. > From a maintenance perspective, the sender doesn’t know what the receivers depend on At a glance, no. But it's not imponderable, assuming a limited number of in-house consumers. The absolute statement about it isn't accurate. > it’s just an assumption that the receiver needs the version of data in the message, rather than the latest version. So I don’t think this is a strong argument for fat events. I've seen it cause a severe and hard-to-diagnose failure, when system A lags enough, so I think it is a strong argument. > Maybe I should have said, “I’m on team thin by default. Sure. I'm on team "fat events" by default because it can solve more issues than it creates. If it turns out that 90% of the event gets ignored, with no issues or http call-backs, then this might be a case for thin events. |
Well, yes it is a straw man, because I never said that.
> At a glance, no. But it's not imponderable, assuming a limited number of in-house consumers. The absolute statement about it isn't accurate.
That’s a pretty huge assumption. Especially when one of the advantages of pub/sub is supposed to be decoupling.
Anyway, we clearly have had different experiences, and there is no silver bullet.