פלטפורמת n8n היא כלי workflow בקוד פתוח שמאפשר לעסק קטן לחבר APIs, מודלי שפה ומסדי נתונים בלי לכתוב backend, והמדריך החדש של בלוג n8n על throttling מול rate limiting משלים את מה שחסר לרוב הצוותים. הכלל המעשי: כש-API מחזיר שגיאת 429, קוראים קודם את ה-header של Retry-After, ואז מוסיפים exponential backoff עם jitter כדי שהרצות מקבילות לא ינסו שוב בדיוק באותו רגע וייפגעו באותו קיר.
המאמר מפריד שני מונחים שמתבלבלים זה בזה. rate limiting פשוט דוחה בקשות עודפות עם שגיאת 429, כך שהזרימה חייבת לעצור ולנסות מחדש. throttling, לעומת זאת, מעכב או מכניס את הבקשה לתור, כך שהזרימה רואה תגובה איטית יותר והצעדים הבאים צריכים לדעת לחיות עם ההשהיה. המדריך גם עובר על fixed windows, sliding windows, token buckets ו-leaky buckets - אסטרטגיית קצב שעובדת מול API אחד יכולה להיכשל בשקט מול אחר.
מה זה אומר לעסק קטן בישראל
כל זרימה שנוגעת ב-OpenAI, Anthropic, Google, מערכת CRM או parser חשבוניות של הבנק תפגוש מגבלות ברגע שה-batch גדל מעבר לדמו. בלי backoff נכון, חצי מהלידים של המרפאה, החוזים של משרד עורכי הדין או עמודי המכרז של הסטארטאפ פשוט נזרקים ואף אחד לא שם לב שבוע. בפייפליין ניתוח מכרזים שבניתי, מסמכים בני 100 עמודים עוברים OCR ו-LLM במקביל, והיציבות שומרת על עצמה רק כי שגיאות 429 נתפסות, Retry-After מכובד, ו-jitter מפזר את הניסיונות החוזרים בין העובדים השונים.
למה זה חשוב: אם האוטומציה שלך מעבדת יותר מכמה פריטים בריצה, דפוס הטיפול ב-429 שהמדריך של n8n מתאר הוא ההבדל בין זרימה שמחזיקה נפחים אמיתיים לבין כזו שמאבדת נתונים בשקט תחת עומס.
מקור: n8n Blog