Event-driven integration: τι είναι και πότε το χρειάζεστε

Μια νέα παραγγελία φτάνει στο e-shop. Η αποθήκη τη χρειάζεται για συλλογή και συσκευασία, η τιμολόγηση για να εκδοθεί το παραστατικό, το CRM για να ενημερωθεί το ιστορικό του πελάτη, και του χρόνου θα τη χρειαστεί και το πρόγραμμα επιβράβευσης. Η πρώτη εκδοχή είναι συνήθως ένα integration που καλεί όλα αυτά τα συστήματα το ένα μετά το άλλο. Δουλεύει, μέχρι που ένα από αυτά αργεί ή πέφτει, και τότε σταματά όλη η αλυσίδα, μαζί και τα κομμάτια που δεν είχαν καμία σχέση με το πρόβλημα.

Το event-driven integration είναι ένας διαφορετικός τρόπος να συνδέετε συστήματα: το e-shop ανακοινώνει ότι κάτι συνέβη, και κάθε σύστημα που ενδιαφέρεται αντιδρά μόνο του. Σε αυτόν τον οδηγό εξηγούμε τις βασικές ιδέες, τις εγγυήσεις στις οποίες μπορείτε (και δεν μπορείτε) να βασιστείτε, πότε η προσέγγιση αξίζει και πότε όχι, και πώς να συγκρίνετε τα εργαλεία.

Events, commands και γιατί η διαφορά μετράει

Δύο είδη μηνυμάτων μοιάζουν ίδια στο δίκτυο, αλλά σημαίνουν διαφορετικά πράγματα:

Ένα command ζητά από ένα συγκεκριμένο σύστημα να κάνει κάτι: «δημιούργησε την παραγγελία πώλησης για τον C-1042 στο ERP». Ο αποστολέας ξέρει τον παραλήπτη και συνήθως τον ενδιαφέρει το αποτέλεσμα.
Ένα event δηλώνει ένα γεγονός που ήδη συνέβη: «δημιουργήθηκε η παραγγελία 58213». Ο αποστολέας δεν ξέρει και δεν τον ενδιαφέρει ποιος ακούει. Γι’ αυτό τα events ονομάζονται σε παρελθοντικό χρόνο.

Η μετάβαση από commands σε events είναι αυτό που αποσυνδέει τα συστήματα. Το e-shop δεν χρειάζεται πια να ξέρει ότι υπάρχει σύστημα αποθήκης. Η προσθήκη του προγράμματος επιβράβευσης γίνεται «subscribe στο order.created», όχι «άλλαξε το integration του e-shop και ξαναδοκίμασε τα πάντα».

Ένα καλό event είναι αυτάρκες: έχει event ID, τύπο, χρονική σήμανση, το επιχειρηματικό κλειδί (αριθμό παραγγελίας, κωδικό πελάτη όπως C-1042) και είτε τα σχετικά δεδομένα είτε έναν σύνδεσμο για να τα ανακτήσει κανείς.

{
  "eventId": "7f1c2e9a-4b1d-4c55-9a51-2d1f0b7c9e10",
  "type": "order.created",
  "occurredAt": "2026-10-23T09:14:02Z",
  "orderId": "58213",
  "customerId": "C-1042",
  "total": 184.50,
  "currency": "EUR",
  "lines": [{ "sku": "OL-500", "qty": 2 }]
}

Τα δομικά στοιχεία

Publish/subscribe

Στο pub/sub, οι producers δημοσιεύουν events σε ένα κανάλι με όνομα, και όσοι subscribers υπάρχουν παίρνουν από ένα αντίγραφο. Ο producer δημοσιεύει μία φορά· τη διανομή την αναλαμβάνει ο broker. Αυτό ακριβώς είναι το παράδειγμα της παραγγελίας: ένα event order.created, τρεις ή τέσσερις ανεξάρτητοι consumers.

Topics και queues

Οι δύο κλασικοί τύποι καναλιού:

Ένα queue παραδίδει κάθε μήνυμα σε έναν consumer. Πολλοί workers μπορούν να διαβάζουν το ίδιο queue για να μοιράσουν τον φόρτο, αλλά κάθε μήνυμα επεξεργάζεται μία φορά. Κατάλληλο για μοίρασμα δουλειάς.
Ένα topic παραδίδει κάθε μήνυμα σε κάθε subscription. Κατάλληλο για ανακοίνωση γεγονότων.

Οι σύγχρονοι brokers θολώνουν τα όρια. Στο Kafka, τα consumer groups μοιράζονται τα partitions ενός topic· στο Apache Pulsar, κάθε subscription σε ένα topic παίρνει όλα τα μηνύματα και οι consumers μέσα στο ίδιο subscription μπορούν να μοιράσουν τον φόρτο. Η ιδέα που αξίζει να κρατήσετε: ένα αντίγραφο ανά σύστημα που ενδιαφέρεται, μοιρασμένο ανάμεσα στους workers αυτού του συστήματος.

Ο broker

Producers και consumers δεν μιλούν ποτέ απευθείας. Ένας broker κρατά τα events μέχρι να τα επεξεργαστεί κάθε subscription. Από εκεί προέρχεται η ανθεκτικότητα: αν το CRM είναι εκτός λειτουργίας για μία ώρα, τα events του περιμένουν, ενώ η αποθήκη και η τιμολόγηση συνεχίζουν κανονικά.

Οι εγγυήσεις που έχετε (και αυτές που δεν έχετε)

Παράδοση at-least-once

Σχεδόν κάθε πρακτική υλοποίηση παραδίδει τουλάχιστον μία φορά. Ο consumer επεξεργάζεται ένα μήνυμα και μετά το επιβεβαιώνει (acknowledge). Αν «πέσει» ανάμεσα στα δύο, ο broker το ξαναστέλνει. Άρα οι consumers θα δουν περιστασιακά το ίδιο event δύο φορές. Το «exactly-once» υπάρχει σε περιορισμένες μορφές μέσα σε κάποιες πλατφόρμες, αλλά ανάμεσα σε έναν broker και ένα ERP δεν είναι κάτι στο οποίο πρέπει να βασίζεστε.

Idempotent consumers

Η απάντηση στο at-least-once είναι κάθε consumer να είναι idempotent: η επεξεργασία του ίδιου event δύο φορές έχει το ίδιο αποτέλεσμα με τη μία. Συνηθισμένες τεχνικές:

Αποθηκεύετε τα event IDs που έχετε επεξεργαστεί και παραλείπετε όσα έχετε ξαναδεί.
Χρησιμοποιείτε το επιχειρηματικό κλειδί ως φυσική προστασία: πριν δημιουργήσετε παραγγελία πώλησης για την web παραγγελία 58213, ελέγχετε αν υπάρχει ήδη.
Προτιμάτε λειτουργίες «ορισμού» («το απόθεμα του OL-500 είναι 12») αντί για «πρόσθεσης» («πρόσθεσε 2 στο απόθεμα»).

Σειρά μηνυμάτων

Η σειρά συνήθως εγγυάται μόνο μέσα σε ένα partition ή κλειδί, όχι σε όλο το topic, και οι παράλληλοι consumers μπορούν ούτως ή άλλως να επεξεργαστούν μηνύματα εκτός σειράς. Αν η σειρά μετράει (ένα order.cancelled δεν πρέπει να επεξεργαστεί πριν από το order.created του), στείλτε τα σχετικά events με το ίδιο κλειδί, π.χ. τον αριθμό παραγγελίας, και σχεδιάστε τους consumers ώστε να αντέχουν την περιστασιακή έκπληξη, για παράδειγμα ελέγχοντας την τρέχουσα κατάσταση πριν δράσουν.

Μηνύματα που αποτυγχάνουν

Κάποια μηνύματα θα αποτυγχάνουν κάθε φορά: πελάτης που λείπει, πεδίο με λάθος μορφή, προϊόν που δεν γνωρίζει το ERP. Χωρίς σχέδιο, αυτά τα poison messages μπλοκάρουν ένα subscription ή ξαναδοκιμάζονται για πάντα. Η καθιερωμένη λύση είναι περιορισμένος αριθμός retries και μετά ένα dead-letter topic ή queue, όπου κάποιος μπορεί να τα εξετάσει, να τα διορθώσει και να τα ξαναστείλει. Αυτό ακριβώς φτιάχνουμε στο Poison messages, retries και dead-letter topics στο Boomi Event Streams.

Πότε το event-driven είναι η σωστή επιλογή

Αξίζει όταν ισχύουν αρκετά από τα παρακάτω:

Ένα γεγονός, πολλά ενδιαφερόμενα συστήματα. Μια παραγγελία, ένας νέος πελάτης, μια αλλαγή τιμής που χρειάζονται τρία ή περισσότερα συστήματα.
Συστήματα με διαφορετική διαθεσιμότητα. Ένα cloud e-shop που δεν κοιμάται ποτέ και ένα on-premises ERP που κάνει backup κάθε βράδυ.
Αιχμές όγκου. Η κίνηση της Black Friday απορροφάται από τον broker και επεξεργάζεται με τον ρυθμό που αντέχει το ERP.
Συστήματα που έρχονται και φεύγουν. Νέοι consumers προστίθενται χωρίς να αγγίξετε τον producer.
Ο σχεδόν πραγματικός χρόνος μετράει, αλλά ο producer δεν χρειάζεται να περιμένει τους consumers.

Πότε κάτι άλλο είναι καλύτερο

Το event-driven δεν είναι η προεπιλογή. Άλλα στυλ είναι συχνά απλούστερα:

Το request-reply είναι καλύτερο όταν ο καλών χρειάζεται απάντηση τώρα: «υπάρχει απόθεμα;», «ποιο είναι το υπόλοιπο του πελάτη;». Μη φτιάχνετε διαδρομή με events για μια ερώτηση. (Δείτε Sync ή async integration στο Boomi για τα υπέρ και τα κατά.)
Το batch είναι καλύτερο όταν τα δεδομένα είναι από τη φύση τους περιοδικά και κανείς δεν κερδίζει από λίγα δευτερόλεπτα καθυστέρησης: η νυχτερινή αποστολή των τιμολογίων της ημέρας στο λογιστικό γραφείο ή οι μηνιαίες φορτώσεις σε data warehouse.
Μια απλή point-to-point ροή αρκεί όταν υπάρχει ακριβώς ένας consumer και αυτό δεν πρόκειται να αλλάξει.

Πολλά πραγματικά περιβάλλοντα χρησιμοποιούν και τα τρία: request-reply για ερωτήματα, events για αλλαγές κατάστασης, batch για αναφορές.

Συνηθισμένα λάθη

Events που στην ουσία είναι commands. Ένα event με όνομα createInvoiceInErp δένει ξανά τον producer με έναν consumer. Δημοσιεύστε order.created και αφήστε την τιμολόγηση να αποφασίσει τι θα κάνει.
Η υπόθεση του exactly-once. Το πρώτο διπλό τιμολόγιο συνήθως τελειώνει αυτή την πεποίθηση. Σχεδιάστε για διπλότυπα από την πρώτη μέρα.
Τεράστια ή μικροσκοπικά events. Events με ολόκληρο το παραστατικό του ERP δύσκολα εξελίσσονται· events μόνο με ένα ID αναγκάζουν κάθε consumer να ξαναρωτήσει την πηγή, που γίνεται το νέο σημείο συμφόρησης. Βάλτε ό,τι χρειάζονται οι περισσότεροι consumers.
Χωρίς πειθαρχία στο schema. Βάλτε εκδόσεις στις μορφές των events και προσθέτετε πεδία αντί να μετονομάζετε ή να αφαιρείτε. Μια κοινή μορφή event δουλεύει καλύτερα όταν ακολουθεί ένα canonical model (δείτε Canonical data model στο Boomi).
Χωρίς σχέδιο για αποτυχίες. Χωρίς dead-lettering και παρακολούθηση των backlogs, τα προβλήματα τα ανακαλύπτουν οι πελάτες.
Ο broker ως βάση δεδομένων. Η διατήρηση (retention) υπάρχει για ανάκτηση και replay, όχι για επιχειρηματικά ερωτήματα.

Πώς να συγκρίνετε εργαλεία

Πριν φτιάξετε λίστα προϊόντων, απαντήστε στις παρακάτω ερωτήσεις:

Τι όγκο και τι καθυστέρηση χρειάζεστε; Εκατοντάδες παραγγελίες την ημέρα και εκατομμύρια events τηλεμετρίας το λεπτό είναι διαφορετικά προβλήματα με διαφορετικά εργαλεία.
Χρειάζεστε replay; Οι log-based brokers κρατούν τα events για ένα διάστημα, ώστε οι consumers να ξαναδιαβάσουν το ιστορικό. Τα κλασικά queues σβήνουν τα μηνύματα μόλις καταναλωθούν.
Πού τρέχουν producers και consumers; Σε ένα cloud, σε πολλά, ή on-premises, όπως ένα ERP πίσω από firewall.
Ποιος γράφει producers και consumers; Developers που γράφουν κώδικα με client libraries, ή μια ομάδα integration που φτιάχνει ροές σε πλατφόρμα με connectors για ERP και CRM;
Managed ή self-hosted; Η σωστή λειτουργία ενός cluster brokers θέλει γνώσεις και χρόνο. Μια managed υπηρεσία μεταφέρει αυτή τη δουλειά στον vendor.
Τι γίνεται με αποτυχίες και παρακολούθηση; Δείτε πώς δουλεύουν στην πράξη τα retries, το dead-lettering, οι ειδοποιήσεις για backlogs και η εξέταση μηνυμάτων, όχι μόνο αν υπάρχουν.

Τα εργαλεία της αγοράς

Αυτά είναι τα προϊόντα που συναντάμε συχνότερα, με αλφαβητική σειρά.

Apache Kafka / Confluent. Το de facto πρότυπο για event streaming μεγάλου όγκου, με τεράστιο οικοσύστημα connectors και εργαλείων stream processing. Η Confluent προσφέρει managed cloud υπηρεσία και enterprise δυνατότητες πάνω στο open-source Kafka. Πολύ ισχυρό, αλλά η αυτοδιαχείρισή του θέλει πραγματική εξειδίκευση.
AWS EventBridge / SNS + SQS. Στο AWS, το EventBridge δρομολογεί events ανάμεσα σε υπηρεσίες και SaaS πηγές με κανόνες φιλτραρίσματος, ενώ ο συνδυασμός SNS (fan-out) και SQS (queues) είναι ένα δοκιμασμένο, απλό pattern pub/sub. Φυσική επιλογή όταν τα περισσότερα συστήματά σας τρέχουν ήδη στο AWS.
Azure Service Bus / Event Grid. Το Service Bus είναι ώριμος enterprise message broker με queues, topics, sessions για σειρά και ενσωματωμένα dead-letter queues· το Event Grid είναι ελαφριά υπηρεσία δρομολόγησης events. Δυνατή επιλογή για οργανισμούς που ήδη χρησιμοποιούν Azure.
Boomi Event Streams. Managed υπηρεσία event streaming, χτισμένη πάνω στο Apache Pulsar, που είναι μέρος της πλατφόρμας Boomi. Τα topics και τα subscriptions διαχειρίζονται δίπλα στα integration processes, και τα processes παράγουν και καταναλώνουν events μέσω ειδικού connector. Ταιριάζει καλύτερα όταν τα συστήματα που δημοσιεύουν και αντιδρούν σε events είναι ήδη συνδεδεμένα μέσω του Boomi Integration, ώστε ο broker και η λογική για ERP ή CRM να βρίσκονται στο ίδιο σημείο.
RabbitMQ. Πολύ διαδεδομένος open-source message broker με ευέλικτη δρομολόγηση (exchanges, queues, bindings). Εύκολος για αρχή και γνώριμος στους developers· χρησιμοποιείται συχνά για work queues και επικοινωνία ανάμεσα σε υπηρεσίες.
Solace. Event broker διαθέσιμος ως hardware, software και cloud υπηρεσία, γνωστός για το event mesh ανάμεσα σε clouds και on-premises εγκαταστάσεις και για την υποστήριξη πολλών πρωτοκόλλων. Συνηθισμένος σε χρηματοοικονομικά, βιομηχανία και άλλους κλάδους όπου μετράει η καθυστέρηση.

Αν ήδη χρησιμοποιείτε μία από αυτές τις πλατφόρμες για integration ή hosting, ξεκινήστε την αξιολόγηση από εκεί.

Επόμενα βήματα

Δύο πρακτικά άρθρα δείχνουν τα patterns αυτού του οδηγού στο Boomi:

Publish μία φορά, πολλοί consumers: pub/sub με το Boomi Event Streams: ένα event order.created για αποθήκη, τιμολόγηση και CRM.
Poison messages, retries και dead-letter topics στο Boomi Event Streams: retries, dead-letter topics και replay μετά τη διόρθωση.