first commit

doc/decisions/ADR-001-scraper-choice.md

@@ -0,0 +1,53 @@
+# ADR-001: Cheerio Scraping Kütüphanesi Seçimi
+
+## Durum
+
+Kabul edildi
+
+## Bağlam
+
+Netflix içerik sayfalarından HTML parsing ile veri çekmemiz gerekiyor. İki ana seçenek var:
+
+1. **Cheerio**: Lightweight HTML parser
+2. **Playwright/Puppeteer**: Headless browser automation
+
+## Karar
+
+**Cheerio** seçildi.
+
+## Gerekçe
+
+### Cheerio Avantajları
+- Hafif ve hızlı
+- Düşük kaynak kullanımı
+- Basit API
+- Daha az bağımlılık
+
+### Playwright Avantajları
+- JavaScript rendering desteği
+- Daha güçlü scraping
+- Dinamik içerik desteği
+
+### Seçim Nedeni
+1. Netflix sayfalarının HTML'inde temel veriler mevcut
+2. Client-side rendering gerektiren kritik veri yok
+3. Performans öncelikli
+4. Başlangıç için Cheerio yeterli
+
+## Sonuçlar
+
+### Olumlu
+- Düşük kaynak kullanımı
+- Hızlı yanıt süresi
+- Basit bakım
+
+### Olumsuz
+- JavaScript rendering gerektiren sayfalar için çalışmayabilir
+- Netflix client-side rendering'e geçerse güncelleme gerekir
+
+### Alternatif Plan
+Eğer Cheerio yetersiz kalırsa Playwright'a geçiş yapılabilir. Altyapı buna uygun hazır.
+
+## Tarih
+
+2025-02-27

doc/decisions/ADR-002-cache-strategy.md

@@ -0,0 +1,61 @@
+# ADR-002: Hybrid Cache Stratejisi
+
+## Durum
+
+Kabul edildi
+
+## Bağlam
+
+Netflix'ten scraped verileri nasıl saklayacağımıza karar vermemiz gerekiyor. Seçenekler:
+
+1. **Sadece Cache**: Redis'te TTL ile sakla
+2. **Sadece Database**: PostgreSQL'de kalıcı sakla
+3. **Hybrid**: Cache + Database birlikte
+
+## Karar
+
+**Hybrid Cache Stratejisi** (Cache → DB → Netflix) seçildi.
+
+## Akış
+
+```
+İstek → Redis Cache → Varsa dön
+                    → Yoksa → PostgreSQL → Varsa dön, Cache'e yaz
+                                       → Yoksa → Netflix'ten çek → DB'ye yaz → Cache'e yaz → Dön
+```
+
+## Gerekçe
+
+### Sadece Cache Eksikleri
+- TTL dolduğunda veri kaybı
+- Yeniden scraping maliyeti
+
+### Sadece Database Eksikleri
+- Her istekte DB sorgusu
+- Daha yavaş yanıt
+
+### Hybrid Avantajları
+1. **Hız**: Cache hit durumunda anlık yanıt
+2. **Kalıcılık**: Veriler DB'de saklanır
+3. **Verimlilik**: Netflix'e gereksiz istek atılmaz
+4. **TTL Esnekliği**: Cache süresi ayarlanabilir
+
+## Sonuçlar
+
+### Olumlu
+- En hızlı yanıt süresi (cache hit)
+- Veri kalıcılığı
+- Netflix üzerinde minimal yük
+
+### Olumsuz
+- İki sistem senkronizasyonu
+- Daha fazla kod karmaşıklığı
+
+### Yapılandırma
+```env
+REDIS_TTL_SECONDS=604800  # 7 gün
+```
+
+## Tarih
+
+2025-02-27

doc/decisions/ADR-003-api-key-strategy.md

@@ -0,0 +1,63 @@
+# ADR-003: Named API Keys Stratejisi
+
+## Durum
+
+Kabul edildi
+
+## Bağlam
+
+API güvenliği için authentication yöntemi belirlememiz gerekiyor. Birden fazla frontend olacak (Web, Mobile, Admin).
+
+## Seçenekler
+
+1. **Tek API Key**: Tüm frontend'ler aynı key'i kullanır
+2. **Named API Keys**: Her frontend için ayrı key
+3. **Database API Keys**: Key'ler DB'de tutulur, yönetim paneli ile
+
+## Karar
+
+**Named API Keys** (.env'de tanımlı) seçildi.
+
+## Yapılandırma
+
+```env
+API_KEY_WEB=web-frontend-key-xxx
+API_KEY_MOBILE=mobile-app-key-yyy
+API_KEY_ADMIN=admin-key-zzz
+```
+
+## Gerekçe
+
+### Tek Key Eksikleri
+- Hangi frontend'in istek attığı belli değil
+- Tek bir frontend engellenemez
+- Audit trail yok
+
+### Database Key Eksikleri
+- Ekstra kompleksite
+- Yönetim paneli gerektirir
+- Başlangıç için overkill
+
+### Named Keys Avantajları
+1. **İzlenebilirlik**: Hangi frontend'in istek attığı bilinir
+2. **Kontrol**: Tek bir frontend'in erişimi kapatılabilir
+3. **Basitlik**: .env ile yönetim
+4. **Güvenlik**: Her frontend için ayrı secret
+
+## Sonuçlar
+
+### Olumlu
+- Frontend bazlı rate limiting
+- Kolay key rotasyonu
+- Basit yapılandırma
+
+### Olumsuz
+- Yeni frontend için .env güncellemesi gerekir
+- Key yönetimi manuel
+
+### Gelecek
+Gerekirse Database API Keys sistemine geçiş yapılabilir.
+
+## Tarih
+
+2025-02-27