שאלות ראיון System Design 2026 — 33 שאלות ותשובות

ראיון System Design בודק את היכולת לתכנן מערכת בקנה מידה גדול: איך מסקיילים, איפה מוסיפים caching, איך מפרקים למיקרו-שירותים, ואיך מאזנים בין עקביות לזמינות. אין תשובה אחת נכונה — בוחנים את דרך החשיבה. עם 1,952 משרות פעילות ב-HiTakeJob, ריכזנו 21 שאלות ליבה עם תשובות.

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

כל תשובה טובה ב-System Design מרכיבה יחד כמה אבני בניין. הטבלה מסכמת את המרכזיות:

רכיב	מה הוא פותר
Load Balancer	חלוקת עומס וזמינות
Cache (Redis)	האצת קריאות והורדת עומס מהמסד
Message Queue	עיבוד אסינכרוני והחלקת עומסים
Sharding	סקיילינג כתיבה ואחסון
Replication	זמינות וקריאות מהירות

עקרונות סקיילינג

מה ההבדל בין סקיילינג אנכי לאופקי?

אנכי (scale-up) מחזק שרת בודד ביותר משאבים — פשוט אך מוגבל ומהווה נקודת כשל. אופקי (scale-out) מוסיף שרתים ומחלק עומס — מורכב יותר לניהול אך גמיש, עמיד וכמעט בלתי מוגבל.

מהו Load Balancer ואילו אלגוריתמים הוא מפעיל?

Load Balancer מחלק בקשות בין שרתים. אלגוריתמים נפוצים: Round Robin (בתורות), Least Connections (לשרת הפחות עמוס), ו-IP Hash (עקביות לפי משתמש). הוא גם מנתב הלאה משרתים כושלים.

מהו Stateless service ולמה הוא חשוב לסקייל?

שירות שאינו שומר מצב לקוח בין בקשות — כל בקשה עומדת בפני עצמה. זה מאפשר לנתב כל בקשה לכל שרת ולהוסיף/להסיר שרתים בחופשיות. המצב מנוהל חיצונית (מסד נתונים, cache).

מהי חשיבות ה-CAP Theorem?

משפט CAP קובע שבמערכת מבוזרת אפשר להבטיח לכל היותר שניים מתוך שלושה: Consistency, Availability ו-Partition tolerance. מכיוון ש-partitions בלתי נמנעות, בפועל בוחרים בין עקביות לזמינות.

Caching והאצה

מהו Caching ואילו רמות cache קיימות?

Caching שומר תוצאות בגישה מהירה כדי לחסוך חישוב או שאילתה חוזרת. רמות: cache בצד לקוח, CDN, cache אפליקטיבי (Redis), ו-cache של מסד הנתונים. כל שכבה מפחיתה עומס מהשכבה שמתחתיה.

מהי אסטרטגיית Cache Invalidation?

קביעה מתי לרענן או למחוק ערך מה-cache כדי למנוע נתונים מיושנים. גישות: TTL (תפוגה לפי זמן), write-through (עדכון cache בכל כתיבה), ו-write-back. Cache invalidation נחשב מהאתגרים הקשים בהנדסה.

מה תפקיד Redis בארכיטקטורה?

Redis הוא מאגר נתונים בזיכרון (in-memory) מהיר במיוחד, שמשמש ל-caching, ניהול sessions, תורים, ו-rate limiting. מהירותו נובעת מכך שהנתונים בזיכרון RAM. ראו משרות Redis.

מה ההבדל בין cache hit ל-cache miss ואיך מודדים יעילות?

cache hit הוא כשהנתון נמצא ב-cache, ו-cache miss כשצריך לפנות למקור. מודדים ב-hit ratio (אחוז ה-hits). יחס גבוה מעיד על caching יעיל; יחס נמוך אומר שכדאי לשנות אסטרטגיה או גודל cache.

מסדי נתונים בקנה מידה

מהו Database Sharding?

חלוקה אופקית של נתונים למספר מסדי נתונים (shards) לפי מפתח (למשל user_id). כל shard מחזיק חלק מהנתונים, מה שמאפשר לסקייל מעבר ליכולת שרת בודד. האתגר: שאילתות חוצות shards וריבּלנסינג.

מה ההבדל בין Replication ל-Sharding?

Replication מעתיק את אותם נתונים למספר שרתים לזמינות וקריאות מהירות. Sharding מפצל נתונים שונים בין שרתים לסקיילינג כתיבה ואחסון. לרוב משלבים את שניהם: כל shard מְשוכפל.

מה ההבדל בין SQL ל-NoSQL ברמת ארכיטקטורה?

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

מהי Eventual Consistency?

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

מיקרו-שירותים ותקשורת

מה ההבדל בין מונוליט למיקרו-שירותים?

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

מהו Message Queue ומתי משתמשים בו?

תור הודעות (כמו Kafka או RabbitMQ) מנתק בין מפיק לצרכן ומאפשר עיבוד אסינכרוני. הוא מחליק עומסים (buffering), מגביר עמידות (הודעות נשמרות בכשל), ומאפשר לרכיבים לעבוד בקצב שלהם.

מה ההבדל בין תקשורת סינכרונית לאסינכרונית?

סינכרונית (REST/gRPC) — הקורא ממתין לתשובה, פשוט אך יוצר צימוד ותלות בזמינות. אסינכרונית (דרך תור) — הקורא לא ממתין, מה שמגביר עמידות וסקייל אך מוסיף מורכבות בעקיבות ובעקביות.

מהו Circuit Breaker?

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

אמינות וניטור

מהו Single Point of Failure וכיצד מסירים אותו?

SPOF הוא רכיב שכשלו מפיל את כל המערכת. מסירים אותו ביתירות: מספר שרתים, מספר Availability Zones, שכפול מסד נתונים, ו-Load Balancers כפולים. המטרה שאף רכיב בודד לא יהיה קריטי.

מהו Rate Limiting ולמה הוא חשוב?

הגבלת מספר הבקשות שלקוח יכול לשלוח בפרק זמן. הוא מגן מפני עומס יתר, שימוש לרעה (abuse) והתקפות DoS, ומבטיח חלוקה הוגנת של משאבים. לרוב ממומש עם אלגוריתם כמו token bucket.

איך ניגשים לשאלת System Design בראיון?

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

API ותקשורת בין שירותים

מה ההבדל בין REST ל-gRPC?

REST מבוסס HTTP/JSON, קריא, נפוץ ונוח לדיבוג. gRPC מבוסס HTTP/2 ו-Protocol Buffers — בינארי, מהיר יותר, עם streaming דו-כיווני. gRPC מתאים לתקשורת פנימית בין שירותים בעלת ביצועים גבוהים, REST לממשקים ציבוריים.

מהו API Gateway ומה תפקידו?

נקודת כניסה יחידה שמנתבת בקשות לשירותים המתאימים, ומרכזת אחריות רוחבית: אימות, rate limiting, caching, ולוגים. הוא מפשט את הצד הלקוח ומסתיר את המבנה הפנימי של המיקרו-שירותים.

מהי אסטרטגיית Idempotency ב-API ולמה היא חשובה?

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

עקביות ועסקאות מבוזרות

מהו דפוס Saga לעסקאות מבוזרות?

במקום טרנזקציה יחידה חוצת-שירותים, Saga מפרק אותה לסדרת פעולות מקומיות, שלכל אחת יש פעולת פיצוי (compensating action) לביטול במקרה כשל. כך שומרים על עקביות בלי נעילה חוצת-מערכת.

מהו Outbox Pattern?

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

דוגמת תכנון: קיצור כתובות URL

איך תעצב שירות לקיצור כתובות (כמו bit.ly)?

מייצרים מזהה קצר וייחודי (למשל base62 של מונה או hash), שומרים מיפוי בין הקוד לכתובת המקורית במסד נתונים, ומוסיפים שכבת cache לקריאות התכופות. מכיוון שיחס הקריאות לכתיבות גבוה מאוד, מתכננים קודם לקריאה — cache, שכפול, ו-CDN.

איך תסקיל את השירות למיליארדי כתובות?

מבצעים sharding של מסד הנתונים לפי המזהה הקצר, מוסיפים cache מבוזר (Redis) לקישורים החמים, ומפזרים את שכבת האפליקציה מאחורי Load Balancer. הפעולה הקריטית — הפניה (redirect) — חייבת להיות מהירה, ולכן שואפים ל-cache hit ratio גבוה.

איך תעריך את הקיבולת (capacity estimation) לשירות כזה?

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

סקיילינג אנכי מול אופקי — טבלת השוואה

הבחירה בין שתי גישות הסקיילינג היא שאלת יסוד. הטבלה מסכמת את ההבדלים:

קריטריון	אנכי (Scale-up)	אופקי (Scale-out)
שיטה	חיזוק שרת בודד	הוספת שרתים
מגבלה	תקרת חומרה	כמעט בלתי מוגבל
זמינות	נקודת כשל בודדת	עמידה בכשלים
מורכבות	נמוכה	גבוהה יותר

טעויות נפוצות בראיון System Design

אלה הדפוסים שמפילים מועמדים גם עם ידע טכני חזק:

• קפיצה לפתרון בלי הבהרת דרישות: לא לשאול על היקף, QPS ותרחישים לפני שמתחילים לתכנן — טעות מספר אחת.
• מונולוג במקום דיאלוג: ראיון עיצוב הוא שיחה. מי שלא מזמין משוב ולא בוחן חלופות מפספס את המטרה.
• over-engineering: להוסיף מיקרו-שירותים, sharding ו-Kafka לבעיה שלא דורשת אותם — מסגיר חוסר שיקול דעת.
• התעלמות מפשרות: כל החלטה היא trade-off. לטעון שפתרון "פשוט טוב" בלי לנמק מול חלופה נראה שטחי.
• שכחת נקודות כשל וניטור: עיצוב בלי SPOF removal, התראות ו-observability אינו שלם.

צ'קליסט הכנה לראיון System Design

ודאו כיסוי של הנקודות הבאות לפני הראיון:

• לתרגל מסגרת גישה: הבהרת דרישות ← הערכת סקייל ← עיצוב גבוה ← העמקה ← צווארי בקבוק.
• לשלוט באבני הבניין: Load Balancer, cache, queue, sharding ו-replication.
• להבין caching לעומק: אסטרטגיות invalidation ו-hit ratio.
• לתרגל תכנון מערכות מוכרות בקול רם: קיצור URL, פיד חברתי, צ'אט.
• להכיר CAP, eventual consistency ומתי כל אחד מתאים.
• לתרגל capacity estimation גס: QPS, אחסון ורוחב פס.

איך להתכונן לראיון System Design

תרגלו תכנון מערכות מוכרות (קיצור URL, פיד חברתי, צ'אט) בקול רם, וצללו לפשרות. הבינו היטב caching, תורים ומסדי נתונים. ראו משרות מיקרו-שירותים, משרות Redis ואת כלל המשרות. השלימו עם שאלות ראיון Backend ושאלות ראיון Cloud ו-AWS.

שאלות נפוצות

למי מיועד ראיון System Design?

בעיקר למפתחים ברמת Mid ומעלה, ולתפקידי Backend, DevOps ו-SRE. בחברות גדולות זהו שלב מרכזי בתהליך. עם 1,952 משרות פעילות בישראל, שליטה בעיצוב מערכות היא מבדל משמעותי בין מועמדים.

איך מתכוננים לראיון System Design ללא ניסיון בקנה מידה גדול?

לומדים את דפוסי היסוד (סקיילינג, caching, תורים, sharding), מתרגלים תכנון מערכות ידועות, ומנתחים ארכיטקטורות אמיתיות שפורסמו. חשוב להראות חשיבה מובנית ומודעות לפשרות, לא לשנן פתרון יחיד.

מה מחפשים המראיינים בראיון System Design?

חשיבה מובנית, שאלות הבהרה נכונות, מודעות לפשרות (trade-offs), ויכולת להצדיק החלטות. פחות מחפשים "התשובה הנכונה" ויותר את איך אתם מתמודדים עם עמימות וכיצד אתם מנמקים בחירות ארכיטקטוניות.

כמה זמן צריך להקדיש להכנה לראיון System Design?

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

האם צריך לזכור מספרים מדויקים (latency numbers)?

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

מה ההבדל בין ראיון System Design לראיון קידוד?

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