ניסיונות חוזרים ומניעת כפילויות

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

הלוח

בסך הכול כ-21 שעות, מספיק כדי לעבור פריסה, חידוש תעודה ורוב התקלות. המרווחים הקצרים בהתחלה תופסים את הכשלים הרגעיים, והארוכים בסוף נותנים לצוות זמן לתקן בלי שהיעד יוצף. יעד שצריך משהו אחר מקבל לוח משלו:

curl -X PATCH https://api.hookget.com/v1/endpoints/ep_… \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -d '{"retry_schedule":[0,10,60,300],"max_attempts":4}'

מניעת כפילויות משני הצדדים

בצד המפרסם. שלחו מפתח ייחודיות (idempotency key) עם הפרסום, ואותו מפתח לעולם לא ייצור אירוע שני, לא משנה כמה פעמים התשתית שלכם עצמה שולחת את הבקשה מחדש. זה חשוב כי גם הקריאה שלכם ל-API יכולה ליפול באמצע, ואז אין לכם דרך לדעת אם האירוע נשמר. עם מפתח, פשוט שולחים שוב.

-d '{"type":"order.created","payload":{…},"idempotency_key":"ord_10241-created"}'

בצד הצרכן. webhook-id נשאר קבוע בכל ניסיון חוזר של אותה מסירה. שמרו אותו והתעלמו מכל מה שכבר טיפלתם בו:

const id = headers['webhook-id'];
if (await seen(id)) return res.status(200).end();   // already handled
await handle(event);
await remember(id);                                  // then remember it
res.status(200).end();

הסדר בקוד הזה מכוון. קודם בודקים אם המזהה כבר הופיע, ואם כן עונים 200 ולא עושים כלום, כי מבחינת השולח המסירה הצליחה. אחר כך מטפלים באירוע, ורק בסוף שומרים את המזהה, כדי שכשל באמצע הטיפול לא יסמן את האירוע כמטופל.

מה עוצר את הלוח מוקדם