Event Driven Design - FullstackCodingGuy/Developer-Fundamentals GitHub Wiki
read
If you’ve designed large scalable systems with event-driven design before, you’ve undoubtedly encountered the dual write problem. Some of you may have been fortunate enough to work with architects or experienced software engineers who put in place systems to avoid this problem; others sadly aren’t as fortunate.
I’m lucky to have never directly encountered this problem on any projects I’ve worked on. However, I have heard war stories from many colleagues over the years, which prompted me to dive deeply into this topic early in my career.
So, my dear reader, strap in and explore this topic further. Let’s start by examining this diagram. Can you spot what’s wrong?
Give up? In this example, an event to save something to the database happens simultaneously as a follow-up event takes place; this could be to update Redis or something else.
What happens if the application fails after the save has been completed but before the emit finishes?
Our database was updated in this scenario, but our event was never successfully emitted. This is a problem because we have a huge inconsistency between our database and our events.
Of course, this is a simplified version of the problem, but you can imagine how much of an issue this would cause at scale.
Now, you might be wondering for yourself:
That's pretty straightforward; just emit the event first, then save it to the database!
Problem solved, right? Unfortunately, that reverses the order in which you’ll encounter the problem, but the problem still remains. This is because now the event is being emitted but the state/data is never saved.
Another solution is wrapping everything under a transaction; unfortunately, this moves the problem elsewhere in our system.
So how exactly is this problem solved?
There are 2 solutions