After a housing case row commits, an agent follow-up message must not be lost if the process crashes mid-flight. What pattern helps?
Select an answer to reveal the explanation.
Short Explanation
You can think of the outbox as writing the housing note in the ledger, then placing the “call the agent” slip in the out tray. That way, a crash won’t lose the follow-up after the case is saved.
Full Explanation
After a housing case row commits, the agent follow-up must survive a process crash. An outbox-style pattern persists the case state and the intent to message within the same durable store or transactional boundary, then reliably dispatches the Service Bus follow-up. If the process dies after the database commit, the pending outbox entry remains available for dispatch, so the agent automation is not lost mid-flight. Publishing the Service Bus message before committing the case row risks an orphan follow-up for an unsaved case. Skipping messaging and hoping caseworkers notice database changes drops the agent follow-up automation. Writing the database change and queue message in separate systems with no coordination creates a dual-write race: a crash may leave only one of the two changes in place. Exam caveat: database-and-broker dual writes are a classic consistency hazard, and the transactional outbox is the relevant mitigation here; unlike an outbox, idempotent consumers address duplicate delivery after a message has been enqueued. Practical check: in a test harness, commit a housing case with an outbox entry, crash before the Service Bus send, restart the dispatcher, and verify that it publishes the follow-up from the outbox exactly once and that the agent receives the case context.