diff --git a/README-he.md b/README-he.md
index 8f5d1369..5862cbbf 100644
--- a/README-he.md
+++ b/README-he.md
@@ -695,7 +695,7 @@
 </div>
 
 
-## ביצועים (performance) מול סקילביליות (scalability)
+## ביצועים (Performance) מול סקילביליות (Scalability)
 
 <div dir="rtl">
 
@@ -715,7 +715,7 @@
 
 </div>
 
-## שיהוי (latency) מול תפוקה (throughput)
+## שיהוי (Latency) מול תפוקה (Throughput)
 
 <div dir="rtl">
 
@@ -731,7 +731,7 @@
 
 </div>
 
-## זמינות (availability) מול עקביות (consistency)
+## זמינות (Availability) מול עקביות (Consistency)
 
 <div dir="rtl">
 
@@ -746,10 +746,10 @@
 במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים:
 
 <ul>
-      <li><strong>עקביות (Consistency)</strong> – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.</li>
-      <li><strong>זמינות (Availability)</strong> - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.</li>
-      <li><strong>יכולת חלוקה (Partition Tolerance)</strong> - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.</li>
-    </ul>
+  <li><strong>עקביות (Consistency)</strong> – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.</li>
+  <li><strong>זמינות (Availability)</strong> - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.</li>
+  <li><strong>יכולת חלוקה (Partition Tolerance)</strong> - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.</li>
+</ul>
 
 *ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״. 
 לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.*
@@ -770,3 +770,129 @@
 * [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)
+
+</div>
+
+
+## דפוסי עקביות (Consistency Patterns)
+
+<div dir="rtl">
+
+כאשר קיימים מספר עותקים של אותם נתונים, עלינו להחליט כיצד לסנכרן ביניהם כדי שלקוחות יקבלו תצוגה עקבית של המידע.  
+ניזכר בהגדרה של עקביות מתוך [משפט CAP](#cap-theorem): כל קריאה מקבלת את הכתיבה העדכנית ביותר או שגיאה.
+
+### עקביות חלשה (Weak Consistency)
+
+לאחר כתיבה, קריאות עשויות לראות או לא לראות את הערך החדש שנכתב. הגישה כאן היא של best effort - המאמץ הטוב ביותר.
+
+גישה זו נפוצה במערכות כמו memcached. עקביות חלשה מתאימה למקרים של מערכות זמן-אמת, כמו VoIP, שיחות וידאו, ומשחקים מרובי משתתפים.  
+לדוגמה, אם אתה בשיחת טלפון ומאבד קליטה לכמה שניות, כשאתה חוזר אתה לא שומע מה שנאמר בזמן שלא הייתה קליטה.
+
+### עקביות לא מיידית (Eventual Consistency)
+
+לאחר כתיבה, הקריאות יראו בסופו של דבר את מה שנכתב (בדרך כלל תוך מספר מילישניות). הנתונים משוכפלים באופן אסינכרוני.
+
+גישה זו נפוצה במערכות כמו DNS ומייל. עקביות לא מיידית מתאימה למערכות ששומרות על זמינות גבוהה במיוחד.
+
+### עקביות חזקה (Strong Consistency)
+
+לאחר כתיבה, הקריאות יראו תמיד את הערך החדש שנכתב. השכפול מתבצע באופן סינכרוני.
+
+גישה זו נפוצה במערכות קבצים ובמסדי נתונים רלציוניים (RDBMS). עקביות חזקה מתאימה למערכות שדורשות טרנזקציות.
+
+### מקורות וקריאה נוספת
+
+- [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)
+
+</div>
+
+## דפוסי זמינות (Availability Patterns)
+
+<div dir="rtl">
+
+קיימים שני דפוסים משלימים לתמיכה בזמינות גבוהה: **מעבר אוטומטי (fail-over)** ו-**שכפול (replication)**.
+
+### גיבוי בזמן כישלון (Fail-Over)
+
+#### אקטיבי-פסיבי (Active-Passive)
+
+במבנה אקטיבי-פסיבי, נשלחים heartbeat-ים בין השרת הפעיל לשרת הרזרבי (הפסיבי). אם ה-heartbeat נקטע, השרת הפסיבי לוקח את כתובת ה-IP של הפעיל וממשיך את השירות.
+
+משך זמן ההשבתה תלוי אם השרת הפסיבי פועל מראש במצב 'חם' (hot standby), או שיש להפעילו ממצב 'קר' (cold standby). רק השרת הפעיל מקבל תעבורה.
+
+סוג זה נקרא גם Master-Slave.
+
+#### אקטיבי-אקטיבי (Active-Active)
+
+במבנה אקטיבי-אקטיבי, שני השרתים מקבלים תעבורה ומחלקים ביניהם את העומס.
+
+אם השרתים חשופים פומבית, שרת ה-DNS צריך לדעת על כתובות ה-IP הציבוריות של שניהם. אם השרתים פנימיים, על לוגיקת האפליקציה להכיר את שניהם.
+
+סוג זה נקרא גם Master-Master.
+
+### חסרונות של מעבר אוטומטי
+
+<ul dir="rtl">
+  <li>מעבר אוטומטי מוסיף חומרה ועלות תפעולית.</li>
+  <li>קיימת אפשרות לאובדן נתונים אם המערכת הפעילה קורסת לפני שהספיקה לשכפל את המידע למערכת הפסיבית.</li>
+</ul>
+
+### שכפול (Replication)
+
+#### עבור Master-Slave/Master-Master
+
+נושא זה נדון בפירוט נוסף בחלק על [מסדי נתונים](#database):
+
+- [Master-slave replication](#master-slave-replication)
+- [Master-master replication](#master-master-replication)
+
+### זמינות במספרים
+
+נהוג למדוד זמינות לפי זמן פעילות (uptime) או חוסר פעילות (downtime)כאחוז מהזמן שבו השירות פועל. המדד הנפוץ הוא לפי מספר התשיעיות — לדוגמה: שירות עם זמינות של 99.99% מתואר כבעל ארבע תשיעיות.
+
+#### זמינות של 99.9% — שלוש תשיעיות
+
+| Duration            | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year   | 8h 45min 57s       |
+| Downtime per month  | 43m 49.7s          |
+| Downtime per week   | 10m 4.8s           |
+| Downtime per day    | 1m 26.4s           |
+
+#### זמינות של 99.99% — ארבע תשיעיות
+
+| Duration            | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year   | 52min 35.7s        |
+| Downtime per month  | 4m 23s             |
+| Downtime per week   | 1m 5s              |
+| Downtime per day    | 8.6s               |
+
+#### זמינות במקביל לעומת בטור
+
+אם שירות מורכב ממספר רכיבים שעלולים להיכשל, הזמינות הכוללת של השירות תלויה באופן שבו הם מסודרים - בטור או במקביל.
+
+###### בטור
+
+כאשר שני רכיבים עם זמינות קטנה מ-100% מסודרים בטור, הזמינות הכוללת יורדת:
+
+```
+Availability (Total) = Availability (Foo) * Availability (Bar)
+```
+
+אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם בטור תהיה 99.8%.
+
+###### במקביל
+
+הזמינות הכוללת עולה כאשר שני רכיבים בעלי זמינות קטנה מ־100% פועלים במקביל:
+
+```
+Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
+```
+
+אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם במקביל תהיה 99.9999%.
+
+</div>
+
+
+