51–60 of 66 posts
1. You should be able to recreate the complete business state from the complete event sequence only. No reaching out to other servers/servies/DB’s to get data.
2. The events should be as small as possible. So only carry the minimum data needed to implement rule #1
That’s it. It works really well in practice.
Earlier quoted context omitted.
Yes, it happens. A way to deal with it is carrying some counter on the message metadata and incrementing it every time a consumer passes it along, so you can detect recursions. Another is having messages carry a unique id, and consumers record already seen messages.
Do you consider it a requirement for every message? Like, the problem sounds bad enough to warrant it. If not, now do you choose when to apply it? Our architects have a habit of ignoring these kind of issues and when you suggest making things like this a requirement they accuse you of excessive concern!
Earlier quoted context omitted.
There should be some law that says strictly serialized process should never be broken into discreet services. Distributed locks and transactions are hell.
> Distributed locks and transactions are hell. Which distributed transaction scenario have you ever dealt with that wasn't correctly handled by a two-phase commit or at worst a three-phase commit?
Earlier quoted context omitted.
The best way to avoid distributed locks and transactions is to manually do the work. For example, instead of doing a distributed lock on two accounts when transferring funds, you might do this (which is the same as a distributed transaction, without the lock): 1. take money from account A 2. if failed, put money back into account A 3. put money into account B 4. if failed, put money back into account A In other words…
Here's how you can do this. You have 3 accounts: A, B and in-flight. 1. Debit A, Credit in-flight. 2. Credit B, Debit in-flight. If 1. fails, nothing happened and everything is consistent. If 2. fails, you know (because you have money left on in-flight), and you can retry later, or refund A. This way at no point your total balance decreases, so everything is always consistent.
This isn't an easy-to-solve problem when it comes to distributed computing.
Thank you for this well-written, well-reasoned, and thoroughly enjoyable article! Yet I am troubled by it, and must disagree with some of the premises and conclusions. Only you know your specific constraints, so my 'armchair architecting' may be way off target. If so, I apologize, but I was particularly disturbed by this statement: "events that travel between services have a dual role: They trigger actions and carry…
> Yes, sort of, but mostly no. Events do not "trigger" anything. The recipient of an event may perform an action in response to the event, but events cannot know how they will be used or by whom.
I don't see the difference. Maybe it's a language thing. But I'd say if a recipient receives an event and perfoms an action as consequence, it's fair to say the event triggered the action. The fact that the event triggers something doesn't mean the event or the publisher must know at runtime what's being triggered.
Regarding your suggestions, I think your proving my point. Of course the whole "there are two types of.." is a generalization, but given that, you seem to fall in the first category, the one I called "DDD engineer/architect".
My response to the first three would be: Why? I know some literature suggests this. I've applied this pattern in the past. And I wrote "This is totally legitimate and will work.". But we also need to ask ourselves: What's the actual value? Why does the kind of event / the business reason have to be encoded as the name/type of the event? Honest question. Doesn't having it in the event payload carry the same information, just in a different place?
I don't want to be following what might be seen as "best practices" just for the sake of it, without understanding why.
I know of a few systems that started of with domain events that were named & typed "properly" according to the business event. And after a while, the need for wide events carrying the full state of the source entity arose. If you look at talks and articles from other EDA practioners (e.g. the ones on https://github.com/lutzh/awesome-event-driven-architecture#r...), you'll see that's not uncommon. This regularly leads to having to provide the wide events in addition to the "short" events. This is extra effort and has its own drawbacks. I just want to save the readers the extra work.
Well put! We do a lot of event driven architecture with ActiveMQ. We try to stick messaging-as-signalling rather than messaing-as-data-transfer. These are the terms we came up with, I'm sure Martin Fowler or someone else has described it better! So we have SystemA that is completing some processing of something. It's going to toss a message onto a queue that SystemB is listening on. We use an XA to make sure the data…
So... you're not using event-driven architecture. That's fine, but I don't know why it supports this article's weird point about event-driven architecture.
I've never used EDA, just read about it, so I'm curious what you disagree with from the article.
It seems that the logic is reasonable, that subscribers have varying needs and publishers would need to account for those needs over time as the functionality (and data) required by subscribers evolves.
The triggering of the action is a direct consequence of the information an event contains. Whether or not an action is triggered should not be the responsibility of the event. If you are writing events with the intention of having them invoke some specific actions, then you should prefer to invoke those things directly. You should be describing a space of things that have occurred, not commands to be carried out. By…
> each consumer can perform their own targeted lookups as needed that puts you into tricky race condition territory, the data targeted by an event might have changed (or be deleted) between the time it was emitted and the time you're processing it. It's not always a problem, but you have to analyse if it could be every time. It also means that you're losing information on what this event actually represents: looking…
Also, CAP is a thing too.
Sure, try to keep transactions single-node. If you can't let me give you the advice of people FAR smarter than I:
- DO NOT DESIGN YOUR OWN DISTRIBUTED TRANSACTION SERVICE
Use a vetted one.
Earlier quoted context omitted.
Here's how you can do this. You have 3 accounts: A, B and in-flight. 1. Debit A, Credit in-flight. 2. Credit B, Debit in-flight. If 1. fails, nothing happened and everything is consistent. If 2. fails, you know (because you have money left on in-flight), and you can retry later, or refund A. This way at no point your total balance decreases, so everything is always consistent.
It can fail at your commas in 1&2, then you are just as broke as everyone else. This isn't an easy-to-solve problem when it comes to distributed computing.
The important thing is not having money go missing.
Earlier quoted context omitted.
It can fail at your commas in 1&2, then you are just as broke as everyone else. This isn't an easy-to-solve problem when it comes to distributed computing.
It should be an atomic transaction, double-entry style, so it can’t fail between commas. The important thing is not having money go missing.