> Sure enough it sounded like this article

FWIW The article literally talks about the challenges with getting this to actually work and recommends removing it and just using the DB for everything.

▲ mrkeen 5 hours ago | parent [-]

But that's what the outbox pattern is. You take the problem of transacting between more than one system, and by "just using the db", you declare the problem solved, leaving the communication with other systems as an exercise for the reader.

From the end of the article:

  The enqueue_workflow UDF creates this row in the same transaction as the user database update, guaranteeing atomicity

	▲	sarchertech 4 hours ago \| parent \| next [-]
		Your right! But the outbox pattern is good enough for a lot of purposes. The outbox pattern works if the only reason the write to the 2nd system can fail is because of transient issues. It will keep trying until the system is back up. If the 2nd system write can fail for non-transient reasons, the outbox pattern doesn’t work and you need either 2 phase commit or a distributed saga. I wrote about this here a few years ago. https://linuxblog.io/the-two-generals-problem/
	▲	koverstreet 4 hours ago \| parent \| prev [-]
		The point is that the "outbox pattern" is not an atomic transaction. You fundamentally don't have those in the distributed world, via the CAP theorem, and if you want anything close to the guarantees a local transactional database gives you in a distributed system you have to design your schema for it. Distributed coherency is not something you can abstract away, the abstractions all leak.