Thin events have the benefit of easy retry/resend logic. Depending on your message queue solution you might need to sometimes resend events.
If the event is 'user account changed', receiving it a few times too many causes only performance issues, but not correctness problems.
Sometimes this is the better tradeoff.
It is easier to send an event 'user account changed' than to analyze in detail what exactly changed, which also allows you to decouple the event logic from everything else.
Of course not every system benefits from such solutions, but sometimes simplicity wins.
assume the data format changes, it would change in the called api as well. as long as the fat event sends data that it's in the same format that the api would return, you'd have the same level of coupling. I think fat vs thin is more about how much other services the event have to travel, because thin event would multiply reads by a fair factor, with the tradeoff being the performance hit for the queue system to stor…
With an API you can publish a new endpoint (/v1, /v2 etc). It’s normally reasonably easy to maintain an old API even while you add features to the new API, and the runtime penalty is minimal because clients would be expected to call just one version of the API for any given event. (You can also see who’s calling the old API and ask them to change) But this is not true for events. If you change the body such that you…
API versioning is more for external users, not internal. if your api is versioned, your events should be versioned as well tho, so we're at square one, as in, you're manufacturing a scenario where one approach is advantageous, and I agree your approach works in that scenario, but that is different than saying that one approach is advantageous at priori
I‘d pick neither and just let the system in possession of data send with the event only the part of data it owns (i.e. something in between fat and thin). Saves API call back, the body doesn’t have to be fully deserialized, so no format coupling, the rest can be fetched from other services on demand (coherent state though is not guaranteed, but that’s usually not critical with well designed bounded contexts).
> just let the system in possession of data send with the event only the part of data it owns (i.e. something in between fat and thin).
I'm a fan of fat events, and let the receiver decide if they want to trust the event or not, or go ahead and make a call to the service to get the data.
for example:
if one receiver wants to know if you have read a book, then there is no reason to make a call to the service.
but if a service wants to know the last book you read, and doesn't trust the events to be in order, then it would make sense to just call the service.
> A's state to lag behind it's own events, Real systems don't have just 2 services. There can be 100s and the "own events" assumption may not hold.
Sure, but in a thin events model someone would "own" the events since otherwise the subscriber wouldn't know where to query the actual data. What would you even do with an event saying a customer changes address if querying that address then produces the old one. I'm genuinely curious how such an architecture would work. You don't have to respond directly here, but if you have any reference to further reading, I'd ap…
> I'm genuinely curious how such an architecture would work.
Complex systems are the way that they are because they got that way over time. It is not my goal to defend or even characterise a system that I did not create.
I am here telling you the issue that I saw: one event consumer, at an edge case, ran substantially behind another, and when they attempted to co-ordinate over http, this failed. And how it was successfully resolved: fatter events removed the need for co-ordination between these two altogether. This was IMHO a more elegant design - it avoided he issues of the the thin events.
> b) You're asking for occasional "eventual consistency" trouble when A's state lags or has moved on ahead of the event To be noted that this is the default if B is recovering after an outage. Personally, I consider events to be insane. "We create an immutable database so that the state of the system is always recoverable." Okay, cool, very functional programming of you. "But then to actually work with the event from…
The bit you seem to be missing is the events are the source of truth, not the databases. Lose your database? Roll up all the events. Got a lot of them? Take snapshots and then roll up from the last trusted snapshot. In true event sourced systems, the databases and stateful systems are artefacts that can be thrown away and rebuilt. The event log is the actual “true” database. Once you design around that, your objectio…
This only works if your events are in a single globally ordered stream or all your code is eventually consistent over every stream it consumes. Specifically, you cannot do the "query a service for the aggregate state" thing this article espouses for thin events, ever.
I'd settle for developers just making sure events were events that have happened and not action commands they want to happen. Nothing is worse than an event driven system polluted with action commands.
I agree in principle, but I also to need action commands when crossing boundaries in and out of the event system (e.g. to the user, or to an external provider.) Of course I still phrase them in the past tense:
I'm a fan of fat events, and let the receiver decide if they want to trust the event or not, or go ahead and make a call to the service to get the data. for example: if one receiver wants to know if you have read a book, then there is no reason to make a call to the service. but if a service wants to know the last book you read, and doesn't trust the events to be in order, then it would make sense to just call the se…
> if a service wants to know the last book you read, and doesn't trust the events to be in order, then it would make sense to just call the service.
It would make more sense to me if the events had an increasing sequence number, version number or accurate timestamp, so that if I record that "'sithlord' last read 'The Godfather' at event '123456'" I can record that, and ignore any event related to "sithlord last read" with event This is not a new problem, there are existing solutions to it.
I'd settle for developers just making sure events were events that have happened and not action commands they want to happen. Nothing is worse than an event driven system polluted with action commands.
I agree in principle, but I also to need action commands when crossing boundaries in and out of the event system (e.g. to the user, or to an external provider.) Of course I still phrase them in the past tense: PurchaseRequested { userId = ... } PaymentRequestSentToStripe { userId = ... } It really helps with debugging, especially if the user gets into some failed state (and the events tell you that they accidentally…
Of course you need command actions. All I'm asking is that you stop mixing them up with events.
Whether you're mixing or not is hard to tell if you're fudging the wording.
Whats the point of the payment request sent to stripe event? Does it trigger a stripe API request or is it emitted after an API request to stripe is made?