Events: Fat or Thin?
codesimple.blog
Events: Fat or Thin?
1–10 of 61 posts
Re: Events: Fat or Thin?
#2Why not have an option for both? Both have their use cases.
Re: Events: Fat or Thin?
#3> Thin Events add coupling
That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified.
So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’t care about the body of the object?
So I’m on team thin. Every time I’ve been tempted by the other team, I’ve regretted it. It’s also in my experience a lot more difficult to version events than it is to version APIs, so reducing their surface area also solves other problems.
Re: Events: Fat or Thin?
#4> Thin Events add coupling That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified. So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’…
> thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API.
You make a statement in the first sentence, and in the next sentence produce evidence ... that the statement is wrong. And, YMMV.
It is my experience that thin events add coupling. If service B receives an event, and wants to process it ASAP (i.e. near real time) and so calls back over http to Service A for the details, then
a) there is additional latency for a http call. And time variance - Even if the average latency of a http request round-trip is fine, the P99 might be bad.
b) You're asking for occasional "eventual consistency" trouble when A's state lags or has moved on ahead of the event
c) Worst of all: When service A is down or unreachable, Service B is unable to do work: Service B uptime must be I don't believe that it's accurate to say "receivers are also free to call or not call..." it's not choosing a flavor of ice-cream, you do the calls that the work at hand _needs_.
If you find that you never need to call back to service A then yes, "thin events" would suit your case better. That has not been my experience.
It's fair that event data format versioning is a lot of work with fat events - nothing is without downside. But in your case, do you have "dependency on the event body" ? All of it? If a thin event is all that you need, then you depend on a couple of ids in the event body, and not the rest. Json reading is very forgiving of added / removed fields, you can ignore the parts of a fat event that you don't care about.
Re: Events: Fat or Thin?
#5Delta events sounds an awful lot like Change Data Capture.
Re: Events: Fat or Thin?
#6> Thin Events add coupling That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified. So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’…
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 store and ship large events
Re: Events: Fat or Thin?
#7> Thin Events add coupling That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified. So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’…
> thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. You make a statement in the first sentence, and in the next sentence produce evidence ... that the statement is wrong. And, YMMV. It is my experience that thin events add coupling. If service B receives an event, and wants to process it ASAP (i.e. near real time) and so calls back over http to Service A for the…
> 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 immutable database, you have to query a stateful service." ??? What? And even fat events only go so far to get you out of that. So with a stream of n events, you don't have n states that the application can be in, but n times the product of all possible states of every other service that you query. How does this help?!
Re: Events: Fat or Thin?
#8> Thin Events add coupling That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified. So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’…
> thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. You make a statement in the first sentence, and in the next sentence produce evidence ... that the statement is wrong. And, YMMV. It is my experience that thin events add coupling. If service B receives an event, and wants to process it ASAP (i.e. near real time) and so calls back over http to Service A for the…
> You make a statement in the first sentence, and in the next sentence produce evidence ... that the statement is wrong.
My first sentence was quoting from the article, then I refute the article. Sorry if that wasn’t clear.
Re your point a), yes I agree in this case you’d send the contents in the body, but then I’d tend to call it stream processing rather than event processing - I admit this might seem like splitting hairs, but I do feel that there’s a difference between events and data distribution. And I personally find the data distribution pattern tends to be a lot more specialised.
Re b), 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.
Re c), again, it’s an assumption that the receiver needs the exact data provided in the event body; but I’ve found that, except in very simple cases, it’s very difficult to efficiently create event bodies that contain everything that all receivers are going to need. Maybe the receiver needs to collate a bunch more data, in which case the problem persists regardless of fat or thin, or maybe it just clears a local cache, in which case the problem is deferred until the data is needed and you probably have other things to worry about then anyway.
> I don't believe that it's accurate to say "receivers are also free to call or not call..." it's not choosing a flavor of ice-cream, you do the calls that the work at hand _needs_.
Sure, and the calls you make depend on the context, and if there is enough data in the event body to avoid making any calls at all. And I’m saying that in my experience that’s not generally the case. What I’ve seen is that the sender composes some event body and sends it, and the receivers end up needing to call APIs anyway.
In which case, the sender may as well have not gone to the trouble, hence my preference for thin events.
> But in your case, do you have "dependency on the event body" ? All of it?
From a maintenance perspective, the sender doesn’t know what the receivers depend on, so even if all your receivers only depend on the IDs, there is no way to find out. Because of this, it’s really easy to add fields to an event message, but really dangerous to remove them, because you can’t easily tell what receivers depend on the thing you’re removing. This is why I said that fat events create more coupling than thin events.
Of course as with most things there are always exceptions. Maybe I should have said, “I’m on team thin by default. But of course some use cases require fat messages, in which case proceed with great care”.
Re: Events: Fat or Thin?
#9Delta events sounds an awful lot like Change Data Capture.
It seems rare that every operation in a business is atomic across a single aggregate, so I’ve always been wary of events that are pure CRUD, whatever you choose to call them.
Re: Events: Fat or Thin?
#10> Thin Events add coupling That’s not my experience. In fact I’d say fat events add coupling because they create an invisible (from the emitter) dependency on the event body, which becomes ossified. So I’d say the opposite: thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. But receivers are also free to call or not call any other API they want. What if they don’…
> thin events reduce coupling. Sure, the receiver might call an API and that creates coupling with the API. You make a statement in the first sentence, and in the next sentence produce evidence ... that the statement is wrong. And, YMMV. It is my experience that thin events add coupling. If service B receives an event, and wants to process it ASAP (i.e. near real time) and so calls back over http to Service A for the…
b) You're asking for occasional "eventual consistency" trouble when A's state lags or has moved on ahead of the event
If you allow A's state to lag behind it's own events, then how are you ever going to create a sane system? Surely A either has to be ahead or at the state that caused the event to emit, or events are pointless.