Transactional Outbox
Casella in uscita transazionale
Una casella di posta transazionale salva una modifica dei dati e un record di messaggio in un'unica transazione di database locale. Un relay invia il messaggio salvato dopo che la transazione viene confermata.
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerorders✓order_2048outbox✓evt_784local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerJOBUn altro esempio
Il checkout salva l'ordine `984` e l'evento in uscita `OrderCreated:984` in un'unica transazione. Un relay pubblica l'evento successivamente. Se si interrompe dopo l’invio ma prima di contrassegnare la riga, potrebbe inviarlo di nuovo. Il consumer rimuove il duplicato tramite l'ID dell'evento.
Parti principali
- 01Variazione dati aziendali
- 02riga evento della cassetta in uscita
- 03Una transazione locale
- 04Relay o flusso di cambiamenti
- 05pubblicazione del broker
- 06Consumatore sicuro dai duplicati
Usalo quando
Usalo quando una modifica impegnata al database deve portare in modo affidabile a un messaggio o evento. Mantieni l'outbox nella stessa transazione e gestisci il relay come un processo affidabile a sé stante.
Non usarlo quando
Non chiamarlo consegna una tantum o una singola transazione tra servizi. Pianifica eventi ripetuti, il loro ordine, ritardo di trasmissione, pulizia e gestione sicura dei duplicati.
Nome usato nel codice
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumer Prima di spedire
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Complete the task with Casella in uscita transazionale (Transactional Outbox). User context: Il checkout salva l'ordine `984` e l'evento in uscita `OrderCreated:984` in un'unica transazione. Un relay pubblica l'evento successivamente. Se si interrompe dopo l’invio ma prima di contrassegnare la riga, potrebbe inviarlo di nuovo. Il consumer rimuove il duplicato tramite l'ID dell'evento. Technical concept or control: Casella in uscita transazionale (Transactional Outbox). Why it fits: Usalo quando una modifica impegnata al database deve portare in modo affidabile a un messaggio o evento. Mantieni l'outbox nella stessa transazione e gestisci il relay come un processo affidabile a sé stante. Do not use it when: Non chiamarlo consegna una tantum o una singola transazione tra servizi. Pianifica eventi ripetuti, il loro ordine, ritardo di trasmissione, pulizia e gestione sicura dei duplicati. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Nessun singolo standard ufficiale controlla l'intero termine. Il suo significato può cambiare tra team, piattaforme o framework. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Controlla questa richiesta
Review how Casella in uscita transazionale (Transactional Outbox) is used now. Definition: Una casella di posta transazionale salva una modifica dei dati e un record di messaggio in un'unica transazione di database locale. Un relay invia il messaggio salvato dopo che la transazione viene confermata. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.