# מערכת Caching מתקדמת עם TTL דינמי

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

- **למה**: הפחתת זמן תגובה, עומס DB וצריכת רוחב-פס.
- **מה**: TTL דינמי לפי סוג תוכן וקונטקסט, warming, invalidation חכם, ו-sync בין שרתים.
- **איך**: הרחבות ל-`cache_manager.py` ודקורטורים לשימוש נוח ב-WebApp.

## עקרונות

- TTL מבוסס סוג תוכן + התאמות לפי קונטקסט (פופולריות, עדכון אחרון, tier משתמש).
- התאמות לפי שעות פעילות (שעות שיא/לילה).
- invalidation חכם באירועי שינוי, תמיכה ב-tags וגרסאות.
- סנכרון בין instances באמצעות Redis Pub/Sub.

## קוד לדוגמה

ראו קטעי קוד נרחבים במדריך היישום. דוגמאות מרכזיות:

- מחלקות `DynamicTTL` ו-`ActivityBasedTTL` לקביעת TTL דינמי.
- `EnhancedCacheManager.set_dynamic` ו-`get_with_refresh` להטמעה הדרגתית.
- דקורטור `@dynamic_cache` לשימוש ב-Flask endpoints.
- מנגנוני invalidation (patterns, tags, versions) ו-sync.

## דגשים תפעוליים

- מדדו Hit Rate וזמני תגובה; יעד Hit Rate > 80% לאחר warming.
- הוסיפו jitter ל-TTL למניעת thundering herd.
- fallback מקומי בעת תקלה ב-Redis.

## Warmup לנכסי Frontend

- לאחר שהשרת עולה, `scripts/start_webapp.sh` מבצע warmup best-effort באמצעות `curl` ל-`/healthz` כדי לוודא שה-instance מוכן ושהחיבורים ל-DB "מתחממים".
- ניתן לשנות את יעד ה-warmup דרך `WEBAPP_WARMUP_URL`, ולכוון את קצב הניסיונות עם `WEBAPP_WARMUP_MAX_ATTEMPTS` ו-`WEBAPP_WARMUP_DELAY_SECONDS`.
- הלוגים מציינים מתי ה-warmup הצליח (באיזה ניסיון), וכישלון נחשב best-effort ולא מפיל את התהליך.
- כדי למנוע השפעה על זמני עלייה, ה-warmup רץ רק לאחר הצלחת בדיקת הבריאות, ונחשב best-effort (כישלון לא מפיל את התהליך).

## קישורים

- Issue המקור: [#975](https://github.com/amirbiron/CodeBot/issues/975)
- דף WebApp – Caching Validators: `webapp/caching`