So the sub side boots up, says it is ready, accepts an event, then power goes down.
You reboot the sub side. The event never gets processed because pub already sent it and recorded this fact.
Or, the sub side doesn't reboot, the pub side does. The pub side accepts an event for publishing, send it to the sub side, and promptly loses power.
The pub side reboots and either it resends the event and the sub side receives the event twice (because the pub side didn't record that it had already sent it before power was lost), or it doesn't resend the event and the sub side never receives it (because the power loss killed the network link while the packet was on its way out).
If you think you can make these and other corner cases go away with a simple bit of acknowledging here and there, good luck!
The corner cases can be solved, but it's not half as simple as "wait in a queue and be consumed when ready".
I think that's just unfair. Synchronous system finishes a task, tries to change state, power goes out, system is in an inconsistent state. If you think you can fix this with a couple of write-ahead logs and a consistency checker, good luck! That's how you sound.
> If you think you can fix this with a couple of write-ahead logs and a consistency checker, good luck! That's how you sound.
I'm literally saying it can't be fixed with a simple solution, in the parent comment and other comments, so I'm not sure where you get the idea that I'm saying it can.
Dealing with inconsistent states from failures in a distributed system is solvable but it's not simple unfortunately. It's not even simple to describe why.
Then the events will wait in a queue and be consumed when sub side is ready.