Transaksjonell inbox
En transaksjonell inbox bruker varige meldingsregistreringer for å beskytte lokal behandling mot doble leveringer.
En transaksjonell inbox bruker varige meldingsregistreringer for å beskytte lokal behandling mot doble leveringer. I varianten som beskrives her, lagres registreringen av en behandlet melding og den tilhørende endringen i forretningsdataene i samme databasetransaksjon.
En fiktiv tjeneste med konsumentnavnet report-worker mottar meldingen E-42. Den registrerer kombinasjonen av konsument og meldings-ID i sin inbox og øker en rapportteller fra 6 til 7. Begge endringene committes samlet. En unikhetsregel i databasen for denne kombinasjonen beskytter også når flere instanser arbeider samtidig. Å kontrollere først og skrive etterpå er ikke tilstrekkelig i seg selv.
Tidspunktet for krasjet er viktig
Mislykkes transaksjonen før commit, blir verken inboxregistreringen eller tellerendringen stående. Lykkes commit, men den etterfølgende kvitteringen til brokeren går tapt, kan E-42 komme igjen. Den eksisterende registreringen hindrer da en ny økning til 8. Kvitteringen til brokeren er ikke selv en del av denne lokale databasetransaksjonen.
Idempotens beskriver den trygge virkningen av gjentakelse; en inbox er et mulig implementasjonsmønster. En outbox lagrer derimot utgående meldinger sammen med den lokale endringen. Inboxen alene garanterer ikke at et eksternt HTTP-kall utføres eller en e-post sendes nøyaktig én gang. Lagringstiden for meldings-ID-er må passe til det mulige tidsrommet for ny levering og replay; registreringer som fjernes for tidlig, beskytter ikke lenger mot senere duplikater.
Kilder
Beslektede begreper
- IdempotensEn idempotent handling har samme tilsiktede effekt på tilstanden ved identisk gjentakelse som ved én utførelse.
- MeldingskvitteringEn meldingskvittering forteller meldingsmegleren at en levering er mottatt eller behandlet etter den avtalte regelen.
- Jitter ved nye forsøkRetry-jitter varierer ventetider tilfeldig for å spre nye forsøk og redusere samtidige forespørsler fra mange klienter.
- TestkundeområdeEt logisk avgrenset kundeområde i en multitenant-applikasjon, satt opp for kontroller.
- Ny sending av webhookNy sending av webhook overfører en melding på nytt. Planlagt gjenoppretting og replay-angrep krever ulike kontroller.
- IdempotensnøkkelEn idempotensnøkkel identifiserer gjentakelser av samme tilsiktede forespørsel. Område, lagringstid og API-regler avgjør virkningen.
Artikler om temaet
API-er og integrasjon med ASES
ERP, CRM og nettbutikk ryddig koblet sammen