Kafka

ביישומים מונוליטיים מסורתיים, שמירה על עקביות נתונים על פני ישויות מרובות היא פשוטה. מנועי מסד נתונים יחסיים מספקים ערבויות ACID (אטומיות, עקביות, בידוד, עמידות) עטופים בעסקאות SQL מקומיות. אם ביצוע הזמנה, ניכוי תשלום או עתודת מלאי נכשלים באמצע הדרך, הקריאה ROLLBACK תחזיר כל שינוי במסד הנתונים באופן מיידי. עם זאת, כאשר עוברים ל-Microservices Architecture מודרנית, ניהול הנתונים משתנה באופן מהותי. כדי להבטיח אוטונומיה של תחום ומדרגיות עצמאית, כל מיקרו-שירות הוא הבעלים של מסד הנתונים הפרטי שלו. פעולה עסקית אחת - כגון עיבוד קופה של מסחר אלקטרוני - משתרעת כעת על מספר גבולות שירות ומנועי מסד נתונים (למשל, PostgreSQL להזמנות, DynamoDB for Payments, Redis for Inventory).

בארכיטקטורת מיקרו-שירותים מבוססת אירועים (Event-Driven Architecture), שירותים מפיצים אירועים באופן קבוע (OrderCreated, PaymentProcessed) כדי לתקשר שינויי מצב באופן מנותק. עם זאת, הבטחת אמינות מלאה בפרסום אירועים מציבה אתגר קריטי: כיצד להבטיח שעדכון מסד הנתונים ופרסום האירוע יצליחו שניהם יחד או ייכשלו שניהם יחד? אם מיקרו-שירות מעדכן את מסד הנתונים המקומי שלו (PostgreSQL או MySQL) ולאחר מכן מנסה לשלוח הודעה ברשת לברוקר (כגון Apache Kafka או RabbitMQ), תקלת רשת עלולה לגרום לחוסר עקביות בנתונים.