Outbox Pattern: Fixing event failures in an event-driven architecture

The Transactional Outbox Pattern ensures a message is always published to a message broker when making changes to a database, even if the message broker fails initially. This is essential for event-driven architecture to ensure consistency when other services are rebuilding state from your events.
0:00 Network failures
0:54 Atomic Transactions
2:00 Publishing the event
2:52 At-Least Once delivery
3:32 Idempotency
4:14 Outro

[@primavera919]

Excellent video displayed in an animation, thanks a lot

[@ericveltman5624]

Excellent explanation! Visual, concise but still explaining all the important matters.

[@danyboomz]

Please take a look at spring modulith, it implements all the concepts you described in all your videos !

[@arvjosol]

Your videos are so good. They're concise and informative.

[@alex_martishin]

Great video! Very concise and informative

[@saidk.6461]

Great explanation, thank you!

[@VagnerGon]

Love your videos, keep going!

[@alan-]

Always the best videos.

[@drawingboxes]

Cheers! Great to see you here, as always!

[@johnxisde]

amazing video!

[@tamasszebenyi5942]

Nice!

[@get_out_it]

thanks

[@thiensinh6872]

What toolset are you using to create these great videos? I supposed PowerPoint is one of them.

[@drawingboxes]

Exactly - export slides as video, record my voice and make background music in Ableton, then retime the video to the audio with DaVinci Resolve

[@亞米歐弟沒有]

It's really good video, but the more pattern I learned, the more traditional way I would decide to use. I've been implementing DDD and Microservice for years, and I found traditional design always win, and you don't need to seek for a new pattern to fix the patterns.

[@robotrabbit5817]

What’s the traditional way?

[@no-name2031]

.​@@robotrabbit5817maybe a monolith and scailing verticality?

[@alan-]

I'm also curious, what is the method you use? Also I think you're implying that there are other situations within DDD/microservices where more modern patterns are perhaps no better than traditional patters. Could you give an example or two as to what those are too?

[@drawingboxes]

Thanks! I'm glad you enjoyed the video. I assume you mean a traditional monolithic centralised application? That is a perfectly valid approach too, but it has its downsides. There's always a trade-off. If you're interested, check out my video comparing these here kzbin.info/www/bejne/bF66pmRtbdiCe6c

[@亞米歐弟沒有]

1. The Anemic model, Monolithic, or even MVC are the "traditional ways" I meant. 　It sounds old but it always "get things done". 2. Microservices or DDD are highly ideal in terms of design, but the implementation just not align with reality. 　Aggregate Root is a great concept, but it's not when you are trying to save/update it. There are still a lot I wanted to talk about, but instead of following DDD mentally, I'm starting to use part of the concept to complement my Monolithic, I found it works the best. I just won't use Microservice / DDD / Event-driven *from the ground up* to lost in the "Pattern Maze" again 💀💀 To know if you are solving a "problem" or a "problem that doesn't exist" is also a puzzle.