IOSOR

IOSOR ידע

מתי מגבלת דייר מובנית חייבת לעצור את השליחה

מגבלות חלוקה הוגנת בתוך מוצר ISV חייבות לעצור לחלוטין את השליחה עבור אותו דייר — לעולם אל תחזיר API 200 מדומה של נמסר כאשר המגבלה מושגת.

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

מגבלות שמורות לשכבת המוצר של ה-ISV — הן אינן תחליף למגבלות קצב של דיירי-משנה אצל השותף, ואינן השלכה שקטה של הודעות בתור. עצירה אמיתית אומרת: ממשק ה-SaaS מראה הוקפא או הגיע למגבלה, השירות המובנה דוחה בקשות חדשות עבור מזהה הדייר הזה, וצוות התפעול יכול לייצא דוח של מי שהגיע למגבלה.

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

הגעה למגבלה פירושה סירוב להגשה, לא אזהרה רכה לנצח

אזהרות רכות הן התראות מוקדמות בלבד. במגבלה הקשיחה, השירות המובנה מחזיר שגיאת מגבלת דייר ואינו קורא ל-API ההודעות עבור בקשות חדשות. הודעות שכבר בתהליך יכולות להסתיים; בקשות OTP וקמפיינים חדשות ממתינות לאיפוס או לאישור העלאת מגבלה.

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

לעולם אל תפיק אישור מסירה מוצלחת במסלול מוגבל

תגובה מתי מותר אסור כאשר
מוצר מוגבל / מוקפא הגעה למגבלה קשיחה במסלול סירוב מגבלה
שגיאת HTTP / סטטוס מופה סירוב מגבלה —
נמסר / 200 הצלחה מסלול קבלה אמיתי במסלול סירוב מגבלה
השלכה שקטה לעולם לא תמיד
השלכה שקטה ותגובות 200 מדומות דומות לגלישת תור שמעמידה פני הצלחה.

התאם את מגבלות המוצר לקווי עצירת הארנק

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

בקשות להעלאת מגבלה דורשות מאשר מוסמך. העלאות עצמאיות ללא הגבלה הורסות את עקרון החלוקה ההוגנת.

בצע בדיקת עצירה בסביבת Staging עם דייר עמוס

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

נתיבי תפעול קשורים

התחל עם IOSOR

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

סיכום IOSOR

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

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

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

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