Σε ολόκληρες τις υπηρεσίες, συνήθως εμπορευόμαστε την ισχυρή συνέπεια για τελική συνέπεια, και βασιζόμαστε στο CQRS και το event sourcing για να το κάνουμε πρακτικό και ορθό.
Τελική συνέπεια
Μετά από μια αλλαγή, οι αντίγραφα συγκλίνουν "σύντομα" αντί για άμεσα. Αποδεκτό για τις περισσότερες επιχειρηματικές ροές (ένας αριθμός αποθέματος μπορεί να καθυστερήσει ένα δευτερόλεπτο), μη αποδεκτό για ορισμένα (έλεγχος υπολοίπου τραπεζικού λογαριασμού).
CQRS (Command Query Responsibility Segregation)
Διαχωρίστε το μοντέλο εγγραφής από ένα ή περισσότερα μοντέλα ανάγνωσης.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Οι αναγνώσεις κλιμακώνονται και αναδιαμορφώνονται ανεξάρτητα από τις εγγραφές· το μοντέλο ανάγνωσης ενημερώνεται από γεγονότα, επομένως είναι τελικά συνεπές.
Event sourcing
Αποθηκεύστε την ακολουθία γεγονότων ως πηγή αλήθειας, όχι μόνο την τρέχουσα κατάσταση. Η τρέχουσα κατάσταση είναι ένα fold στα γεγονότα.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
Ανταλλάγματα
| Τεχνική | Κέρδη | Κόστη |
|---|---|---|
| Τελική συνέπεια | Διαθεσιμότητα, κλιμάκωση | Παλαιές αναγνώσεις, συγκρούσεις |
| CQRS | Κλιμάκωση ανάγνωσης/εγγραφής | Δύο μοντέλα για συγχρονισμό |
| Event sourcing | Audit, αναπαραγωγή, ιστορικό | Εξέλιξη σχήματος/γεγονότος, πολυπλοκότητα |
Παγίδα
Μην υιοθετείτε το event sourcing παντού — είναι ισχυρό αλλά βαρύ. Χρησιμοποιήστε το όπου το audit/ιστορικό έχει πραγματικά σημασία.
Γιατί έχει σημασία
Τα διανεμημένα συστήματα δεν μπορούν να έχουν ταυτόχρονα ισχυρή συνέπεια, διαθεσιμότητα και ανοχή διαμέρισης, επομένως ο senior design αφορά την επιλογή του πού είναι αποδεκτή η τελική συνέπεια.
CQRS και event sourcing σας δίνουν τα εργαλεία για να κάνετε την τελική συνέπεια αξιόπιστη και ελεγμένη — αλλά το καθένα προσθέτει πραγματική πολυπλοκότητα, επομένως εφαρμόστε τα χειρουργικά, όχι εξ ορισμού.