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.
@SoftwareDeveloperDiaries3 ай бұрын
That's a great point! My example with a game server is totally off, you're right 🙂
@juliocesarvieirasantos32193 ай бұрын
I'd love to see you digging deeper into rabbitmq with real world examples!
@whoami27438 ай бұрын
This is the first time I learned about the basic of Event driven and Event sourcing
@Aleks-fp1kq8 ай бұрын
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.
@SoftwareDeveloperDiaries8 ай бұрын
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.
@hexomega94455 ай бұрын
love the content... well explained and straight to the point!
@jackfilleyreviews68447 ай бұрын
Hey, love this content. Please keep it up!
@kevinstampe3 ай бұрын
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
@TannerBarcelos8 ай бұрын
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.
@SoftwareDeveloperDiaries8 ай бұрын
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 🙂
@AmarMishra8 ай бұрын
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.
@SoftwareDeveloperDiaries8 ай бұрын
I'll cover that in a separate video soon!
@dranon0o5 ай бұрын
> 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
@abhilashkr11758 ай бұрын
Thanks for the video. This is all theory but pls implement it
@SoftwareDeveloperDiaries8 ай бұрын
Will do in one of the next videos 🤙
@elmehdimarjane8 ай бұрын
Anyone has an idea on how to handle duplicates in an async context ?
@alienmars24426 ай бұрын
I wonder if InventoryService processes fails, but EmailService sends email successfully, how should we gonna do ?
@mithunbobade16 ай бұрын
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
@raphauy8 ай бұрын
Thank you!
@sauravkumarsharma68128 ай бұрын
Thanks for such a good knowledge make some practical or reference some git repo
@prashlovessamosa8 ай бұрын
Can you please implement all that stuff it would be too helpful
@SoftwareDeveloperDiaries8 ай бұрын
I can! Just stay tuned 😊
@prashlovessamosa8 ай бұрын
@@SoftwareDeveloperDiaries great will wait for it.
@emperoralthaf62648 ай бұрын
@@SoftwareDeveloperDiariesHey that's awesome brother 🔥. Would like to see a payment integration using event driven architecture ❤.
@dikatok8 ай бұрын
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
@SoftwareDeveloperDiaries8 ай бұрын
Indeed, they are individual patterns. But EDA often relies on those :)
@SureddiBhargav7 ай бұрын
RABBITMQ deep dive please
@dinov53475 ай бұрын
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.
@bhuvaneshwariselvaraj95886 күн бұрын
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,