What is the event publishing approach called write-aside, and why do you need to be careful when using it.
First, what is write-aside?
It is when a processor of a request or an event performs its main operation, like updating records in a database, and then afterwards publishes the occurred event to an event platform.
Now because the two are external network operations to the processor, you need to ensure that the two complete successfully or not at all.
Because it is not a question; If it will fail, it’s when.
And to roll back changes on failure you to do you need to perform a distributed transaction.
But what do you do if the event after the operation does not publish?
First, of course, you could try to retry another time, and it may work, but there comes to a point where you need to stop and either try later or move on.
Now, what do you do with the performed operation?
Rollback the initial database transaction?
What do you do if the rollback fails or the commit has triggered an action which is not reversible?
Now you could perform a two-stage commit, but what happens if the commit fails? Maybe you could perform a three-phase commit, but it becomes a downward spiral and introduces design complexities.
Now, of course, you could not acknowledge or commit the consumer offset, reprocess, or implement a retry solution. However, what happens if the operation is not idempotent and operations can have negative consequences or is not reversible?
And if you can’t publish the occurred event, you will lose the event, which might be problematic.
Ok, so to summarise
So don’t use write-aside if
- You cannot lose data
- You cannot rollback
- Reprocessing the message will have adverse effects, or you cannot know if it has been processed (now, bear in mind if you publish an event at a later point, after processing later events, does the ordering of events matter? If so, this may have negative consequences as well
And only use write-aside if
- You can lose events, if not published
- You can reprocess the request or the triggering event without negative consequence
Implement exactly-once processing when you check if the operation has already been performed and if it has, then only publish the event. But if event ordering is essential, then this would not work.