Game servers do not work like this. The main server contains all the game logic and needs to be very fast. It does not go through any broker; instead, it sends data directly to the clients through an open socket.
1. 10:00 How can order-service forget about purchase when it is possible that while the payment was processed the product's balance dropped to 0 (zero)? 2. how to handle the case when inventory-service processes the event but fails to send the ACK message? 3. does the broker has to ACK back the ACK message? If yes, what if inventory-service fails to receive it? 4. event sourcing doesn't cause eventual consistency, but event driven architecture. 5. so how CQRS helps with the two DBs? 6. in reality our systems are hybrid depending on the communication scenario. as in, some services may opt for messages, some for sync communication.
Thanks for your questions, I will try to answer them 🙂 1. If the payment fails, no event will be emitted. But once it is emitted, the service forgets it. That's what was meant by "forgetting". 2. You have multiple strategies depending on your use case and needs: a. Retry Mechanism: Implement a retry mechanism in your microservice. If the database operation fails, the service can try again after a certain period. b. Dead Letter Queue: If the error persists after several retries, you can send the message to a Dead Letter Queue (DLQ). The DLQ stores messages that could not be processed successfully. You can later analyze these messages and decide how to handle them. c.Event Sourcing: If a failure occurs, you can replay the events to bring your application back to a consistent state. d. Compensating Transactions: If your operation has side effects, you might need to execute a compensating transaction to undo the changes in case of failures. 3. No, the broker doesn't have to ACK back. It's more of a "fire and forget" pattern, meaning the event publisher usually doesn't wait for an ACK. 4. Agree :) 5. It doesn't. 6. Exactly.
Awesome video. Your content is teaching me a ton, and it all makes sense when I listen to your content over some others here on YT. I did have a question In the payment processing example, when the client is making the request to make an order, if the payment service succeeds and therefore the order service can update the orders for the user, wouldn't the user simply be moved on to the success screen irregardless of what happens down stream (inventory service update, email service etc.) ? I would assume from the clients perspective, they should not be at the mercy of the rest of the systems processing and should only care about if the payment was processed and their money was taken out or not.
Thanks a lot! And yes, that's totally true. As long as the payment succeeds, the user can be forwarded to the success screen. My diagram should've reflected that 🙂
Newbie here: If RabbitMQ does not know about what services are subscribing, and lets say that inventory service returns ACK, but e-mail service has not gotten to process the payment_succeeded event yet, what happens? It sounds like the ACK deletes the event from the queue, and if there is no payment_succeeded event present, then email service wouldn't know about it
Great work....can you please cover. RabbitMq in a separate video. May be conceptualize it as a class object . So that we can have publisher and consumer as 2 member methods of the same instance of rabbitmq client. Was wondering if we can have a separate worker thread for consuming the event.
Events can be replayed at any point of time in case of failure , also every message broker has solution for transient failure where failed msgs are stored to process later
> what are the disadvantages of high-decoupling? basically you have to think and stop being a code monkey, which is an excellent thing use to tracing tool and you will be good
Decent high level introduction but I think the event sourcing here is not clear here. Event sourcing events should never be exposed directly to the other (microservice) service just like the db. A lot of people make the mistake that event source events should be published as regular events.
I don't think event sourcing and cqrs have anything to do with EDA at all, they are individual patterns that can be used without any of the other patterns
Hi, One suggestion , please give some gap between each topics. since you are speaking continuously couldn't get it clearly and am beginner in this topic so finding difficult to understand. I felt your voice bit low. Thanks,
Game servers do not work like this. The main server contains all the game logic and needs to be very fast. It does not go through any broker; instead, it sends data directly to the clients through an open socket.
That's a great point! My example with a game server is totally off, you're right 🙂
I'd love to see you digging deeper into rabbitmq with real world examples!
This is the first time I learned about the basic of Event driven and Event sourcing
love the content... well explained and straight to the point!
1. 10:00 How can order-service forget about purchase when it is possible that while the payment was processed the product's balance dropped to 0 (zero)?
2. how to handle the case when inventory-service processes the event but fails to send the ACK message?
3. does the broker has to ACK back the ACK message? If yes, what if inventory-service fails to receive it?
4. event sourcing doesn't cause eventual consistency, but event driven architecture.
5. so how CQRS helps with the two DBs?
6. in reality our systems are hybrid depending on the communication scenario. as in, some services may opt for messages, some for sync communication.
Thanks for your questions, I will try to answer them 🙂
1. If the payment fails, no event will be emitted. But once it is emitted, the service forgets it. That's what was meant by "forgetting".
2. You have multiple strategies depending on your use case and needs:
a. Retry Mechanism: Implement a retry mechanism in your microservice. If the database operation fails, the service can try again after a certain period.
b. Dead Letter Queue: If the error persists after several retries, you can send the message to a Dead Letter Queue (DLQ). The DLQ stores messages that could not be processed successfully. You can later analyze these messages and decide how to handle them.
c.Event Sourcing: If a failure occurs, you can replay the events to bring your application back to a consistent state.
d. Compensating Transactions: If your operation has side effects, you might need to execute a compensating transaction to undo the changes in case of failures.
3. No, the broker doesn't have to ACK back. It's more of a "fire and forget" pattern, meaning the event publisher usually doesn't wait for an ACK.
4. Agree :)
5. It doesn't.
6. Exactly.
Hey, love this content. Please keep it up!
Thank you!
Awesome video. Your content is teaching me a ton, and it all makes sense when I listen to your content over some others here on YT.
I did have a question
In the payment processing example, when the client is making the request to make an order, if the payment service succeeds and therefore the order service can update the orders for the user, wouldn't the user simply be moved on to the success screen irregardless of what happens down stream (inventory service update, email service etc.) ?
I would assume from the clients perspective, they should not be at the mercy of the rest of the systems processing and should only care about if the payment was processed and their money was taken out or not.
Thanks a lot! And yes, that's totally true. As long as the payment succeeds, the user can be forwarded to the success screen. My diagram should've reflected that 🙂
Newbie here:
If RabbitMQ does not know about what services are subscribing, and lets say that inventory service returns ACK, but e-mail service has not gotten to process the payment_succeeded event yet, what happens?
It sounds like the ACK deletes the event from the queue, and if there is no payment_succeeded event present, then email service wouldn't know about it
Great work....can you please cover. RabbitMq in a separate video. May be conceptualize it as a class object . So that we can have publisher and consumer as 2 member methods of the same instance of rabbitmq client.
Was wondering if we can have a separate worker thread for consuming the event.
I'll cover that in a separate video soon!
Thanks for the video. This is all theory but pls implement it
Will do in one of the next videos 🤙
I wonder if InventoryService processes fails, but EmailService sends email successfully, how should we gonna do ?
Events can be replayed at any point of time in case of failure , also every message broker has solution for transient failure where failed msgs are stored to process later
> what are the disadvantages of high-decoupling?
basically you have to think and stop being a code monkey, which is an excellent thing
use to tracing tool and you will be good
Anyone has an idea on how to handle duplicates in an async context ?
RABBITMQ deep dive please
Can you please implement all that stuff it would be too helpful
I can! Just stay tuned 😊
@@SoftwareDeveloperDiaries great will wait for it.
@@SoftwareDeveloperDiariesHey that's awesome brother 🔥. Would like to see a payment integration using event driven architecture ❤.
Thanks for such a good knowledge make some practical or reference some git repo
Decent high level introduction but I think the event sourcing here is not clear here. Event sourcing events should never be exposed directly to the other (microservice) service just like the db. A lot of people make the mistake that event source events should be published as regular events.
I don't think event sourcing and cqrs have anything to do with EDA at all, they are individual patterns that can be used without any of the other patterns
Indeed, they are individual patterns. But EDA often relies on those :)
Hi,
One suggestion , please give some gap between each topics. since you are speaking continuously couldn't get it clearly and am beginner in this topic so finding difficult to understand. I felt your voice bit low.
Thanks,