3 dk okuma
Backend / Sistem Tasarımı
Backend / Sistem Tasarımı Mülakat Konuları
1. Caching Stratejileri
- Cache invalidation: Veri değiştiğinde cache'i güncel tutmak — "computer science'taki en zor iki şeyden biri" diye şakayla anılır.
- TTL (Time To Live): Cache'in ne kadar süre geçerli kalacağı.
- Cache-aside, write-through, write-behind: Farklı cache güncelleme stratejileri.
- Redis: Sık kullanılan in-memory cache/veri deposu; session, rate limiting, leaderboard gibi senaryolarda da kullanılır.
2. Rate Limiting Algoritmaları
- Token bucket: Kova belirli hızda token ile doldurulur, her istek bir token harcar; kova boşsa istek reddedilir.
- Leaky bucket: İstekler sabit hızda "sızdırılır", ani patlamaları (burst) yumuşatır.
- Sliding window: Belirli bir zaman penceresinde (örn. son 60 saniye) kaç istek yapıldığını sayar.
3. JWT vs Session-Based Authentication
- Session-based: Sunucu tarafında oturum bilgisi tutulur, client sadece session ID (genelde cookie'de) taşır. İptal etmek kolay.
- JWT (JSON Web Token): Kullanıcı bilgisi token içine gömülür, sunucu state tutmaz (stateless). Ölçeklenebilir ama token'ı erken iptal etmek zordur (blacklist gerekir).
4. Database Indexing
- B-tree index: Çoğu veritabanının varsayılan index yapısı, sıralı arama ve aralık sorguları için hızlıdır.
- Composite index: Birden fazla kolonu kapsayan index — kolon sırası önemlidir (soldan sağa kullanılır).
- Index her zaman yardımcı olmaz:
WHERE column LIKE '%x%'gibi baştan wildcard içeren sorgularda B-tree index işe yaramaz; yazma işlemlerini (INSERT/UPDATE) yavaşlatabilir.
5. SQL vs NoSQL
| SQL | NoSQL | |
|---|---|---|
| Şema | Katı (structured) | Esnek |
| İlişkiler | Güçlü (JOIN, foreign key) | Genelde denormalize |
| Ölçekleme | Dikey (genelde) | Yatay (genelde) |
| Örnek | PostgreSQL, MySQL | MongoDB, DynamoDB, Redis |
Karmaşık ilişkisel veri ve transaction güvenilirliği (ACID) gerekiyorsa SQL; esnek şema, hızlı yazma ve yatay ölçekleme gerekiyorsa NoSQL tercih edilir.
6. Message Queue'lar
Senkron API çağrısı yerine kuyruk (Kafka, RabbitMQ, SQS) kullanmanın sebepleri:
- İşi arka plana atıp kullanıcıyı bekletmemek (örn. email gönderimi, video işleme)
- Servisler arası bağımlılığı azaltmak (biri çökse bile mesaj kuyrukta bekler)
- Ani yük artışlarını (traffic spike) yumuşatmak
7. Idempotency
Aynı isteği birden fazla kez göndermek, tek seferlik gönderilmiş gibi aynı sonucu vermelidir. Özellikle ödeme ve sipariş sistemlerinde kritik: ağ hatası yüzünden kullanıcı "Öde" butonuna iki kez basarsa, çift ücretlendirme olmamalı. Genelde bir idempotency key (istemcinin ürettiği benzersiz ID) ile çözülür.
Sık Sorulan Mülakat Soruları
- Cache invalidation neden zor bir problem olarak görülür?
- Cache-aside, write-through ve write-behind arasındaki farklar nelerdir?
- Token bucket ile leaky bucket algoritmaları arasındaki fark nedir?
- JWT ile session-based authentication'ı nasıl karşılaştırırsın, hangi durumda hangisi tercih edilir?
- Bir JWT'yi süresi dolmadan nasıl iptal edersin?
- B-tree index nasıl çalışır, ne zaman işe yaramaz?
- Composite index'te kolon sırası neden önemlidir?
- SQL ile NoSQL arasında nasıl seçim yaparsın?
- Neden senkron bir API çağrısı yerine message queue kullanılır?
- Idempotency nedir, ödeme sistemlerinde neden kritiktir?
- Idempotency key nasıl implemente edilir?