Trex Pi
Niekde v každej integračnej zmluve je veta typu „každá objednávka bude odoslaná presne raz". Nebola pravdivá ani raz. Sieť sa rozdelila uprostred požiadavky a odosielateľ to skúsil znova; fronta doručila správu znova po páde konzumenta; skladový pracovník stlačil tlačidlo exportu dvakrát. Duplicity nie sú zlyhanie - sú počasie.
Idempotenčné kľúče, starostlivo vybrané
Riešenie je staré a nevzhľadné: každá správa nesie kľúč a spracovanie je no-op, keď už bol kľúč videný. Všetky zaujímavé rozhodnutia sú vo výbere kľúča.
- Prirodzené kľúče porážajú generované. Synchronizácia objednávok s kľúčom
order_id + statusprežije, keď odosielateľ znova vygeneruje svoj outbox; náhodné UUID vytvorené v čase odoslania nie. - Rozsah kľúča viažte na efekt, nie na správu. Ak jedna správa vytvorí faktúru a zároveň zaúčtuje sklad, sú to dva efekty s dvomi kľúčmi - inak vás čiastočné zlyhanie ponechá v stave, keď bezpečne nemôžete zopakovať ani jeden z nich.
- Nechajte kľúče vypršať zámerne. Úložisko na deduplikáciu, ktoré rastie donekonečna, je časovaná bomba; také, ktoré vyprší príliš skoro, opäť zavedie duplicity. Predvolene používame 3-násobok maximálneho horizontu opakovania odosielateľa.
Test, na ktorom záleží
Každá integrácia, ktorú dodáme, prejde tým, čo interne nazývame test dvojitého ťuknutia: prehráme celý včerajší log správ voči dnešnému systému, dvakrát, a porovnáme výsledný stav. Ak sa pri druhom priechode čokoľvek zmenilo, pipeline nie je hotová.
Je to brutálny test a počas vývoja neustále zlyháva - na časových pečiatkach, na audit poliach typu „vytvoril", na sekvenčných počítadlách. Každé zlyhanie je miesto, kde by opätovné doručenie o 3:00 ráno potichu poškodilo dáta. Odhaliť to počas vývoja je oveľa lacnejšie než v produkcii.