Röviden: Az események köré szervezett rendszer rugalmasabb és jobban skálázódik, de új nehézségeket is hoz. Mikor válaszd, és mire figyelj a gyakorlatban?
Az eseményvezérelt architektúra — ahol a komponensek nem közvetlenül hívják egymást, hanem eseményeken keresztül kommunikálnak — a felhős tervezés egyik legerősebb mintája. A vonzereje a laza csatolás: a komponensek nem tudnak egymásról közvetlenül, csak eseményeket adnak ki és fogadnak. Ez rugalmasságot és jó skálázhatóságot ad, de cserébe új nehézségeket is hoz, amiket érdemes tisztán látni, mielőtt belevágsz.
Mit ad a laza csatolás?
A közvetlen hívásnál a hívó fél tudja, kit hív, és megvárja a választ — szoros csatolás. Az eseményvezérelt modellben a komponens csak kiad egy eseményt („ez történt”), és nem tudja, ki és hogyan reagál rá. Ez felszabadító: új feldolgozókat adhatsz hozzá anélkül, hogy a kibocsátót módosítanád, és a komponensek egymástól függetlenül skálázódhatnak és fejlődhetnek.
Mikor válaszd?
- Több, független reakció egy eseményre: egy dolog megtörténik, sok minden reagálhat rá.
- Eltérő skálázási igény: a komponensek külön-külön skálázódnak.
- Fejlődő rendszer: új feldolgozók hozzáadása a meglévők bolygatása nélkül.
- Aszinkron tolerancia: a feldolgozás nem kell azonnal, elviseli a késleltetést.
Az új nehézségek
A laza csatolás ára a megnövekedett komplexitás a megértésben és a hibakeresésben. Egy szinkron hívásláncot könnyű követni; egy aszinkron eseményfolyamot sok komponensen át nehéz. Emellett kezelni kell az események sorrendjét, a duplikációt (ugyanaz az esemény kétszer érkezhet) és a hibás feldolgozást (mi történik egy fel nem dolgozható eseménnyel?).
Az idempotencia mint kötelező elem
Az eseményvezérelt rendszerekben egy esemény többször is megérkezhet — ez a modell természetéből fakad. Ezért a feldolgozóknak idempotensnek kell lenniük: ugyanazt az eseményt kétszer feldolgozva nem lehet más az eredmény, mint egyszer. E nélkül a duplikált események csendben elrontják az adatot. Ez nem opcionális finomítás, hanem alapvető helyességi követelmény.
A hibás események kezelése
Mi történik egy eseménnyel, amit nem sikerül feldolgozni? Ha nincs terved rá, elveszhet vagy végtelenül próbálkozhat, blokkolva a sort. A jó minta egy dedikált „elakadt üzenetek” tár (dead-letter queue): a többszöri próbálkozás után is sikertelen esemény ide kerül, ahol megvizsgálható, anélkül hogy a fő folyamatot blokkolná.
Mit jelent ez neked?
Az eseményvezérelt architektúra laza csatolással rugalmasságot és jó skálázhatóságot ad — akkor válaszd, ha egy eseményre több független reakció kell, a komponensek eltérően skálázódnak, és a feldolgozás elviseli az aszinkronitást. Cserébe fektess be a megfigyelhetőségbe, mert a hibakeresés a fő nehézség; tedd a feldolgozókat idempotenssé, mert az események duplikálódhatnak; és kezeld a hibás eseményeket dedikált dead-letter tárral. A laza csatolás felszabadít, de csak ha ezeket az alapokat lerakod.