# מערך שיעור: Redis ו-Cache-Aside📋 מערך מרצה

משך: 2 שעות אקדמיות (100 דקות).

מטרת השיעור: הסטודנטים יבינו למה Redis מהיר, ויישמו תבנית Cache-Aside אמיתית מעל DB קיים.

בסוף השיעור הסטודנטים צריכים: להסביר למה זיכרון מהיר מדיסק, לממש Cache-Aside עם Cache Hit/Miss, ולהסביר את הסיכון של קאש מיושן (Cache Invalidation).

דגש קריטי: מדידת זמן תגובה אמיתית (Cache Hit מול Miss) היא ההוכחה החיה הכי חזקה בשיעור הזה — הקדישו לה זמן.

---

## מהלך השיעור

| חלק בשיעור | משך | הערות ודגשים |
| --- | --- | --- |
| פתיחה וחיבור | 5 דקות | שאלו: "מה יותר מהיר — לקרוא מ-RAM או מדיסק?" |
| הרעיון: Redis כמטמון בזיכרון | 15 דקות | הסבר קצר על ההבדל במהירות |
| הכנסת Redis לפרויקט (Setup) | 10 דקות | Docker → NuGet → רישום ב-Program.cs (DI, AddSingleton) → הזרקה לשירות |
| Data Types | 15 דקות | String/Hash/List/Set, דוגמאות קצרות |
| הרעיון: Cache-Aside | 20 דקות | בדיקה→Miss→שליפה+שמירה→Hit הבא |
| TTL | 10 דקות | מניעת קאש מיושן לצמיתות |
| הדגמה חיה: מדידת זמן | 20 דקות | Stopwatch, Hit מול Miss בפועל |
| תרגול מודרך | 5 דקות | תרגיל 1 |

---

## דגשים להעברת השיעור

- השלב הכי נשכח: הרישום ב-Program.cs. סטודנטים נוטים לדלג ישר לקוד עם `ConnectionMultiplexer.Connect` בכל מקום, בלי DI — הדגישו למה `AddSingleton` ולא ליצור חיבור חדש בכל בקשה.
- מדידת זמן תגובה אמיתית (עם `Task.Delay` מלאכותי לדימוי DB "איטי") היא הרגע החשוב ביותר — מספרים קונקרטיים (למשל "500ms → 2ms") משכנעים בהרבה מהסבר תיאורטי.
- הדגישו בתקיפות את סיכון ה-Cache Invalidation — עדכון DB בלי לעדכן/למחוק קאש הוא באג נפוץ ומסוכן בקוד production אמיתי.
- קשרו TTL ל-TTL Index ב-MongoDB מהשיעור הקודם — אותו רעיון בדיוק, כלי אחר.

---

## מושגים

**Cache** — אחסון זמני של תוצאות מחושבות.
**Redis Data Types** — String/Hash/List/Set.
**TTL** — זמן חיים לערך בקאש.
**Cache-Aside Pattern** — בדוק קאש→Miss→שלוף+שמור→Hit הבא.

---

## תרגיל חשיבה

**שאלת פתיחה:** "עדכנתם מחיר מוצר ב-DB, אבל שכחתם למחוק את הערך המתאים ב-Redis. מה יראה משתמש שמבקש את המוצר הזה עכשיו — ולמה זה מסוכן במיוחד למחיר?"

**מהלך:** הובילו לתובנה: המשתמש יראה את המחיר **הישן** (מהקאש), לא העדכני — עד שה-TTL יפוג. עבור מחיר, זו לא רק אי-נוחות — זה עלול להיות נזק עסקי ממשי (מכירה במחיר שגוי). זו הדגמה מצוינת לכך ש-Cache Invalidation הוא לא "פרט טכני קטן" אלא חלק קריטי מהתכנון.

**מה המרצה מראה בסוף:** הריצו תרחיש מלא: שליפה ראשונה (Cache Miss, שומר בקאש) → עדכון "ידני" של הנתון ב-DB בלבד (בלי לגעת בקאש) → שליפה שנייה (Cache Hit — מציגה את הערך הישן, השגוי) → תיקון עם מחיקת מפתח הקאש בעדכון → שליפה שלישית (Miss מחדש, מציגה את הערך הנכון).