Transactions - ACID Properties
2003, Bank of America. בשל bug בקוד, כסף הועבר מחשבונות A לחשבונות B - אבל ה-credit לחשבון B לא הושלם תמיד. לקוחות ראו כסף יוצא מהחשבון שלהם אבל לא מגיע ליעד. $10 מיליון "נעלמו" בפועל. התיקון לקח ימים ועלה בביטחון לקוחות. Root cause: transaction handling לא נכון.
Transactions הם לא feature נחמד - הם ה-primitive שמאפשר לבנות מערכות כספיות, מלאי, ו-booking systems בלי race conditions. מי שמבין transactions מבין למה relational databases עדיין רלוונטיים בעידן ה-NoSQL.
הבעיה שtransactions פותרות קיימת בכל מערכת שמבצעת כמה פעולות שצריכות להיות atomic.
ב-2012, Groupon פרסמו post-mortem על bug שגרם לcoupons ל"להימכר" יותר פעמים ממה שנשארו במלאי. הבעיה: שני requests בו-זמנית בדקו "כמה coupons נשארו" (נניח 5), שניהם ראו 5, שניהם הרשו purchase, והcount ירד לminus. בלי proper locking בתוך transaction, הrace condition הזה הוא צפוי. ה-fix: SELECT FOR UPDATE בתוך transaction לcompute ולdecrement atomically. מהbug הפשוט הזה למדו lesson שכל e-commerce developer צריך להכיר: inventory operations חייבות להיות atomic, תמיד. Booking system: רזרבציה + תשלום + עדכון מלאי. E-commerce: יצירת order + הורדת stock + חיוב כרטיס. User registration: יצירת account + שליחת email verification + יצירת preferences. בכל אחד מהמקרים, failure בפעולה האמצעית בלי rollback = corrupted state.
2013, Knight Capital Group, חברת trading שוול סטריט. Bug בdeploy גרם לalgorithm לרוץ בתצורה שגויה. בתוך 45 דקות, הם הפסידו $440 מיליון - כמה שנים של רווחים. חלק מהבעיה: פעולות trading שהתבצעו ללא proper transaction handling, גרמו ל-position שלא אפשר היה לrollback. transactions נכונות לא היו פותרות את הבעיה בכדי, אבל היו מגבילות את הנזק.