IOSOR

IOSOR ידע

Webhooks של SMS נכנס: ניסיונות חוזרים, סדר אירועים, ואידמפוטנטיות בקבלה

מדריך בנייה לצוותי B2B המטפלים ב-SMS נכנס: מדוע מתרחשים ניסיונות חוזרים, מדוע סדר האירועים אינו מובטח, וכיצד להפוך את נקודת הקצה שלכם לקבלה לאידמפוטנטית במקום לשכפל שיחות וטיפול ב-STOP.

כל מטפל בהודעות נכנסות נתקל בסופו של דבר באותן שלוש הפתעות: אותו webhook מופעל פעמיים, אירוע "delivered" מגיע אחרי ה-"failed" שהיה אמור להחליף, ותגובת STOP של לקוח מעובדת פעמיים כי שני שרתים קיבלו את אותו ניסיון חוזר. אף אחד מאלה אינו באג בפלטפורמה השולחת לכם את ה-webhook — זו התנהגות רגילה של כל מערכת אספקה "לפחות פעם אחת", ונקודת הקצה לקבלה שלכם חייבת להיבנות למציאות הזו מהיום הראשון.

IOSOR מספקת SMS נכנס, מילות מפתח STOP/HELP, ואירועי מסירה כ-webhooks בתשלום מראש white-label — התנהגות הניסיון החוזר והסדר המתוארת להלן היא מה שכל אינטגרציית B2B רצינית צריכה להניח, ללא קשר לאיזו פלטפורמה עומדת מאחוריה.

מדוע webhooks מנסים שוב בכלל

ספק webhook לא יכול לדעת בוודאות שנקודת הקצה שלכם עיבדה מסירה. השרת שלכם עשוי להחזיר 200 לאחר commit למסד נתונים שאז עובר rollback; מאזן עומסים עשוי לאבד את התגובה בדרך חזרה למרות שהמטפל שלכם הצליח; פריסה עשויה להפעיל מחדש את התהליך שלכם באמצע בקשה.

שלושת מצבי הכשל שעליכם לתכנן עבורם

מצב כשל מה קורה מה נשבר אם תתעלמו
מסירה כפולה אותו מזהה אירוע מגיע 2+ פעמים תגובות נספרות פעמיים, עיבוד STOP כפול, שרשורי שיחה כפולים
אירועים לא בסדר אירוע עם חותמת זמן מאוחרת יותר מגיע לפני אחד מוקדם יותר סטטוס "delivered" נכתב מחדש חזרה ל-"sent"
כשל חלקי/מעורפל המטפל שלכם עיבד את האירוע אבל האישור אבד הספק מנסה שוב משהו שכבר עשיתם

אידמפוטנטיות: התכונה האחת שפותרת את שלושתם

נקודת קצה לקבלה אידמפוטנטית מייצרת את אותו מצב סופי לא משנה כמה פעמים אותו אירוע נמסר. המנגנון פשוט ומובן היטב: כל אירוע נכנס נושא מזהה אירוע ייחודי; לפני העיבוד, אתם בודקים אם כבר תיעדתם את המזהה הזה; אם כן, אתם מחזירים הצלחה מיד ללא עיבוד מחדש. 1. חלצו את מזהה האירוע/ההודעה של הספק מה-payload — לעולם אל תמציאו משלכם מחותמת זמן + גוף, מכיוון שניסיונות חוזרים עשויים להזיז חותמות זמן במילישניות. 2.

סדר אירועים: מדוע "הכתיבה האחרונה מנצחת" מסוכן

אירועי webhook לאותה הודעה לא מובטחים להגיע בסדר שבו התרחשו. ניסיון חוזר של אירוע "queued" מוקדם יותר עשוי להגיע אחרי אירוע "delivered" מאוחר יותר בשל ריצוד רשת, תורים בצד הספק, או מאגר העובדים שלכם עצמו המעבד בקשות שלא בסדר. אם המטפל שלכם פשוט כותב מחדש את עמודת הסטטוס של ההודעה עם מה שהגיע זה עתה, אירוע ישן שהגיע באיחור עלול להחזיר בשקט הודעה שנמסרה למצב מוקדם יותר.

STOP, HELP, ומילות מפתח נכנסות אחרות זקוקות לאותו משמעת

מילות מפתח נכנסות קריטיות לציות ראויות לאידמפוטנטיות המחמירה ביותר מכולן. STOP כפול לעולם לא צריך לתעד פעמיים אירוע הסרה או לשלוח שתי תגובות אישור. HELP כפול לעולם לא צריך להפעיל שתי הודעות מידע תמיכה נפרדות לאותו מספר באותה דקה.

התחילו עם IOSOR

משכו את יומני ה-webhook הנכנסים של השבוע וספרו מזהי אירוע שהגיעו יותר מפעם. נגנו כפיל אחד וזוג שלא לפי סדר (failed ואז delivered). המקלט שומר אפקט אחד: שורת inbox אחת, כתיבת STOP אחת, נגיעת ארנק אחת. Last-write-wins שמבטל STOP מפיל. זו אידמפוטנטיות בקליטה וסדר ניסיונות חוזרים, לא אימות חתימה ולא מנעול שער לפני התור.

סיכום IOSOR

Webhook נכנס מנסה שוב. אידמפוטנטיות בקליטה היא התשובה הבטוחה היחידה; סדר אינו הבטחה.

עשו: מפתחו את האירוע והתעלמו מהתאום. אל תעשו: last-write-wins על STOP או חיוב אותו אירוע פעמיים.

האם המדריך הזה עזר?

מדריכים קשורים