Prime Day 2019: מיליוני קונים על Amazon. חלק מהם פתחו את עגלת הקניות וראו שמוצרים שהוסיפו לפני דקה נעלמו. מוצרים שמחקו חזרו. ה-cart לא שיקף את המציאות. האם זו תקלה? האם הנדסאים פאניקה ב-on-call? לא. זו החלטה ארכיטקטורית מכוונת של Amazon. ההנחה שעמדה מאחוריה: עדיף להראות cart ישן מאשר להציג דף 503 לקונה שמוציא כסף. זה CAP Theorem ב-production.
Eric Brewer הציג את ה-conjecture ב-2000 ב-PODC, Gilbert ו-Lynch הוכיחו אותו פורמלית ב-2002. מאז, זה אחד ה-rocks הבסיסיים של distributed systems design.
Werner Vogels, CTO של Amazon, כתב ב-2007 את ה-blog post המפורסם "Eventually Consistent" שהפך לתיאור הכי ברור של AP design decisions. הוא הסביר ש-Amazon בנתה DynamoDB ב-dependency ישיר על ה-Dynamo paper הפנימי שפורסם ב-2007 - paper שמתאר בדיוק איך מממשים AP system עם tunable consistency ו-eventual consistency. DynamoDB לא הייתה choice אקראית - היא הייתה implementation של years of painful lessons על trade-offs.
ה-insight העמוק ש-Vogels שיתף: חברות לרוב לא יודעות מראש את ה-consistency requirements של כל feature. DynamoDB מאפשר per-request consistency level - strongly consistent read ל-orders, eventually consistent read ל-product catalog. זה architectural flexibility ש-PostgreSQL single-node לא נותן.
ה-paper של Brewer נכתב ספציפית בהקשר של web services - הוא ראה שחברות בשנות 2000 המוקדמות מתמודדות עם אותה סוגיה שוב ושוב: האם לחסום access בזמן network issue כדי לשמור על consistency, או להמשיך לתת שירות עם data שאולי לא מעודכן. Amazon, eBay, ו-Yahoo - כולם התמודדו עם זה, ולכולם היו גישות שונות. Brewer formalized את ה-tradeoff.