Senior Backend mülakat soruları ve cevapları: API, veri ve ölçeklenme

Backend seniorlığı, yalnızca endpoint yazmak değil; başarısızlık durumlarında sistemin doğru davranmasını tasarlamaktır.

1. Bir POST endpoint'ini nasıl idempotent yaparsınız?

Ödeme, sipariş veya webhook gibi tekrar gönderilebilen isteklerde istemci bir Idempotency-Key yollar. Sunucu bu anahtarı istek özeti ve sonuçla birlikte kalıcı olarak saklar. Aynı anahtar tekrar geldiğinde işlemi yeniden çalıştırmak yerine ilk sonucu döner.

Kritik ayrıntı concurrency'dir: “önce bul, sonra oluştur” iki istekte yarışabilir. Veritabanında benzersiz kısıt ve transaction kullanır, çakışma durumunu kontrollü biçimde ele alırım. Anahtarın geçerlilik süresi, kullanıcı/tenant kapsamı ve hata sonrası tekrar davranışı da sözleşmenin parçasıdır.

2. Transaction her şeyi çözer mi?

Hayır. Transaction tek veritabanı içindeki atomik değişimleri korur; e-posta göndermek, ödeme sağlayıcısına çağrı yapmak veya kuyruk mesajı yayınlamak transaction dışında yan etki üretir. Outbox pattern kullanarak veritabanı değişikliğiyle yayınlanacak olayı aynı transaction içinde kaydeder, ayrı bir worker ile güvenilir biçimde işlerim.

Consumer tarafında da en az bir kez teslim varsayımıyla idempotency gerekir. “Exactly once” çoğu dağıtık sistemde slogan olarak kolay, uçtan uca garanti olarak pahalıdır.

3. Bir sorguya indeks eklemeye nasıl karar verirsiniz?

Önce gerçek sorgu desenini ve EXPLAIN çıktısını görürüm. Filtre, sıralama ve join koşullarına göre bileşik indeks seçerim. Örneğin yayımlanmış yazıları yenilik sırasıyla listeleyen sorguda [published, createdAt] indeksi anlamlıdır.

İndeksler okuma hızını artırırken yazma maliyeti ve disk alanı getirir. Her kolona indeks eklemek değil, sık ve pahalı erişimleri kanıtla hedeflemek gerekir.

4. Uzun süren işi request içinde mi çalıştırırsınız?

Kullanıcıya hemen sonuç gerekmiyorsa hayır. E-posta, rapor, video/görsel işleme gibi işleri kuyrukta çalıştırırım. API hızlıca job ID veya kabul sonucu döner; worker retry, backoff, timeout ve gözlemlenebilirlik ile işi tüketir.

Kuyruk, pik yükleri düzleştirir ve Node.js event loop'unu bloklayan işleri kullanıcı trafiğinden ayırır. Ama job'ların idempotent, tekrar denenebilir ve izlenebilir olması gerekir.

5. Bir production hatasını nasıl incelersiniz?

Önce etkisini sınıflandırırım: kaç kullanıcı, hangi endpoint, hangi sürüm, ne zamandan beri? Correlation ID ile log, metric ve trace'i ilişkilendiririm. Hızlı mitigasyon gerekiyorsa rollback, feature flag veya trafiği sınırlama seçeneklerini uygularım.

Sonrasında root cause, düzeltme, önleyici test/alert ve sahiplik içeren kısa bir postmortem yazarım. Suçlu aramak yerine sistemin benzer hatayı neden engelleyemediğini anlamak kalıcı iyileştirmedir.

NestJS, Prisma ve MariaDB kararlarına daha uygulamalı bakmak için ölçeklenebilir API tasarımı rehberine göz atabilirsiniz.