Join thousands of developers getting weekly updates to increase your understanding of software architecture and design. 🚀mailchi.mp/63c7a0b3ff38/codeopinion
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.
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.
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).
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.
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?
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.
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.
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. th-cam.com/video/anL-RGKz_Ak/w-d-xo.html
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
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.
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
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.
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).
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.
Depends on your usecase. If you dont need real-time access to changes in your system, you could get away with using CDC/ETL.
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?
@@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.
@varshard0 I didn't mean read user. I meant "reading someone's else database" and that's a design antipattern.
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.
Good timing on the hybrid sync/async approach anectode: I was looking for an answer on that. Thanks
Looking forward to the next video you teased already, would love to hear your advice on the topic of delivery timing.
Very interesting. Thank you. More examples would be great but look forward to more videos.
this channel is a gem🎉
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.
On 4:30 table is best, that I had seen about EDA. It's the essence
Good points, I always Sam Newman's claims in his book that Request Reaponse should not be used in microservices in his book.
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. th-cam.com/video/anL-RGKz_Ak/w-d-xo.html
Under Armour being secret sponsor of Derek's videos :D
that escalated quickly
Thanks!
Thank you!
The biggest drawback of your video is you are very speed and not clear
I... will... talk... slower? Oddly, I get other videos saying they enjoy it because they don't have to speed it up. Win some, lose some?
I always watch at 1.25x speed... 🤷♂️
You can go the other way and choose a slower speed. Look for the gear icon on the video.
He speak very clear IMO and im not even from USA, nor speaking english as my main language.. Add subtitles
Thanks!
No, thank you!