~/zafer
Tüm yazılara dön
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?