Az event-driven microservice architektúra olyan rendszer, ahol a service-ek nem közvetlenül hívják egymást, hanem eseményeket (eventeket) publikálnak, és más service-ek ezekre aszinkron módon reagálnak.

Headless WordPress + Angular architektúrával már dolgoztam lazán csatolt rendszerben.
Jelenleg NestJS-ben event-driven payment flow-t tervezek (SimplePay → invoice → email), ahol eventekkel választom szét a folyamatokat.

Microservice architektúrát akkor érdemes használni, amikor a rendszer több jól elkülöníthető domainre bontható, például egy médiaportálnál külön kezeljük a contentet, a kommenteket, a keresést és az ajánló rendszert. Így ezek külön skálázhatók és hibák esetén nem borítják az egész rendszert. Event-driven megközelítéssel pedig ezek lazán kapcsolódnak egymáshoz, például egy cikk megnyitása eseményt generál, amire több service is reagálhat.

Ha akarod, adok még egy példát:

👉 SaaS / előfizetéses rendszer (Stripe + billing + user management)

Oké — akkor kapsz egy realista, senior szintű mini mock interjút.
Ez nagyon közel lesz ahhoz, amit egy ilyen (pl. ES-Matrix szintű) cégnél kérdeznek.

👉 Menet:

kérdés
mit várnak
jó válasz (amit te is mondhatsz)
* extra insight, ha rá akarsz tenni egy lapáttal

🎯 1. Kérdés

„Mi az az event-driven architektúra, és miért jobb, mint a klasszikus request-response?”

🎯 Mit várnak:

ne definíciót mondj csak
coupling + async + skálázás

✅ Jó válasz:

Event-driven architektúrában a service-ek nem közvetlenül hívják egymást, hanem eseményeket publikálnak, amikre más service-ek aszinkron módon reagálnak.
Ez csökkenti a couplingot, mert a producer nem tud a consumer létezéséről, és növeli a skálázhatóságot, mert a feldolgozás párhuzamosítható.

🔥 Extra:

Request-response modellnél a hívási lánc törékeny, míg event-driven esetben a rendszer jobban tolerálja a részleges hibákat.

🎯 2. Kérdés

„Mi történik, ha egy event feldolgozása közben hiba történik?”

🎯 Mit várnak:

retry
DLQ
nem veszhet el adat

✅ Jó válasz:

Ilyenkor retry mechanizmust alkalmazunk, például exponential backoff-pal.
Ha egy event többször is sikertelenül feldolgozódik, akkor Dead Letter Queue-ba kerül, ahol később manuálisan vagy külön processz által kezelhető.

🔥 Extra:

Fontos, hogy a feldolgozás idempotens legyen, mert retry során ugyanaz az event többször is lefuthat.

🎯 3. Kérdés

„Mi az az idempotencia, és miért kritikus event-driven rendszereknél?”

🎯 Mit várnak:

ne tankönyv
konkrét use case

✅ Jó válasz:

Idempotencia azt jelenti, hogy ugyanazt az eseményt többször feldolgozva is ugyanaz az eredmény jön létre.
Event-driven rendszereknél ez kritikus, mert az üzenetküldés általában at-least-once delivery, tehát ugyanaz az event többször is megérkezhet.

🔥 Példa:

Például egy számla létrehozásnál transactionId alapján ellenőrzöm, hogy már létezik-e, így nem generálok duplikált számlát.

🎯 4. Kérdés

„Milyen message brokert választanál, és miért?”

🎯 Mit várnak:

trade-off
nem egy szó

✅ Jó válasz:

Kisebb rendszereknél Redis alapú queue-t, például BullMQ-t használnék, mert egyszerű és gyorsan integrálható.
Komplexebb, skálázott rendszereknél RabbitMQ-t vagy Kafka-t, attól függően, hogy queue vagy stream alapú feldolgozásra van szükség.

🔥 Extra:

RabbitMQ task queue jellegű use case-ekre ideális, Kafka pedig event streamingre és nagy throughput-ra.

🎯 5. Kérdés

„Hogyan terveznél meg egy payment flow-t event-driven módon?”

👉 EZ A LEGFONTOSABB

🎯 Mit várnak:

end-to-end gondolkodás
nem csak backend

✅ Jó válasz (nagyon közel a tiedhez):

A frontend elindítja a fizetést egy BFF-en keresztül.
A Payment Service kezeli a fizetést, és siker esetén publish-ol egy payment.completed eventet.
Erre reagál az Invoice Service, ami létrehozza a számlát, majd egy invoice.created eventet küld.
Ezt a Notification Service használja email küldésre, illetve opcionálisan egy másik service mentheti az adatokat WordPress-be.
Így a folyamat lazán csatolt, és az egyes lépések külön skálázhatók.

🔥 Extra (nagyon ütős):

Így ha például az email service kiesik, a payment flow attól még sikeres marad, és az email később újrapróbálható.

🎯 6. Bonus kérdés (ha erősek)

„Mi az eventual consistency?”

✅ Jó válasz:

Event-driven rendszereknél az adatok nem azonnal konzisztens állapotba kerülnek, hanem idővel.
Például a fizetés sikeres lehet, de a számla csak néhány másodperccel később jön létre.

🎯 7. Hogyan add elő magad (nagyon fontos)

Te így pozicionáld:

Angular frontend fejlesztőként dolgozom, de backend oldalon is építek NestJS alapú rendszereket.
Jelenleg egy event-driven payment flow-t tervezek, ahol a fizetés, számlázás és értesítés külön eseményeken keresztül van szétválasztva.

👉 Ez:

nem junior
nem backend-only
hanem full-stack gondolkodás

🔥 Végső coaching

Ha ezt tudod:

event fogalom ✔️
idempotencia ✔️
retry / DLQ ✔️
payment flow ✔️

👉 simán átugrod a lécet

Ha akarod, következő körben csinálhatunk egy “keményebb interjú” szimulációt, ahol belemegyünk:

microfrontend + event-driven kapcsolat
RxJS vs event-driven backend
distributed transaction (SAGA)

👉 ezek már top 10% kérdések.