Reliability: Failures, Rate Limiting ו-Observability
אל דאגה אם המילים נשמעות מפחידות — נסביר כל אחת בדרך. בשיעור הזה נלמד איך לדבר בראיון על דרכים לשמור על מערכת יציבה גם כשמשהו משתבש: timeouts (פסק זמן — להפסיק לחכות לתשובה אחרי זמן מסוים, במקום להיתקע לנצח), retries (ניסיון חוזר — לנסות שוב בקשה שנכשלה), circuit breakers (מפסק — בדיוק כמו מפסק חשמל
System Design (תכנון מערכות — איך בונים תוכנה גדולה שמשרתת הרבה אנשים) הוא כמו לתכנן עיר: כבישים, מחסנים, רמזורים וצוותי תחזוקה — כך שהעיר תמשיך לעבוד בצורה חלקה גם בשעות העומס, כשכולם בחוץ באותו זמן.
- אמינות ותצפיתיות
- הרעיון המרכזי של השיעור: איך שומרים שהמערכת תישאר אמינה (תמשיך לעבוד) ושנוכל לראות מה קורה בתוכה. כולל: מתי להפסיק לחכות (timeouts), מתי לנסות שוב (retries), מתי לחסום זמנית כדי למנוע קריסה (circuit breakers — מפסק), איך להגביל כמה בקשות מותרות (rate limits), ואיך לעקוב אחרי המתרחש בעזרת metrics (מדדים), logs (יומנים) ו-tracing (מעקב אחרי בקשה).
- Trade-off
- Trade-off (פשרה) — בחירה מודעת שבה מרוויחים דבר אחד ומשלמים על זה במשהו אחר, כמו לבחור אוכל מהיר במקום ארוחה ביתית: חוסכים זמן אבל מאבדים באיכות. בראיון מסבירים מה הרווחנו ומה שילמנו.
- מדד תפעולי
- מדד תפעולי — מספר שמראה אם ההחלטה באמת עובדת כשהמערכת חיה ומשרתת משתמשים אמיתיים (זה נקרא production, פרודקשן). לדוגמה: latency (כמה זמן לוקח לקבל תשובה), error rate (אחוז הבקשות שנכשלות), queue lag (כמה משימות ממתינות בתור), cache hit ratio (כמה פעמים מצאנו את התשובה בזיכרון המהיר) ועוד.