When a data-access layer must notify another system about a change, how do publishing before the commit and publishing from an after-commit callback fail differently?

## Two systems, one boundary that only covers one of them A unit of work commits **database** work. The transaction it controls is the engine's, over one connection: the layer can roll back rows, and it can roll back nothing else. A notification handed to another system has left the building. There is no ordering of the two operations that makes them one, and understanding this is the whole question — everything else is picking which failure to inherit. ## Publishing before the commit: the false positive The send happens while the transaction is still open and undecided. - If the commit then fails — a constraint deferred to the end, a version check that finds nothing to update, a dropped connection, an exception further up the stack — the message is already gone. Receivers have recorded a change the database never adopted, and no retraction reaches them, because the sender does not know who acted on it or how. - Even on the happy path there is a **visibility race**. The change is not readable by anyone else until the commit returns. A receiver that reacts by reading the source record can arrive first and see the old state, or nothing at all. Then it either fails, or — worse — succeeds with stale data and writes a decision based on it. The consequence to state clearly: this ordering is not "usually fine and occasionally wrong". It is wrong in a way whose blast radius grows with the number of receivers, because each one has independently absorbed a fact that has to be undone by hand. ## Publishing after the commit: the false negative Moving the send into an after-commit callback fixes the direction: nothing is announced unless it really happened. What it buys is honesty; what it costs is delivery. - The process can die between the commit returning and the send. The data is durable; the notification never existed. - The receiving system can be unavailable. Retrying inside the callback holds a thread and can still exhaust its attempts; giving up loses the message. - The callback's own failure changes nothing about the data, so there is no automatic path back to a consistent state. - The loss is **silent by default** — the state is correct, so nothing downstream detects the absence except the receiver's own suspicion that it has not heard from you. | | Publish before commit | Publish from after-commit callback | |---|---|---| | Failure produced | Announced a change that never landed | Landed a change nobody was told about | | Detectability | Receivers act, then diverge | Silent absence | | Repairable by retry | No — the send already happened | Yes, if the intent was recorded somewhere | | Race on reading the source | Yes, the change is not yet visible | No, the change is committed | ## Why neither can be made atomic here The layer's boundary spans its own transactional work. Enrolling an outside system into that boundary is not something the mapper can do on its own: the other system has its own commit, its own failure modes, and no obligation to obey a decision made elsewhere. Coordinating two independent commits is a separate discipline with its own costs, and it is not what an after-commit callback is. So the honest framing for a candidate is: **choose the failure you can absorb**, and then remove it if the cost justifies it. ## The move that changes the trade The notification does not have to be an *effect*. It can be **data**. Writing the message as an ordinary row in the same unit of work as the state change makes the two atomic in the only place atomicity is available — inside one database transaction. Either both are there after the commit or neither is. Delivery then becomes a separate step, performed after the data is durable and free to retry because the intent is safely recorded; an after-commit callback is a fine way to nudge that step to run immediately instead of waiting. That shifts the guarantee from "the notification happened" to "the notification will happen", which is usually what the business actually needed. It also changes the receiver's contract: a step that may retry can deliver the same thing more than once, so receivers must be able to absorb a repeat. That is the price of never losing one. ## The compression Before the commit you can lie; after the commit you can forget. Only data written inside the transaction can be neither.