Röportaj Soruları: Skor Sistemleri Mühendisine Sorulacak 12 Teknik Soru — Senkronizasyon, Kesinti Kurtarma ve Hile Önleme

Skor sistemleri (özellikle oyun, yarışma veya gerçek zamanlı puanlama uygulamaları) yüksek tutarlılık, düşük gecikme ve aşırı kötü niyetli davranışlara karşı direnç gerektirir. Bu yazıda, bir skor sistemleri mühendisini teknik olarak derinlemesine değerlendirecek 12 soru, her soru için neyi ölçtüğü, hangi cevapların beklenebileceği ve takip soruları/puanlama ipuçları ile birlikte bulacaksınız.

Giriş: Neden özel sorular?

Skor sistemleri, tek başına veri modelinden daha fazlasıdır: dağıtık senkronizasyon, olay sıralaması, dayanıklılık (durability), kesinti kurtarma (fault recovery) ve hile (cheating) tespiti gibi disiplinler arası konuları içerir. Bu nedenle röportajda yüzeysel bir yetkinlik ölçümü yerine, adayın mimari prensipleri, zamanlama ve güvenlik yaklaşımlarındaki derinliğini test etmek gerekir.

Nasıl kullanmalı?

Her soru için aşağıdaki yapıyı öneririm: önce soruyu sorun, adayın verdiği cevabı dinleyin, ardından takip soruları ile derinliğe inin ve son olarak değerlendirme kriterleri ile puanlayın.

12 Teknik Soru ve Açıklamaları

1. 1) Skor güncellemelerini dağıtık bir sistemde nasıl senkronize edersiniz?

   Ne ölçer: Saat/olay sıralaması, tutarlılık modelleri (strong vs eventual), conflict resolution stratejileri.

   İyi cevapta: Lamport/Vector clock, CRDT/operational transform, optimistic vs pessimistic concurrency, idempotency, deterministik görevlendirme (leader election) gibi kavramları görmelisiniz. Örnek: "Gerçek zamanlı oyunlarda olay sıralaması için Lamport timestamp + merkezi arabulucu (veya deterministik komut sırası) kullanırım; çevrimdışı/partition durumunda CRDT ile eventual consistency tercih ederim."

   Takip: Network partition olursa ne olur? Gecikme 200ms'den 1sn'e çıkarsa tasarım değişir mi?

   Red flags: Sadece "tek bir DB'ye yazıyoruz" demek; timestamp'leri yerel saatle karşılaştırma hatası; idempotency'den bahsetmemek.

2. 2) Puanlama işlemlerinde idempotency nasıl sağlanır?

   Ne ölçer: Duplicate request handling, retry senaryoları, benzersiz işlem kimlikleri.

   İyi cevapta: Her skor değişikliğine benzersiz bir event ID eklemek, consumer tarafında processed-set tutmak veya deduplication logları kullanmak beklenir. Ayrıca API tarafında idempotency-key header ve DB'de bugünkü key ile upsert kullanma örnekleri.

   Takip: Processed-set büyürse ne yaparsınız? Memory/expiry stratejileri?

   Red flags: "Tekrar oluşmaz" demek; veya yalnızca client timestamp'a güvenmek.

3. 3) Kesinti (node crash) sonrası skorları nasıl kurtarırsınız?

   Ne ölçer: Durability, WAL (write-ahead log), snapshotting, replication ve leader election süreçleri.

   İyi cevapta: Sürdürülebilir yaklaşım olarak synchronous replication + WAL + düzenli checkpoint/snapshot önerisi; recovery sırasında idempotent replay; quorum tabanlı commit politikaları (e.g., Raft/etcd) anlatılmalı. Örnek senaryo: leader düştüğünde follower'ın state machine replay ile aynı skora gelmesi.

   Takip: Split-brain durumunda hangi yaklaşımı alırsınız? İnsan müdahalesi gerektirir mi?

   Red flags: Snapshot/backup planı olmayan, veya tek bir backup'a bağımlı olmak.

4. 4) Bir oyuncunun hile yaptığını nasıl tespit edersiniz?

   Ne ölçer: Anomali tespiti, telemetri, server-side validation, anti-cheat stratejileri.

   İyi cevapta: Server-authoritative model (kritik skorlar server tarafında hesaplanmalı), input validation, rate limiting ve davranışsal anomali tespiti (lojik regresyon/ML ile) kombinasyonu. Örnek: anormal skor artışı + kısa sürede yapılan çok sayıda istek = şüphe işareti; bunun yanında replay kayıtları ve checksum ile doğrulama.

   Takip: Yanlış pozitifleri (false positive) nasıl azaltırsınız? Kullanıcı itiraz süreçleri nasıl olur?

   Red flags: Her şeyi client'tan beklemek; sadece IP bloklama ile çözüm aramak.

5. 5) Gerçek zamanlı lider tablolarını (leaderboards) ölçeklendirirken hangi stratejileri kullanırsınız?

   Ne ölçer: Cache, sharding, materialized views, fan-out vs fan-in stratejileri.

   İyi cevapta: Sıralama için Redis sorted sets gibi özel veri yapıları, sıcak veriler için cache katmanı, partitioning (shard by player ID veya leaderboard ID), ayrıca eventual consistency ile batch güncellemeler ve top-N sorguları için precompute/aggregation kullanımı anlatılmalı. Yüksek yazı trafiğinde yazma gecikmesini azaltmak için write-behind ve queue temelli işlemler.

   Takip: Top-100 sorgusunu saniyede 10k istekle nasıl desteklersiniz? Cold start problemi?

   Red flags: Tek bir global SQL sorgusuna güvenmek; sıralamanın her yazmada tam yeniden hesaplanması gerektiğini iddia etmek.

6. 6) Oyun içi puan hesaplaması deterministik olmalı mı? Neden?

   Ne ölçer: Deterministik hesaplamanın faydaları, test edilebilirlik, tekrar oynanabilirlik ve replay/anticheat için gereklilik.

   İyi cevapta: Evet; deterministik fonksiyonlar bug tespiti ve hile analizi için büyük kolaylık sağlar. Rastgelelik gerekiyorsa seed yönetimi ve server-side seed tutma önerilmeli. Ayrıca float hassasiyeti ve platformlar arası tutarlılık hakkında konuşulmalı.

   Takip: Deterministik olmanın maliyeti var mı? Performans/komplekslik etkileri?

   Red flags: Rastgelelikten kaçınmamak veya platform farklılıklarını göz ardı etmek.

7. 7) Event sourcing kullanır mısınız? Skor sistemleri için artıları ve eksileri nelerdir?

   Ne ölçer: Event sourcing kavramı, avantajlar (audit, replay), dezavantajlar (depolama, migrate/zamanla değişim).

   İyi cevapta: Event sourcing, skorlarda audit ve rollback için çok güçlüdür. Ancak event schema migration, storage maliyetleri ve replay sırasında performans sorunları dikkate alınmalı. Genelde event store + materialized view kombinasyonu önerilir.

   Takip: Schema değişikliklerini nasıl yönetirsiniz? Old events ile new logic nasıl uyumlu çalışır?

   Red flags: Event sourcing'i her probleme tek çözüm olarak sunmak; migration stratejisi yok.

8. 8) Network partition ve clock drift senaryolarında skor tutarlılığını nasıl korursunuz?

   Ne ölçer: Partition tolerance, CAP tradeoffs, clock synchronization (NTP/PTP), ve conflict resolution stratejileri.

   İyi cevapta: Saat bazlı kararlar yerine logical clocks kullanmak, partition sırasında yazma quorum'u ve conflict-resolution policy belirlemek (last-writer-wins yerine merge/operational transform/CRDT), ayrıca client tarafında geçici offline modunda queue'lama ve server reconciliation anlatılmalı.

   Takip: Saat eşitleme mümkün değilse ne yaparsınız? Hangi durumlarda eventual consistency tolere edilir?

   Red flags: Local clock'a güvenmek; partition durumunda otomatik veri kaybını kabul etmek.

9. 9) Hileyi server tarafında nasıl önlersiniz? Mimaride hangi bileşenler kritik?

   Ne ölçer: Server-authoritative design, input validation, anti-tampering, logging ve monitoring.

   İyi cevapta: Kritik hesaplamaların her zaman server tarafından yapılması; client sadece input gönderir. Ek olarak code obfuscation, secure telemetry, replay path'leri, anomaly detectors, and legal/audit trails türü bileşenler sayılmalı.

   Takip: Her şeyi server'a taşımak latency sorununu arttırır mı? Hybrid çözümler önerir misiniz?

   Red flags: Tamamen client-trust yaklaşımı veya sadece client-side hile tespitine güvenmek.

10. 10) Veri bütünlüğü (integrity) için hangi kriptografik yaklaşımları kullanırsınız?

    Ne ölçer: Signatures, HMAC, checksums, TLS, ve non-repudiation kavramları.

    İyi cevapta: Transport için TLS, mesaj doğrulama için HMAC veya dijital imzalar, event log için hash-chain (blockchain benzeri) ve replay koruması gösterilmeli. Ayrıca key management ve rotate politikaları tartışılmalı.

    Takip: HMAC vs dijital imza tercih sebepleri? Performans etkileri?

    Red flags: Güvenliği sadece obscurity ile sağlamayı önermek.

11. 11) Geri dönüşümlü (rollback) bir senaryoda skorları nasıl restore edersiniz?

    Ne ölçer: Snapshots, compensating transactions, transactional outbox pattern, ve reconciliation süreçleri.

    İyi cevapta: Event sourcing veya WAL + snapshot kullanarak belirli bir zamani hedefleyerek replay; compensating transactions ile hatalı işlemleri tersine çevirme ve kullanıcı iletişimi/otomasyon süreçleri örneklenmeli.

    Takip: Kullanıcıların gerçek zamanlı oynadığı bir maçta rollback yapmak mümkün mü? UX nasıl yönetilir?

    Red flags: Rollback fikrini sadece DB restore ile çözmeye çalışmak (uygulama seviyesinde reconcile yoksa tutarsızlık artar).

12. 12) İzleme, alarm ve incident response için hangi metrikleri eklersiniz?

    Ne ölçer: Operasyonel olgunluk, SLO/SLI, observability ve on-call süreç bilgisi.

    İyi cevapta: Latency (p99/p95), error rates, write-success ratio, replication lag, queue length, abnormal score delta rate, number of suspected-cheat incidents, ve business metrikleri (e.g., daily active players affecting leaderboard) önerilmeli. Ayrıca runbook ve playbook örnekleri beklenir.

    Takip: Hangi metrik otomatik rollback tetikler? SLA ihlali durumunda ne yapılmalı?

    Red flags: Sadece infra-level metriclere odaklanmak, business metricleri göz ardı etmek.

Mülakat için Puanlama ve İpuçları

• Derinlik (40%): Adayın konseptleri pratik örneklerle ilişkilendirmesi.
• Pratiklik (30%): Gerçek dünya kısıtlarını (latency, cost, operational overhead) dikkate alması.
• Güvenlik/Gizlilik (20%): Hile önleme ve veri bütünlüğü yaklaşımlarında sağlam çözümler.
• İletişim (10%): Kompleks konuları sade anlatabilme yeteneği.

Not: Adayın tüm cevapları mükemmel olmasına gerek yok; önemli olan problem çözme yaklaşımı, trade-off değerlendirmesi ve operasyonel farkındalıktır.

Sonuç

Bu 12 soru, bir skor sistemleri mühendisinin hem teorik hem pratik yetkinliklerini sınar. Soruları takip sorularıyla derinleştirin, adayın varsayımlarını test edin ve gerçek dünya yükleri/şartları üzerinden örnekler isteyin. Başarılı bir mühendis, sadece doğru teknolojiyi bilmekle kalmaz; aynı zamanda hata koşullarını, kullanıcı etkisini ve operasyonel maliyetleri de hesaba katar.

Ardından, adayın verdiği cevapları örnek senaryolarla doğrulayın: küçük bir prototip, yapılandırma değişiklikleri veya whiteboard akışları ile doğrulama her zaman değerlidir.