Trex Pi
Nekje v vsaki integracijski pogodbi je stavek, podoben temu: „vsako naročilo bo posredovano natanko enkrat". To ni bilo resnično še nikoli. Omrežje se je med zahtevo prekinilo in pošiljatelj je poskusil znova; čakalna vrsta je sporočilo znova dostavila po sesutju porabnika; skladiščni delavec je dvakrat pritisnil gumb za izvoz. Podvojeni podatki niso napaka - so vremenski pojav.
Skrbno izbrani ključi idempotentnosti
Rešitev je stara in nezanimiva: vsako sporočilo nosi ključ, obdelava pa se ne izvede, če je bil ključ že viden. Vse zanimive odločitve so v izbiri ključa.
- Naravni ključi so boljši od generiranih. Sinhronizacija naročil s ključem
order_id + statuspreživi, tudi če pošiljatelj znova ustvari svoj odhodni predal; naključni UUID, generiran ob pošiljanju, tega ne preživi. - Ključ omejite na učinek, ne na sporočilo. Če eno sporočilo ustvari račun in knjiži zalogo, gre za dva učinka z dvema ključema - sicer vas delna napaka pusti v položaju, kjer nobenega od njiju ne morete varno ponoviti.
- Ključem namerno določite rok veljavnosti. Shramba za odstranjevanje podvojitev, ki raste v nedogled, je časovna bomba; taka, ki poteče prehitro, znova vnese podvojene podatke. Privzeto uporabljamo 3-kratnik maksimalnega časovnega okvira pošiljateljevih ponovnih poskusov.
Test, ki šteje
Vsaka integracija, ki jo dostavimo, opravi test, ki mu interno pravimo test dvojnega udarca: celoten dnevnik sporočil iz včerajšnjega dne dvakrat predvajamo skozi današnji sistem in primerjamo nastalo stanje. Če se je pri drugem prehodu karkoli spremenilo, cevovod ni dokončan.
Je brutalen test in med razvojem nenehno odpove - pri časovnih žigih, pri revizijskih poljih „ustvaril", pri zaporednih števcih. Vsaka napaka je mesto, kjer bi ponovna dostava ob treh zjutraj tiho pokvarila podatke. Veliko ceneje jo je odkriti med razvojem kot v produkciji.