Beware! Anti-patterns in Event-Driven Architecture

Рет қаралды 14,924

Күн бұрын

Пікірлер: 30

@CodeOpinion 11 ай бұрын

Join thousands of developers getting weekly updates to increase your understanding of software architecture and design. 🚀mailchi.mp/63c7a0b3ff38/codeopinion

@AndresPineros-k9t 9 ай бұрын

What do you think about this? I was told that 2 services (service A & B) could talk to each other via async and sync ways depending on the user story. It feels as if we need to decide between the two, but this take of having both even for communications between the same two services seems interesting. Async via event-driven and sync via API Gateway. What do you think? Probably an anti-pattern, but I've never seen people talk about this.

@nighma 11 ай бұрын

Event pattern is a tool amongst others. I say it often to people : Not everything is a nail, you have to use the right tool in the right situation

@rickardoberg 11 ай бұрын

We do “all of the above” with the event design. It’s metadata+[domainevent], and metadata contains name of what command caused it. Each domain event contains EventName+Created/Updated/Deleted+entityid+attribute/relationship changes. Each event covers a single domain concept, which may be one or more attributes/relationships, depending on what makes sense. With this design different types of subscribers can use different parts of it. Read models use primarily the data changes in the domain events. Integrations with external systems can use data changes plus event names. Analytics or triggers can use the command name in metadata (e.g. “count Signup commands for this month”). There really is no need to design events for “this or that” when you can do “this and that”. IMO.

@sliderhouserules 11 ай бұрын

I'd love more videos on Event Driven Architecture. We're about to rework our whole system and people are wanting to use events for data distribution, or Event Sourcing - which is worse - for our system. I am working things out to have another option for us (which is CDC / ETL or whatever, and then events where they make sense).

@marcom. 11 ай бұрын

CDC like Debezium is in fact using events for data distribution. But there's nothing bad with it per se, it depends on the reason why you're doing it. Same for Event Sourcing: Can be a really nice solution for the right problem - but in many cases it's too complex to handle.

@ashb001 11 ай бұрын

Depends on your usecase. If you dont need real-time access to changes in your system, you could get away with using CDC/ETL.

@seNick7 11 ай бұрын

For me CDC is like a hack. It's like a direct read.of someone's else database but with invented relationship. But the problems stay the same. If you ignore these problems, just make a readonly connection to other service's database. Sounds scary?

@varshard0 11 ай бұрын

@@seNick7 I don't think a read only user can replace CDC. ie: a dependent service needs to update its cache when there's an insert/update event.

@seNick7 11 ай бұрын

@varshard0 I didn't mean read user. I meant "reading someone's else database" and that's a design antipattern.

@amirparcheko1 9 ай бұрын

Great stuff Dreke! I really like you bringing up sinilar topics. It would like to hear from you talking a little more in detail or concrete exanples of these anti patterns.

@VijayJayaram-yr7pn 11 ай бұрын

this channel is a gem🎉

@DeWhiskeys 11 ай бұрын

Good timing on the hybrid sync/async approach anectode: I was looking for an answer on that. Thanks

@allinvanguard 11 ай бұрын

Looking forward to the next video you teased already, would love to hear your advice on the topic of delivery timing.

@jameskim4274 11 ай бұрын

On 4:30 table is best, that I had seen about EDA. It's the essence

@arto00-g2n 9 ай бұрын

Very interesting. Thank you. More examples would be great but look forward to more videos.

@christianhartmann9662 11 ай бұрын

Thanks!

@CodeOpinion 11 ай бұрын

No, thank you!

@antoniusgolly3417 11 ай бұрын

This topic is important and I would like to get more out of your experience. Unfortunately, there is often an "it depends" making it hard to extraxt advice, thus far. I think a series on "When are Events used in an Anti-pattern" would benefit from real Examples, discussing pros and cons.

@yonatandaniyel5640 11 ай бұрын

Good points, I always Sam Newman's claims in his book that Request Reaponse should not be used in microservices in his book.

@CodeOpinion 11 ай бұрын

I agree with that statement (generally). Synchronous request/response between service boundaries can unfold into a nightmare. The question is why do you need data from another service boundary? That's the question to dive deeper on. I cover that more in this video. kzbin.info/www/bejne/l5-vXoV9gN-Sd80