3 ms·
It has been several years since I worked on a system that implemented listen/notify, but I recall there was a significant caveat that if the listener was unavai
by macNchz 3y ago
It has been several years since I worked on a system that implemented listen/notify, but I recall there was a significant caveat that if the listener was unavailable at the exact moment the NOTIFY executes, the message would be lost.
That’s a significant risk for things that need to be in sync between two systems, so we stuck with listen/notify for info-level ops things and used polling/queue systems that offered better guarantees for more important tasks. Don’t want to be in a position where a quiet hiccup with a deploy or something results in fun bugs like 0.5% of rows being silently out of sync between ES and Postgres.
- xupybd 3y agoYou could put a Nats JetStream connection in line and you'd have a good buffer to catch the notifications. Not fool proof but then you'd need some kind of batch process that looks for any outstanding changes and syncs them. We do something like this with our systems. External events get written to the event bus but all operations are idempotent on the event bus. So at night we send another round of the days events to clean up any inconsistencies.
- stoniejohnson 3y agoMaking jobs idempotent forces good design imo.
- freedomben 3y agoYes agreed. It's (usually) more work, but the gains in robustness and fault tolerance are (usually) well worth it