*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)*
**עזרו [לתרגם](TRANSLATIONS.md) את המדריך!**
# המדריך לתכנון מערכות (The System Design Primer)
## מוטיבציה
> ללמוד איך לתכנן מערכות ב-scale גדול.
>
> להתכונן לראיונות ארכיטקטורה.
### ללמוד איך לתכנן מערכות ב-scale גדול
ללמוד כיצד לתכנן מערכות סְקֵילָבִּילִיוּת יסייע לך להפוך למהנדס תוכנה טוב יותר.
תכנון מערכות הוא נושא רחב. יש **כמות אדירה של משאבים ברחבי הרשת** על עקרונות של תכנון מערכות.
ה-repo הזה הוא **אוסף מסודר** של משאבים שנועדו לעזור לך ללמוד איך לבנות מערכות ב-scale.
### ללמוד מקהילת הקוד הפתוח
מדובר בפרויקט קוד פתוח (open source) שמתעדכן באופן מתמשך.
מוזמנים [לתרום!](#contributing)
### להתכונן לראיונות ארכיטקטורה
בנוסף לראיונות קידוד, ארכיטקטורה היא **רכיב נדרש** כחלק מתהליך **ראיונות טכניים** בהרבה חברות טכנולוגיות.
**תוכל לתרגל שאלות ארכיטקטורה נפוצות** ואף **להשוות** את התוצאות שלך עם **פתרונות לדוגמה**: דיונים, קוד, ודיאגרמות.
### נושאים נוספים להכנה לראיונות:
## כרטיסיות Anki
החבילות המוכנות של כרטיסיות [Anki](https://apps.ankiweb.net/) משתמשות בשיטת **חזרתיות מבוססת מרווחים (Spaced Repetition)** כדי לעזור לך לזכור מושגים חשובים בתכנון מערכות.
מומלצות לשימוש בדרכים.
### משאב לראיונות קידוד: אתגרי קידוד אינטראקטיביים
מחפש משאבים שיעזרו לך להתכונן [**לראיונות קידוד**](https://github.com/donnemartin/interactive-coding-challenges)?
תעיף מבט על ה-repo המקביל [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), שמכיל חבילת Anki נוספת:
## תרומה למדריך
> ללמוד מהקהילה.
אל תהסס להגיש pull requests כדי לעזור:
תכנים שעדיין דורשים ליטוש מסומנים בתור
תחת פיתוח.
מומלץ לעיין ב
הנחיות לתרומה לפני התחלה.
## אינדקס נושאים בארכיטקטורה
> סיכומים של נושאים שונים בתכנון מערכות, כולל יתרונות וחסרונות. **כל החלטה כוללת פשרות (trade-offs)**.
>
> כל חלק מכיל קישורים להרחבה וללמידה מעמיקה יותר.
אינדקס נושאים
## מדריך למידה
> נושאים מוצעים ללימוד לפי לוח הזמנים לריאיון שלך (קצר, בינוני, ארוך)
**ש: עבור הראיונות, האם אני אמור לדעת כל מה שכתוב כאן?**
**ת: לא, אתה לא צריך לדעת הכול כדי להתכונן לריאיון**.
מה שאתה תישאל עליו בריאיון תלוי בדברים כגון:
- כמה ניסיון יש לך
- מה הרקע הטכני שלך
- לאילו משרות אתה מתראיין
- באילו חברות אתה מתראיין
- מזל
לרוב מצופה ממועמדים מנוסים יותר לדעת יותר על ארכיטקטורה ותכנון מערכות. ארכיטקטים או ראשי צוותים מצופים לדעת יותר מאשר עובדים בודדים. חברות טכנולוגיות מובילות לרוב יערכו ריאיון אחד או יותר של ארכיטקטורה.
רצוי להתחיל רחב ולהעמיק במספר תחומים. זה עוזר לדעת קצת בנוגע למספר נושאי מפתח בתכנון מערכות. תתאים את המדריך לפי לוח הזמן שלך, הניסיון, המשרות שאתה מתראיין אליהן, והחברות שבהן אתה מתראיין.
- לוח זמנים קצר – התמקד ברוחב של נושאים בתכנון מערכות. תרגל פתרון של כמה שאלות ריאיון.
- לוח זמנים בינוני – התמקד ברוחב וקצת עומק של נושאים בתכנון מערכות. תרגל פתרון של הרבה שאלות ריאיון.
- לוח זמנים ארוך – התמקד ברוחב ויותר עומק של נושאים בתכנון מערכות. תרגל פתרון של רוב שאלות הריאיון.
## איך לגשת לשאלת ריאיון ארכיטקטורה
> איך לפתור שאלת ראיון ארכיטקטורה.
ראיון ארכיטקטורה הוא **שיחה פתוחה**. מצופה ממך להוביל אותה.
אתה יכול להיעזר בצעדים הבאים כדי להנחות את הדיון. כדי לחזק את ההבנה של התהליך, תעבור על [שאלות ריאיון בתכנון מערכות עם פתרונות](#system-design-interview-questions-with-solutions) אל מול הצעדים הבאים:
### תאר מקרי שימוש, אילוצים והנחות עבודה
אסוף דרישות והגדר את ה-scope של הבעיה.
שאל שאלות כדי להבהיר את מקרי השימוש והאילוצים. דון בהנחות העבודה שאתה עושה.
- מי הולך להשתמש במערכת?
- איך הם הולכים להשתמש בה?
- כמה משתמשים יהיו?
- מה המערכת עושה?
- מה הקלטים והפלטים של המערכת?
- בכמה דאטא נצטרך לטפל?
- כמה בקשות לשניה מחכות לנו?
- מה היחס הצפוי בין קריאה לכתיבה?
### שלב 2: כתוב תכנון במבט על (high level design)
כתוב תכנון high level עם כל הרכיבים החשובים.
- שרטט את הרכיבים החשובים והקשרים ביניהם
- תצדיק את הרעיונות שלך
### שלב 3: תכנן את הרכיבים המרכזיים
צלול לפרטים של כל רכיב מרכזי. לדוגמה, אם התבקשת לתכנן [שירות קיצור כתובות url](solutions/system_design/pastebin/README.md), דון בנושאים הבאים:
- יצירה ואחסון hash של ה-url המלא
- דרכים כמו MD5 ו-Base62
- התנגשויות hash
- מסד נתונים SQL או NoSQL
- סכמת הנתונים
- המרה של כתובת מקוצרת לכתובת המלאה
- תכנון API ותכנון מונחה עצמים
### שלב 4: תבצע scale לתכנון
זהה וטפל בצווארי בקבוק, בהתאם לאילוצים. למשל, האם תזדקק לאחד מהפתרונות הבאים כדי להתמודד עם בעיות של סקילביליות?
- מאזן עומסים (Load balancer)
- סקיילינג אופקי (Horizontal scaling)
- שמירה במטמון (Caching)
- פיצול בסיס נתונים (Database sharding)
דון בפתרונות אפשריים וה-trade-offs. הכול הוא trade-off. התמודד עם צווארי בקבוק בעזרת [עקרונות תכנון מערכת סקילבילית](#index-of-system-design-topics).
### חישובים "על גב המעטפה" (מהירים)
ייתכן שיבקשו ממך לבצע הערכות באופן ידני. ראה את [הנספח](#appendix) עבור המשאבים הבאים:
* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
* [Powers of two table](#powers-of-two-table)
* [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know)
### מקורות לקריאה נוספת
עיין בקישורים הבאים כדי להבין טוב יותר למה לצפות:
* [How to ace a systems design interview](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
* [The system design interview](http://www.hiredintech.com/system-design)
* [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70)
* [System design template](https://leetcode.com/discuss/career/229177/My-System-Design-Template)
## שאלות ריאיון תכנון מערכות עם פתרונות
> שאלות נפוצות בריאיון ארכיטקטורה עם הסברים לדוגמה, קוד, ודיאגרמות.
>
> הפתרונות מפנים לתוכן שנמצא בתיקיית `solutions/`.
שאלה |
פתרון |
תכנן את pastebin.com (או bit.ly) |
פתרון |
תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק) |
פתרון |
תכנן web crawler |
פתרון |
תכנן את Mint.com |
פתרון |
תכנן את מבני הנתונים של רשת חברתית |
פתרון |
תכנן אחסון key-value למנוע חיפוש |
פתרון |
תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון |
פתרון |
תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS |
פתרון |
הוסף שאלה לתכנון מערכת |
תרום |
### תכנן את pastebin.com (או bit.ly)
[צפה בתרגיל ובפתרון](solutions/system_design/pastebin/README.md)
הצג/הסתר דיאגרמה
### תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק)
[צפה בתרגיל ובפתרון](solutions/system_design/twitter/README.md)
הצג/הסתר דיאגרמה
### תכנן web crawler
[צפה בתרגיל ובפתרון](solutions/system_design/web_crawler/README.md)
הצג/הסתר דיאגרמה
### תכנן את Mint.com
[צפה בתרגיל ובפתרון](solutions/system_design/mint/README.md)
הצג/הסתר דיאגרמה
### תכנן את מבני הנתונים של רשת חברתית
[צפה בתרגיל ובפתרון](solutions/system_design/social_graph/README.md)
הצג/הסתר דיאגרמה
### תכנן אחסון key-value למנוע חיפוש
[צפה בתרגיל ובפתרון](solutions/system_design/query_cache/README.md)
הצג/הסתר דיאגרמה
### תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון
[צפה בתרגיל ובפתרון](solutions/system_design/sales_rank/README.md)
הצג/הסתר דיאגרמה
### תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS
[צפה בתרגיל ובפתרון](solutions/system_design/scaling_aws/README.md)
הצג/הסתר דיאגרמה
## שאלות ריאיון בתכנון מונחה עצמים עם פתרונות
> שאלות נפוצות בתכנון מונחה עצמים עם הסברים לדוגמה, קוד, ודיאגרמות.
>
> הפתרונות מפנים לתוכן שנמצא בתיקיית `solutions/`.
>**הערה: החלק הזה עדיין בפיתוח**
שאלה |
פתרון |
תכנן Hash Map |
פתרון |
תכנן מנגנון Cache בשיטת Least Recently Used |
פתרון |
תכנן מרכז שירות טלפוני (Call Center) |
פתרון |
תכנן חפיסת קלפים |
פתרון |
תכנן חניון |
פתרון |
תכנן שרת צ'אט |
פתרון |
תכנן מערך מעגלי |
תרום |
הוסף שאלה בעיצוב מונחה עצמים |
תרום |
## נושאים בתכנון מערכות: התחל כאן
חדש בתחום תכנון מערכות?
ראשית, תצטרך לקבל הבנה בסיסית של העקרונות הנפוצים, ללמוד מה הם, איך משתמשים בהם, מה היתרונות והחסרונות של כל אחד מהם.
### שלב 1: צפה בהרצאה על סקילביליות
[Scalability Lecture at Harvard](https://www.youtube.com/watch?v=-W9F__D3oY4)
* Topics covered:
* Vertical scaling
* Horizontal scaling
* Caching
* Load balancing
* Database replication
* Database partitioning
### שלב 2: קרא מאמר על סקילביליות
[Scalability](https://web.archive.org/web/20221030091841/http://www.lecloud.net/tagged/scalability/chrono)
* Topics covered:
* [Clones](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
* [Databases](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
* [Caches](https://web.archive.org/web/20230126233752/https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
* [Asynchronism](https://web.archive.org/web/20220926171507/https://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
### השלבים הבאים
בהמשך, נסתכל על trade-offs ב-high level:
* **Performance** vs **scalability**
* **Latency** vs **throughput**
* **Availability** vs **consistency**
נזכור כי **הכול זה trade-off**.
לאחר מכן נצלול לנושאים ספציפיים יותר כמו DNS, CDN ו-load balancers.
## ביצועים (performance) מול סקילביליות (scalability)
שירות הוא **סקילבילי (scalable)** אם הוא משתפר **בביצועים (performance)** שלו באופן פרופורציונלי למשאבים שנוספו. באופן כללי, שיפור בביצועים פירושו היכולת לתת שירות ליותר יחידות עבודה, אך הוא יכול גם לבוא לידי ביטוי ביכולת להתמודד עם יחידות עבודה גדולות יותר, ככל שהדאטא גדל.
1
דרך נוספת להסתכל על ביצועים מול סקילביליות
- אם יש לך בעיית ביצועים, המערכת איטית עבור משתמש בודד.
- אם יש לך בעיית סקילביליות, המערכת מהירה עבור משתמש בודד אך איטית בעומס כבד.
### מקורות וקריאה נוספת
* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
## שיהוי (latency) מול תפוקה (throughput)
**שיהוי** הוא הזמן שנדרש כדי לבצע פעולה כלשהי או להפיק תוצאה כלשהי
**תפוקה** היא מספר הפעולות או התוצאות ליחידת זמן.
באופן כללי, כדאי לשאוף **לתפוקה מקסימלית** עם **שיהוי סביר**.
### חומרים וקריאה נוספת
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
## זמינות (availability) מול עקביות (consistency)
### משפט CAP
Source: CAP theorem revisited
במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים:
- עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
- זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
- יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.
*ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״.
לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.*
#### בחירה ב-CP - עקביות ויכולת חלוקה
המתנה לתשובה מהמערכת (אשר סובלת מ-network partition) עלולה להסתיים בשגיאת timeout. לכן, CP הוא בחירה טובה במידה ויש הצדקה עסקית לקריאות וכתיבות אטומיות.
#### בחירה ב-AP - זמינות ויכולת חלוקה
תשובות לבקשות מהמערכת מחזירות את הגרסה הזמינה ביותר של הנתונים הזמינים בשרת הרלוונטי, שאינה בהכרח האחרונה. כתיבה עשויה לקחת זמן מסוים עד שתסתיים, עד אשר התקשורת הבעייתית תיפתר.
לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של [eventual consistency](#eventual-consistency) או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות.
### חומרים וקריאה נוספת
* [CAP theorem revisited](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
* [CAP FAQ](https://github.com/henryr/cap-faq)
* [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA)