It would be great if you mentioned the cons of the architecture as well. For example it won't work well for stateful sequential applications. When you suggest using a DB trigger - please also mention that a trigger is not aware of the source of the changes. In general, it is not a good practice to use it for business logic, as let's say some maintaining operations _could_ trigger unexpected actions.
There is a missing "web" prefix in the caption. I mean event driven architecture for other platforms (like desktop apps) could be something similar (as the idea is the same), but building details are different.
@teena: for the first part, I was understanding..but in the second part, if you go little slow ( step by step approach) it would be more useful for the fresh learners like me.
In the scenario that the subscriber is down (or previous to the first time is up because it is a new service) how can it process all the events sent in the meantime? In the sample scenario, if the shipping service is down when the order service sends the order created event, it needs to process that event even if shipping has been down for a long time.
Hi, thanks for the presentation :) If you need save the Order in a relational database, would you do it before creating the event or as an event subscriber?
Hi Teena, I am struggling with one aspect of event driven architectures. If a process fails because of a business data issue (i.e. customer credit status not entered as an example) and want to rerun the process that failed caused by the event (perhaps other process could run) how is that managed. The only way I can see that working is to have a boolean flag that some other process or a user updates when the data condition is corrected and the event is activated but it would only be for certain processes. Not sure how event driven architectures handle this.
As mentioned in the presentation, consumers subscribe to completed events. Events can be "positive", like PaymentCompleted, or negative like PaimentFailed. So if something happened during a business process, it should be handled by a service responsible for retry/recovery (if recovery is possible). In a clean architecture, all events are one-way and if a feedback/result is needed, the sender should subscribe to a correspondent event (which in its turn will have information about initial event's result).
In this design, we handle dead letter events by setting up a dead letter queue/topic for events that fail processing. And then based on the eventId and other parameters, replay the events that are required by triggering an update in the original event stored in the event store (Azure CosmosDB) which would then retrigger the event handler to process the failed event.
@@TeenaIdnani awesome, this design would have solved so many problems that I encountered while processing of the failed events. Thank you so much for sharing.
@@TeenaIdnaniit's not him specifically that's facing the problem, the audio is like you constantly enter and exit a tunnel; a better mic for the future would be nice
Great session! I have one question. In this session you mentioned that event design is very important. I assume by event design you mean event modeling, How do you do event modeling? Do you write about how you do it in some blog or present it in some other video?
Great question! Event modeling and design is a crucial aspect when building effective event-driven integrations and architectures! It requires understanding consumers, mapping system state changes, creating expressive event types, building targeted payloads, and augmenting with descriptive context. I'm planning a full blog post to detail my process soon, Please stay tuned and let me know if any other event modeling questions!
Nice to see that IT people noticed that the world is mostly event driven and not service driven. I work in the industrial automation OT (Operation technology) and we know the world is event driven for more than 30 years. An industrial robot accepts commands and provides notifications. We do this with MQTT and Kafka. Even our Web application for process visualization does not use HTTP/REST web services, but is MQTT event driven with PAHO. Azure event hub is by far too complicated and does not fit our needs
It would be great if you mentioned the cons of the architecture as well. For example it won't work well for stateful sequential applications.
When you suggest using a DB trigger - please also mention that a trigger is not aware of the source of the changes. In general, it is not a good practice to use it for business logic, as let's say some maintaining operations _could_ trigger unexpected actions.
There is a missing "web" prefix in the caption. I mean event driven architecture for other platforms (like desktop apps) could be something similar (as the idea is the same), but building details are different.
Great stuff, Teena.
Your expertise is evident in your content. Keep it up!
Thank you
@teena: for the first part, I was understanding..but in the second part, if you go little slow ( step by step approach) it would be more useful for the fresh learners like me.
In the scenario that the subscriber is down (or previous to the first time is up because it is a new service) how can it process all the events sent in the meantime? In the sample scenario, if the shipping service is down when the order service sends the order created event, it needs to process that event even if shipping has been down for a long time.
Hi, thanks for the presentation :) If you need save the Order in a relational database, would you do it before creating the event or as an event subscriber?
as event subscriber - create Order --> Save Order??
Hey, Nice work. ✌
Thanks, There is a QR Code for the demo source code right at the end of the session. That has the github repo link.
Hi Teena, I am struggling with one aspect of event driven architectures. If a process fails because of a business data issue (i.e. customer credit status not entered as an example) and want to rerun the process that failed caused by the event (perhaps other process could run) how is that managed. The only way I can see that working is to have a boolean flag that some other process or a user updates when the data condition is corrected and the event is activated but it would only be for certain processes. Not sure how event driven architectures handle this.
As mentioned in the presentation, consumers subscribe to completed events. Events can be "positive", like PaymentCompleted, or negative like PaimentFailed. So if something happened during a business process, it should be handled by a service responsible for retry/recovery (if recovery is possible). In a clean architecture, all events are one-way and if a feedback/result is needed, the sender should subscribe to a correspondent event (which in its turn will have information about initial event's result).
Hey, great presentation. How would you handle the dead letter events in your design?
In this design, we handle dead letter events by setting up a dead letter queue/topic for events that fail processing. And then based on the eventId and other parameters, replay the events that are required by triggering an update in the original event stored in the event store (Azure CosmosDB) which would then retrigger the event handler to process the failed event.
@@TeenaIdnani awesome, this design would have solved so many problems that I encountered while processing of the failed events. Thank you so much for sharing.
Nice content, but very bad quality audio.
Oh! I am sorry that you are facing the audio issue
@@TeenaIdnaniit's not him specifically that's facing the problem, the audio is like you constantly enter and exit a tunnel; a better mic for the future would be nice
Great session! I have one question. In this session you mentioned that event design is very important. I assume by event design you mean event modeling,
How do you do event modeling? Do you write about how you do it in some blog or present it in some other video?
Great question! Event modeling and design is a crucial aspect when building effective event-driven integrations and architectures! It requires understanding consumers, mapping system state changes, creating expressive event types, building targeted payloads, and augmenting with descriptive context. I'm planning a full blog post to detail my process soon, Please stay tuned and let me know if any other event modeling questions!
Nice to see that IT people noticed that the world is mostly event driven and not service driven. I work in the industrial automation OT (Operation technology) and we know the world is event driven for more than 30 years. An industrial robot accepts commands and provides notifications.
We do this with MQTT and Kafka. Even our Web application for process visualization does not use HTTP/REST web services, but is MQTT event driven with PAHO. Azure event hub is by far too complicated and does not fit our needs