Röviden: Az aszinkron rendszer sikere a DLQ-n, az idempotencián és a retry-stratégián múlik, nem a happy pathon. A hibakezelés az, amit a legtöbben utólag, incidensben tanulnak meg.
Az eseményvezérelt architektúra vonzó: laza csatolás, jó skálázhatóság, komponensek, amelyek nem várnak egymásra. A tervezés során a figyelem szinte mindig a happy pathra irányul — hogyan folyik az esemény a forrástól a célig, ha minden jól megy. A gond az, hogy a valódi különbség egy törékeny és egy megbízható event-driven rendszer között nem a happy pathon, hanem a hibakezelésben van. És azt a legtöbben utólag, egy éjszakai incidensben tanulják meg.
Az aszinkronitás elrejti a hibát
A szinkron rendszerben a hiba azonnal látszik: a hívó kap egy hibaüzenetet. Az aszinkron, eseményvezérelt rendszerben a termelő elküldi az eseményt, és továbbmegy — nem tudja és nem várja meg, hogy a fogyasztó sikeresen feldolgozta-e. Ha a feldolgozás elhasal, az esemény csendben elveszhet, vagy végtelen retry-ba ragadhat, anélkül hogy bárki észrevenné. Ezért a hibakezelést itt tudatosan meg kell tervezni.
A három pillér
- Holtlevél-sor (DLQ) — ahová a feldolgozhatatlan üzenet kerül, hogy ne vesszen el és később megvizsgálható legyen.
- Idempotencia — a fogyasztó ugyanazt az üzenetet többször feldolgozva se okozzon dupla hatást.
- Retry-stratégia — átmeneti hibánál újrapróbálkozás, de korláttal és növekvő várakozással, nem végtelen ciklusban.
Az idempotencia mint alapkövetelmény
Az eseményrendszerek jellemzően legalább-egyszer kézbesítést garantálnak, ami azt jelenti: számíts rá, hogy egy üzenet többször is megérkezhet. Ha a fogyasztód nem idempotens, akkor egy retry vagy egy duplikált esemény dupla hatást vált ki — dupla számlázás, dupla e-mail, kétszer levont készlet. Az idempotenciát a fogyasztónak kell biztosítania, egy feldolgozási azonosító nyilvántartásával vagy természetes idempotens művelettel.
A retry helyes formája
A naiv retry (azonnal, korlátlanul újrapróbálni) veszélyes: egy tartós hiba esetén végtelen ciklust és terhelést okoz, ami akár egy downstream rendszert is padlóra küldhet. A helyes retry növekvő várakozással dolgozik (exponenciális backoff), van egy maximális próbaszáma, és utána a DLQ-ba teszi az üzenetet. Így az átmeneti hibát kezeled, a tartósat pedig félreteszed vizsgálatra, ahelyett hogy a rendszert ostoroznád vele.
A mérgezett üzenet
Külön figyelmet érdemel a „mérgezett üzenet” (poison message): egy olyan üzenet, amit a fogyasztó soha nem tud feldolgozni (például hibás formátum miatt). Retry-korlát nélkül ez örökre blokkolhatja a feldolgozást, vagy végtelen ciklusban égeti az erőforrást. A retry-korlát és a DLQ pontosan ezt kezeli: a mérgezett üzenet néhány próba után félrekerül, és a rendszer megy tovább.
A holtlevél-sor mint biztonsági háló
Az eseményvezérelt rendszerben a holtlevél-sor (DLQ) nem opció, hanem alapkövetelmény: a feldolgozhatatlan üzenetnek mennie kell valahová, ahol később megvizsgálható, különben csendben elveszik vagy végtelen retry-ba ragad. De a DLQ önmagában nem elég — kell mellé riasztás és egy folyamat, ami rendszeresen megnézi. Egy figyelmen kívül hagyott DLQ csak egy csendes szemetes, ahol az elveszett üzenetek gyűlnek.
A jó felállásban a DLQ-ba kerülő üzenet riasztást vált ki, valaki megvizsgálja, és eldönti: újrafeldolgozható-e javítás után, vagy tartósan hibás. Ez a folyamat teszi a DLQ-t valódi biztonsági hálóvá.
Az idempotencia mint alapfeltétel
Az eseményrendszerek jellemzően legalább-egyszer kézbesítést garantálnak: számíts rá, hogy egy üzenet többször is megérkezhet. Ha a fogyasztód nem idempotens, akkor egy retry vagy egy duplikált esemény dupla hatást vált ki — dupla számlázás, dupla e-mail, kétszer levont készlet. Az idempotenciát a fogyasztónak kell biztosítania.
- Tervezz minden fogyasztót idempotensre.
- Használj feldolgozási azonosítót vagy természetes idempotens műveletet.
- Teszteld a duplikált üzenet esetét, ne csak a happy patht.
Mit jelent ez neked?
Az eseményvezérelt architektúrában a hibakezelés nem utólagos részlet, hanem a rendszer megbízhatóságának lényege. Tervezz DLQ-t riasztással és rendszeres átnézéssel, tedd a fogyasztóidat idempotenssé (mert az üzenet többször is jöhet), és használj korlátos, növekvő várakozású retry-t. A happy path megtervezése a könnyű rész; a rendszered valódi minőségét az dönti el, mi történik, amikor valami elromlik — mert el fog.