In addition, duplication may happen even from the system design of the broker as it requires to be highly available. Moreover, a replication strategy between data held among shards is required to be implemented, leading into duplication of messages regardless our acknowledgment mechanism.
@redouane56262 жыл бұрын
Your videos are concise and contain tons of information, Thanks!
@CodeOpinion2 жыл бұрын
Thanks!
@rodrigoalves85547 ай бұрын
Congratulations for the high level of your channel! Great content! Best Regards
@shahrazkl2 жыл бұрын
Another great topic and great video! Thank you!
@CodeOpinion2 жыл бұрын
Glad you enjoyed it!
@sanjevsaalaivazan77862 жыл бұрын
Thanks a Ton, Will try to send more often.
@CodeOpinion2 жыл бұрын
Thank you! I really appreciate that!
@brightshadow948010 ай бұрын
Tip: don't use a full white background. Those with HDR monitors thank you.
@gokera.99352 жыл бұрын
Nice one, thanks.
@hrtummala2 жыл бұрын
Gotcha🙂, question on DLQ ..if your consumer is calling I/O service to make state changes then there is always a great chance that newer message gets successful than the old message in DLQ. How do we handle this ?
@CodeOpinion2 жыл бұрын
Depends what your consumer is doing. This one is hard to explain via a comment and I should probably create a video about ordering and expectations. The short answer is don't create event consumers that try and use event state to maintain some type of their own state. Expect to consume out of order.
@hrtummala2 жыл бұрын
@@CodeOpinion thank you. Will look forward for the video.
@aleksg29252 жыл бұрын
Love your videos! At 4:30 state update and message sending is in two separate transactions. I know you're familiar with the outbox pattern (you have a brilliant video about it) - dont you think these two operations _always_ need to be done in one transaction? If not, you have 'at most once delivery'. You wont even have eventual consistency - in a large production system you're basically guaranteed inconsistency?
@CodeOpinion2 жыл бұрын
Correct, if you aren't using the outbox pattern then you could fail to publish the event to the broker but still have saved state. If you are using the outbox pattern, then you can also introduce publishing duplicate messages if the publish occurs to the broker, but fails to remove from the outbox.
@aleksg29252 жыл бұрын
@@CodeOpinion Thanks for your answer! Indeed, though duplicate messages seems like a much better problem to have 😄
@Greenthum62 жыл бұрын
You make pizza delivery sound pretty difficult:) Anyways, great info on the topic again!
@CodeOpinion2 жыл бұрын
Thanks! 😃
@nieve49392 жыл бұрын
Regarding handling failures- you're suggesting retrials might have an impact on the overall processing times of other messages by the consumer. But, aren't there buses and brokers that will reintroduce the failed message into the back of the queue, so that other messages will be handled before the failed one will get the retry? In some cases you get this by default, no?
@CodeOpinion2 жыл бұрын
At the end I'm suggesting each individual http call to the external service be driven by an individual message in a queue. In that case it will not have an impact on any other work. How it was implemented in the example would have an impact because all the http calls were made within the same process. If one causes an exception is would fail the message. If it was retried, it would end up making duplicate calls that could have worked the first time.
@kenjohnsiosan97072 жыл бұрын
I really love watching your videos so far. but as a beginner like me where I could possibly start implementing this kind of pattern. Do you have sample projects for references.. appreciate some advise. thank you sir. ☺️
@CodeOpinion2 жыл бұрын
I'm working on something more complete that involves a lot of the concepts I talk about in these videos. Stay tuned!
@idan53232 жыл бұрын
Hey Derek, nice video! I have a question: What do you think about the design of the Blazor Hero template? I would love to hear your opinion about that
@CodeOpinion2 жыл бұрын
I'll take a look. Can't say I've looked at Blazor too much really.
@idan53232 жыл бұрын
@@CodeOpinion Well I actually think blazor is great. I was a bit skeptic at the beginning, but I found out that you can build good looking apps with little effort and almost no js. The performence is pretty good aswell. There are improvements to be made, like better hot reload, but as of now I think it is totally production ready and a real game changer
@Nekroido2 жыл бұрын
Thanks!
@CodeOpinion2 жыл бұрын
Welcome!
@EverydayRoadster2 жыл бұрын
The topic of your talk really is messaging, not eventing.