What is the Listen to Yourself Pattern? | Designing Event-Driven Microservices

[@kevinding0218]

Thanks a lot for the video. With the Listen to Yourself pattern, it implies that when our microservice performs a calculation or similar operation, the resulting data should be included in the event payload. This enables the service to rely on the data within the event payload to update its own database when it listens to itself.
In this setup, I feel it's crucial to pay careful attention to the message bus configuration, particularly aspects like order delivery guarantees.
Alternatively, employing event sourcing might be beneficial to provide a mechanism for reconciliation in case of discrepancies. For instance, if the process involves calculating a deposit check, merely having a snapshot of the calculation in the event payload might be insufficient.

[@robreid_io]

The Transactional Outbox pattern (with CDC) always works nicely as a way to avoid the Dual Write problem!

[@Fikusiklol]

I believe that outbox is just straight up slower and sending an event right away is more perfomant. Do I get it right?

[@MaxingMix]

@@Fikusiklol but you may run into dual write problem without oubox

[@Fikusiklol]

@@MaxingMix Yeah, I get it. I usually just stick to outbox, cause there are no perfomance issues in my domain. Thanks!

[@thats_mr_rob]

@@ConfluentDeveloperRelations You've thought of everything! 😄 Thanks for sharing and for the great content, Wade.

[@caspersthrane]

Outboxing is a far better solution, to solve the dual write problem.

[@sabaokangan]

Thank you so much for sharing this with us on RUclips ❤️‍🔥 from SeoulNatU

[@SwapnilDharane]

How is it different than the saga pattern