A Beginner's Guide to Event-Driven Architecture

  Рет қаралды 22,833

Software Developer Diaries

Software Developer Diaries

Күн бұрын

Пікірлер: 30
@whiletrue1-wb6xf
@whiletrue1-wb6xf 4 ай бұрын
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.
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 3 ай бұрын
That's a great point! My example with a game server is totally off, you're right 🙂
@juliocesarvieirasantos3219
@juliocesarvieirasantos3219 3 ай бұрын
I'd love to see you digging deeper into rabbitmq with real world examples!
@whoami2743
@whoami2743 8 ай бұрын
This is the first time I learned about the basic of Event driven and Event sourcing
@Aleks-fp1kq
@Aleks-fp1kq 8 ай бұрын
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.
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
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.
@hexomega9445
@hexomega9445 5 ай бұрын
love the content... well explained and straight to the point!
@jackfilleyreviews6844
@jackfilleyreviews6844 7 ай бұрын
Hey, love this content. Please keep it up!
@kevinstampe
@kevinstampe 3 ай бұрын
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
@TannerBarcelos
@TannerBarcelos 8 ай бұрын
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.
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
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 🙂
@AmarMishra
@AmarMishra 8 ай бұрын
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.
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
I'll cover that in a separate video soon!
@dranon0o
@dranon0o 5 ай бұрын
> 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
@abhilashkr1175
@abhilashkr1175 8 ай бұрын
Thanks for the video. This is all theory but pls implement it
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
Will do in one of the next videos 🤙
@elmehdimarjane
@elmehdimarjane 8 ай бұрын
Anyone has an idea on how to handle duplicates in an async context ?
@alienmars2442
@alienmars2442 6 ай бұрын
I wonder if InventoryService processes fails, but EmailService sends email successfully, how should we gonna do ?
@mithunbobade1
@mithunbobade1 6 ай бұрын
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
@raphauy
@raphauy 8 ай бұрын
Thank you!
@sauravkumarsharma6812
@sauravkumarsharma6812 8 ай бұрын
Thanks for such a good knowledge make some practical or reference some git repo
@prashlovessamosa
@prashlovessamosa 8 ай бұрын
Can you please implement all that stuff it would be too helpful
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
I can! Just stay tuned 😊
@prashlovessamosa
@prashlovessamosa 8 ай бұрын
@@SoftwareDeveloperDiaries great will wait for it.
@emperoralthaf6264
@emperoralthaf6264 8 ай бұрын
​@@SoftwareDeveloperDiariesHey that's awesome brother 🔥. Would like to see a payment integration using event driven architecture ❤.
@dikatok
@dikatok 8 ай бұрын
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
@SoftwareDeveloperDiaries
@SoftwareDeveloperDiaries 8 ай бұрын
Indeed, they are individual patterns. But EDA often relies on those :)
@SureddiBhargav
@SureddiBhargav 7 ай бұрын
RABBITMQ deep dive please
@dinov5347
@dinov5347 5 ай бұрын
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.
@bhuvaneshwariselvaraj9588
@bhuvaneshwariselvaraj9588 6 күн бұрын
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,
Idempotency in APIs: you should be aware of this!
7:31
Software Developer Diaries
Рет қаралды 17 М.
Microservices with Databases can be challenging...
20:52
Software Developer Diaries
Рет қаралды 119 М.
Непосредственно Каха: сумка
0:53
К-Media
Рет қаралды 12 МЛН
7 Design Patterns EVERY Developer Should Know
23:09
ForrestKnight
Рет қаралды 204 М.
Event-Driven Architecture (EDA) vs Request/Response (RR)
12:00
Confluent
Рет қаралды 181 М.
Event Driven Architecture EXPLAINED in 15 Minutes
14:55
Continuous Delivery
Рет қаралды 38 М.
A Beginner's Guide to Designing a Relational Database (Databases 101)
25:47
Software Developer Diaries
Рет қаралды 4,5 М.
Domain-Driven Design: The Last Explanation You'll Ever Need
21:05
Software Developer Diaries
Рет қаралды 18 М.
Event Driven Architectures vs Workflows (with AWS Services!)
15:49
Be A Better Dev
Рет қаралды 95 М.