Točno-jednom je laž: dizajniranje integracija za duplikate

Negdje u svakom ugovoru o integraciji nalazi se rečenica poput „svaka narudžba bit će prenesena točno jednom". Ona nikada nije bila istinita. Mreža se prekinula usred zahtjeva pa je pošiljatelj ponovio pokušaj; red čekanja ponovno je isporučio poruku nakon pada potrošača; skladišni djelatnik dvaput je pritisnuo gumb za izvoz. Duplikati nisu način kvara - oni su vremenske prilike.

Ključevi idempotentnosti, pažljivo odabrani

Rješenje je staro i nezanimljivo: svaka poruka nosi ključ, a obrada ne radi ništa ako je ključ već viđen. Sve zanimljive odluke leže u odabiru tog ključa.

• Prirodni ključevi bolji su od generiranih. Sinkronizacija narudžbi ključana na order_id + status preživljava situaciju kada pošiljatelj ponovno generira svoj odlazni red; nasumični UUID skovan u trenutku slanja to ne preživljava.
• Vežite ključ uz učinak, ne uz poruku. Ako jedna poruka istovremeno kreira fakturu i knjiži zalihu, to su dva učinka s dva ključa - inače vas djelomični kvar ostavlja u situaciji u kojoj ne možete sigurno ponoviti ni jedno ni drugo.
• Namjerno postavite istek ključeva. Pohrana za deduplikaciju koja raste zauvijek vremenska je bomba; ona koja istekne prebrzo ponovno uvodi duplikate. Kao zadano koristimo 3× maksimalni horizont ponovnih pokušaja pošiljatelja.

Test koji je bitan

Svaka integracija koju isporučimo prolazi ono što interno nazivamo testom dvostrukog dodira: cjelokupni jučerašnji zapisnik poruka ponovno se pusti kroz današnji sustav, dvaput, a rezultirajuće se stanje uspoređuje. Ako se nešto promijenilo u drugom prolazu, cjevovod nije gotov.

To je brutalan test i tijekom razvoja stalno ne uspijeva - na vremenskim oznakama, na revizijskim poljima „kreirao", na brojačima slijeda. Svaki neuspjeh mjesto je gdje bi ponovna isporuka u 3 ujutro tiho oštetila podatke. Daleko ga je jeftinije uhvatiti tijekom razvoja nego u produkciji.