Idempotency - לתכנן כאילו הכול יישלח פעמיים

אחרי שוויתרנו על סדר מוחלט, ואחרי שהבנו ש-Timeouts ו-Retries יכולים לגרום לאותה פעולה לקרות שוב - נשארת שאלה אחת קריטית:

מה קורה אם זה באמת קורה?

כפילויות אינן חריג - הן ברירת מחדל

בעולם מושלם, כל פעולה מתבצעת פעם אחת. בעולם אמיתי:

• בקשה יכולה להישלח שוב
• תשובה יכולה ללכת לאיבוד
• והמערכת לא תמיד יודעת מה כבר קרה

לכן, ההנחה הבטוחה אינה: “זה יקרה פעם אחת” אלא: “זה עלול לקרות שוב”.

Idempotency היא הדרך לחיות עם ההנחה הזו.

מה זה בעצם Idempotency

פעולה idempotent היא פעולה שגם אם תתבצע פעמיים - התוצאה הסופית תהיה זהה לביצוע אחד.

לדוגמה:

“קבע את הסטטוס ל-active” גם אם הבקשה תגיע פעמיים - המצב בסוף זהה.

לעומת זאת:

• “הוסף משתמש”
• “העבר סכום”
• “צור משאב חדש”

אלו פעולות שבהן ביצוע נוסף משנה מצב שוב.

Idempotency אינה אומרת “לא קורה פעמיים”. היא אומרת: גם אם כן - זה לא מזיק.

למה זה חשוב דווקא עכשיו

ברגע שיש:

• Retries
• עיבוד לא לפי סדר
• ו-Timeouts

המערכת כבר לא יכולה לדעת בוודאות: האם פעולה נכשלה - או פשוט הצליחה בלי שנדע.

בלי Idempotency: Retry עלול ליצור:

• כפילות נתונים
• שינוי מצב שקט
• או נזק שמתגלה הרבה אחר כך

עם Idempotency: Retry הופך לבטוח יותר - כי הפעולה עצמה סלחנית לכפילויות.

Idempotency כעיקרון ארכיטקטוני

Idempotency אינה תיקון נקודתי. היא דרך תכנון.

מערכת שמתוכננת כך:

• מניחה שכפילויות יקרו
• מגדירה זהות ברורה לפעולות
• ומוודאת שהשפעתן אינה מצטברת

מערכת שלא עושה זאת:

• נשענת על מזל
• או על הנחה ש-”זה לא יקרה”

ובסקייל - זה תמיד קורה.

הקשר ל-Retries ול-Failures

Retries בלי Idempotency הם הימור. Retries עם Idempotency הם כלי.

ההבדל אינו בקוד ה-Retry - אלא באופן שבו הפעולה עצמה מתנהגת.

כשל הוא בלתי נמנע. כפילות - לא חייבת להיות הרסנית.

המשל

אפשר לחשוב על כפתור “שמור”.

אם לחיצה כפולה שומרת פעמיים את אותו מצב - אין בעיה.

אם כל לחיצה יוצרת עותק חדש - לחיצה כפולה הופכת לבאג.

Idempotency היא ההבדל בין כפתור סלחני לבין כפתור מסוכן.

השורה התחתונה

Idempotency אינה אופטימיזציה. היא הגנה.

היא מאפשרת:

• לנסות שוב בלי לפחד
• לוותר על סדר בלי לאבד שליטה
• ולבנות מערכות שמחזיקות גם כשהעולם לא צפוי

מבט קדימה

גם עם Idempotency, עדיין צריך לבחור על מה לוותר כשיש בעיה.

לא הכול יכול להיות גם זמין וגם עקבי.

בפוסט הבא ניגע בבחירה הזו ישירות: Consistency מול Availability - לא כתיאוריה, אלא כהחלטה יומיומית שמשפיעה על משתמשים.