Sistem tasarımı, code review ve mülakat davranışı

Bu bölümde

Teknik bilgi mülakatın yarısıdır; diğer yarısı o bilgiyi yapılandırılmış ve iş birliğine açık biçimde ortaya koymaktır. Bu bölümde bir sistem tasarımı sorusunu (2 milyon kullanıcılı flash sale checkout) adım adım çözmeyi ve İngilizce anlatmayı, bir PR'ı ciddiyet sırasına göre review etmeyi, iyi commit'in ölçütlerini, live coding oturumunda zamanı ve iletişimi yönetmeyi ve "kendinden bahset", "en zor problemin", "bir incident anlat" gibi davranışsal-teknik soruları STAR çerçevesiyle cevaplamayı öğreneceksin. Bu konular mülakatta açık uçlu tasarım sorusu, ekran paylaşımlı PR inceleme ve oturumun tamamına yayılan davranış değerlendirmesi olarak karşına çıkar.

Konu anlatımı

Sistem tasarımı mülakatının çerçevesi

Sistem tasarımı sorusunun tek doğru cevabı yoktur; değerlendirilen şey belirsizliği nasıl yönettiğin, trade-off'ları görüp görmediğin ve en zor kısma zamanında inip inmediğindir. 45 dakikalık bir oturum için işe yarayan iskelet:

En sık hata 6. adıma hiç gelememektir: 25 dakikayı kutu çizmeye harcayan aday, mülakatçının asıl merak ettiği soruyu ("overselling'i nasıl önlüyorsun?") cevaplayamadan süreyi bitirir. Her adımın sonunda "Bu kısmı burada bırakıp en kritik noktaya, stok tutarlılığına inmek istiyorum; uygun mu?" diye yönlendirme yap.

Kaba hesap (back-of-the-envelope) için akılda tutulacak sayılar:

• 1 gün ≈ 86.400 saniye ≈ 10⁵ saniye. Günde 10 milyon istek ≈ ortalama 115 rps; peak genelde ortalamanın birkaç katıdır.
• Aynı veri merkezi içinde bir ağ gidiş-dönüşü milisaniyenin altında; Redis gibi bellekte çalışan bir store'a çağrı tipik olarak ~1 ms civarı; disk ve veritabanı yazması milisaniyeler; kıtalar arası gidiş-dönüş on milisaniyeler ila 100+ ms.
• Bu sayılar kesin değil, büyüklük mertebesidir. Mülakatta "kaba tahminle" deyip hesabı sesli yapmak, kesin sayıyı bilmekten değerlidir.

Flash sale checkout tasarımı (q20)

Soru: "20:00'de flash sale başlıyor: tek bir telefon modelinden 50.000 adet, büyük indirimle, müşteri başına en fazla 1. İlk dakikada yaklaşık 2 milyon kullanıcının uygulamayı açmasını bekliyoruz. Stok rezervasyonu ve checkout akışını tasarla."

1. Gereksinimler ve netleştirme

Sorulacak sorular ve neden önemli oldukları:

• "Müşteri başına bir" hesap mı, adres mi, kart mı? Hesap bazlı kural kolay, ama bot sahibi bin hesap açabilir; kart/adres bazlı kural ödeme adımında ikinci bir kontrol ister.
• Rezervasyon ödeme için ne kadar bekleyebilir? Bu süre (ör. 10 dakika), satılmayan stoğun ne zaman geri döneceğini belirler.
• Ödeme sağlayıcısının saniyedeki işlem kapasitesi ne? Çoğu zaman gerçek darboğaz budur; sisteme kabul hızını bu belirler.
• "Tükendi" bilgisinin birkaç saniye geç gösterilmesi kabul mü? Kabul ise stok sayısı cache'lenebilir ve okuma yükü dramatik düşer.
• Overselling mutlak yasak mı? Evet (kampanya fiyatından fazla satış zarar ve hukuki risk). Underselling (birkaç adedin geç satılması) ise tolere edilebilir. Bu asimetri tasarımın kalbidir: şüphede reddet.

Fonksiyonel olmayan gereksinimler: overselling sıfır; checkout API'si yük altında da düşük latency ile cevap vermeli (kullanıcıya hızlı "sırada", "tükendi" ya da "rezerve edildi" demek); sistemin geri kalanı (normal alışveriş) etkilenmemeli; her siparişin kalıcı ve denetlenebilir kaydı.

2. Kapasite tahmini

• 2 milyon kullanıcı / 60 saniye ≈ 33.000 kullanıcı/s ortalama. Gelişler düzgün değildir: 20:00:00'da bildirimle gelen dalga ilk saniyelerde ortalamanın birkaç katına çıkar.
• Kullanıcı başına tek istek varsayımı iyimserdir: sayfa açma, stok sorgulama, sabırsız yenileme ve istemci retry'ları ile kullanıcı başına birkaç istek beklenir. Kenar katmanında (CDN + gateway) yüz binlerce rps mertebesi düşünülmeli.
• Sadece 50.000 satış başarılı olabilir: kullanıcıların %97,5'i "tükendi" cevabı alacak. Tasarımın ana fikri: reddedilecek trafiği olabildiğince ucuz ve olabildiğince erken reddetmek, veritabanından uzakta.
• Yazma tarafı küçüktür: 50.000 sipariş, birkaç dakikaya yayıldığında saniyede yüzler-binler mertebesinde; sipariş verisi megabaytlar düzeyinde. Problem veri hacmi değil, anlık eşzamanlılıktır.

3. API

GET  /api/v1/sales/{saleId}                      # statik detay + başlangıç zamanı (CDN'den)
POST /api/v1/sales/{saleId}/queue-tokens          # bekleme odasına gir -> 202 + sıra bilgisi
GET  /api/v1/sales/{saleId}/queue-tokens/{token}  # sıra durumu (polling)
POST /api/v1/sales/{saleId}/reservations          # header: Admission-Token, Idempotency-Key
     -> 201 {reservationId, expiresAt} | 409 already-reserved | 410/409 sold-out | 429
POST /api/v1/reservations/{id}/payment            # header: Idempotency-Key -> 202/200

"Tükendi" için status seçimi takım standardıdır (409 ya da 410 Gone; gövdede code: SOLD_OUT). Önemli olan istemcinin bu cevabı gördüğünde retry yapmaması; aksi halde tükenen bir kampanyaya istemciler istek yağdırmaya devam eder.

4. Veri modeli

• Redis (sıcak yol): stock:{sale42} (kalan adet), buyers:{sale42} (rezerve etmiş/almış kullanıcılar kümesi), pending:{sale42} (sorted set: userId → rezervasyon bitiş zamanı).
• PostgreSQL (kalıcı kayıt): flash_sale_orders(id, sale_id, user_id, reservation_id, status, amount, created_at) + UNIQUE (sale_id, user_id); kampanya stoğu için flash_sales(id, total_stock, sold) CHECK (sold <= total_stock). Bu constraint'ler son savunma hattıdır: Redis'te bir hata olsa bile veritabanı ikinci satışı ya da fazla satışı kabul etmez.
• {sale42} süslü parantezi Redis Cluster hash tag'idir: sadece parantez içi hash'lenir, böylece üç anahtar aynı slot'a, aynı node'a düşer. Bir Lua script'inin birden fazla anahtara atomik dokunabilmesi için anahtarların aynı slot'ta olması gerekir.

5. Yüksek seviye mimari

flowchart LR
    U[Mobil / Web istemci] --> CDN[CDN: statik sayfa, geri sayım]
    U --> GW[API Gateway: auth, rate limit, bot kontrolü]
    GW --> WR[Bekleme odası servisi]
    WR -->|admission token| GW
    GW --> RS[Rezervasyon servisi]
    RS -->|Lua script| R[(Redis: stok, alıcılar, bekleyen rezervasyonlar)]
    RS -->|reservation event| K[(Kafka)]
    K --> OS[Sipariş servisi: idempotent consumer]
    OS --> DB[(PostgreSQL: siparişler + outbox)]
    U --> PS[Ödeme servisi]
    PS -->|idempotency key| PSP[Ödeme sağlayıcısı]
    PS -->|confirm / release| R
    PS --> DB
    SW[Süresi dolan rezervasyon süpürücüsü] -->|expire script| R
    DB -->|outbox relay| K
    REC[Uzlaştırma job'ı] --> R
    REC --> DB

6. Deep dive: trafiği karşılamak

Katmanlı savunma; her katman bir sonrakinin yükünü azaltır:

1. CDN: Ürün sayfası, görseller ve geri sayım statiktir; origin'e hiç gelmez. Stok göstergesi istenirse "son birkaç saniyenin" değeri olarak CDN'de kısa TTL ile cache'lenir.
2. Gateway'de rate limit ve bot koruması: Kullanıcı ve cihaz başına limit (bkz. Bölüm 19), kimliği doğrulanmamış checkout isteği yok, bot tespiti (davranış sinyalleri, cihaz parmak izi, gerektiğinde CAPTCHA). Satış başlamadan önceki istekler ucuzca reddedilir.
3. Sanal bekleme odası (waiting room): Kullanıcılara sıra verilir ve sisteme checkout'un kaldırabileceği hızda alınırlar. Kabul edilen kullanıcı, kısa ömürlü ve imzalı bir admission token alır (ör. JWT: userId, saleId, geçerlilik süresi). Rezervasyon servisi token'ı doğrulamak için hiçbir yere sormaz (imza kontrolü), bu da kontrolü ucuzlatır. Kabul hızı, ödeme sağlayıcısının ve rezervasyon yolunun yük testinde ölçülen kapasitesine göre ayarlanır. Ek fayda: adalet ("ilk gelen önce") ve kullanıcıya dürüst bir sıra göstergesi. Hazır ürünler de var (CDN sağlayıcılarının waiting room servisleri).
4. Önceden ölçekleme: HPA metrik toplayıp pod açana kadar dalga geçmiş olur. Pod'lar 20:00'den önce hedef sayıya çıkarılır, connection havuzları ve cache'ler ısıtılır, bir gün önce aynı profille yük testi yapılır.
5. İzolasyon: Flash sale ayrı pod'larda (bulkhead) koşar; normal alışveriş trafiği aynı thread havuzlarını ve veritabanı connection'larını paylaşmaz.

7. Deep dive: overselling yok, müşteri başına bir

Stok sayacı Redis'tedir ve rezervasyon tek bir Lua script'tir. Redis script'i atomik çalıştırır, araya başka komut girmez; bu yüzden "kontrol et ve düş" adımları arasında yarış yoktur, kilit gerekmez:

-- KEYS[1]=stock:{sale42}  KEYS[2]=buyers:{sale42}  KEYS[3]=pending:{sale42}
-- ARGV[1]=userId  ARGV[2]=reservation expiresAt (epoch ms)
if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then
  return -1                                   -- bu kullanıcı zaten aldı / rezerve etti
end
local stock = tonumber(redis.call('GET', KEYS[1]) or '0')
if stock <= 0 then
  return 0                                    -- tükendi
end
redis.call('DECR', KEYS[1])
redis.call('SADD', KEYS[2], ARGV[1])
redis.call('ZADD', KEYS[3], ARGV[2], ARGV[1])
return 1                                      -- rezervasyon başarılı

Bu script stok 100 iken 300 farklı kullanıcıdan gelen 600 eşzamanlı istekle denendi: tam 100 rezervasyon, aynı kullanıcının ikinci denemesine -1, stok tam 0.

Neden veritabanında UPDATE ... SET stock = stock - 1 WHERE stock > 0 değil? Bu da doğru ve atomiktir, ama tek bir satıra on binlerce eşzamanlı güncelleme o satırın kilidinde sıraya girer: her transaction bir öncekinin commit'ini bekler, connection havuzu dolar, latency saniyelere çıkar. Bekleme odası kabul hızını birkaç yüz/s'ye indirebiliyorsa veritabanı yaklaşımı yeterli ve daha basittir; Redis, kabul hızının veritabanı satır kilidinin kaldıramayacağı kadar yüksek olduğu durum içindir. Mülakatta bu eşiği söylemek, "Redis kullanırım" demekten değerlidir.

8. Rezervasyondan ödemeye

Başarılı rezervasyonun bir bitiş zamanı vardır (ör. 10 dakika). Kullanıcı bu sürede öder; ödemezse birim stoğa döner ve sıradaki kullanıcılar alabilir.

Süresi dolanları geri vermek. pending sorted set'i bitiş zamanına göre sıralı tutar; birkaç saniyede bir çalışan bir süpürücü, süresi geçenleri atomik bir script'le iade eder:

-- KEYS: aynı üç anahtar  ARGV[1]=now (epoch ms)  ARGV[2]=batch size
local expired = redis.call('ZRANGEBYSCORE', KEYS[3], '-inf', ARGV[1], 'LIMIT', 0, ARGV[2])
for _, userId in ipairs(expired) do
  redis.call('ZREM', KEYS[3], userId)
  redis.call('SREM', KEYS[2], userId)        -- kullanıcı tekrar deneyebilir (iş kuralı)
  redis.call('INCR', KEYS[1])                -- birim stoğa geri döner
end
return #expired

Ödeme başarılı olunca onay aynı rezervasyonu pending'den atomik olarak çıkarır (ZREM, 1 dönerse satış kesinleşti). Onay ile süpürücü yarışırsa ikisi de atomik olduğu için sadece biri kazanır. Onay 0 dönerse rezervasyon süresi dolmuş ve stok iade edilmiştir: bu yüzden ödeme iki aşamalı yapılır: önce provizyon (authorize), sonra rezervasyonu onayla, onay başarılıysa tahsilat (capture), başarısızsa provizyonu iptal et (void). Böylece "para çekildi ama ürün başkasına gitti" durumu oluşmaz.

Ödeme çağrısı sağlayıcıya bir idempotency key ile gider; timeout "başarısız" değil "bilinmiyor" demektir, aynı anahtarla durum sorgulanır (bkz. Bölüm 18). Sağlayıcı çağrısı timeout, circuit breaker ve bulkhead ile korunur (bkz. Bölüm 14); sağlayıcı yavaşlarsa bekleme odasının kabul hızı düşürülür (backpressure).

9. Kalıcılık: siparişler veritabanına güvenilir şekilde nasıl ulaşır?

Rezervasyon başarılı olunca rezervasyon servisi Kafka'ya bir ReservationCreated event'i yazar (key = userId ya da reservationId). Sipariş servisi bu event'leri tüketip PostgreSQL'e yazar:

• Idempotent consumer: Kafka en az bir kez teslim eder; aynı event iki kez gelebilir. UNIQUE (sale_id, user_id) ve reservation_id üzerinde unique constraint ile ikinci yazma etkisiz kalır.
• Redis ile Kafka arasında dual-write: Lua script başarılı olup pod Kafka'ya yazamadan çökerse Redis'te rezervasyon var, siparişte yok. Rezervasyonun TTL'li olması bu durumu kendiliğinden iyileştirir: kullanıcı ödeme yapamaz (sipariş yok), rezervasyon süresi dolunca stok geri döner. Ödeme adımı siparişin veritabanında var olmasını şart koşar.
• Sipariş servisinden çıkan event'ler (ödeme alındı, kargoya hazır) veritabanı transaction'ıyla aynı anda outbox tablosuna yazılır ve bir relay ile Kafka'ya taşınır (bkz. Bölüm 13).
• Uzlaştırma (reconciliation) job'ı: Dakikada bir Redis'teki satılan adet, bekleyen rezervasyonlar ve veritabanındaki siparişleri karşılaştırır; farkları raporlar ve kurallı olanları düzeltir. Dağıtık bir sistemde "her şey tutarlı olacak" demek yerine "tutarsızlığı nasıl tespit edip düzelteceğim" demek senior bir cevaptır.

10. Cache, gözlemlenebilirlik ve başarısızlık senaryoları

Cache: Ürün detayı ve kampanya kuralları CDN ve lokal cache'te; kalan stok göstergesi kısa TTL ile (yaklaşık değer kabul). Stok kararının kendisi asla cache'ten verilmez; tek doğru kaynak Redis script'idir.

Gözlemlenebilirlik: Satış öncesi hazırlanmış bir dashboard: kalan stok, saniyelik rezervasyon / onay / iade sayısı, bekleme odası uzunluğu ve kabul hızı, 429 ve hata oranları (endpoint ve kod bazında), Redis latency ve CPU, Kafka consumer lag, ödeme sağlayıcısı latency ve circuit breaker durumu, uzlaştırma farkları. Alarmlar: "rezervasyon - sipariş farkı eşiği aştı", "consumer lag artıyor", "oversell kontrolü: satılan > toplam".

Başarısızlık senaryoları:

Hot key ve kovalar. Stok tek kovada tek node'dadır. Kabul hızı bir node'un kaldıramayacağı kadar yüksekse stok N kovaya bölünür (ör. 10 × 5.000), her kova kendi hash tag'iyle farklı slot'ta: stock:{sale42:3}, buyers:{sale42:3}. Ama "müşteri başına bir" kontrolü kovanın alıcı kümesindedir; kullanıcı rastgele kovaya giderse iki kovadan iki kez alabilir. Bu yüzden kullanıcı deterministik olarak kovasına yönlendirilir (hash(userId) % N). Bunun bedeli: kovası boşalan kullanıcı, başka kovalarda stok varken "tükendi" görür. Çözüm seçenekleri: kalan stoğu periyodik olarak kovalar arasında yeniden dağıtmak, ya da boş kovada alıcı kaydını kendi kovasında tutup başka kovadan stok almak (iki adım, telafi gerekir). Veritabanındaki UNIQUE (sale_id, user_id) her durumda son savunmadır. Bu karmaşıklık yüzünden kovalamaya ancak yük testi tek kovanın yetmediğini gösterirse geçilir.

11. Bilinçli olarak kapsam dışı bırakılanlar

Çok bölgeli (multi-region) aktif-aktif kurulum, dinamik fiyatlama, iade süreci, kargo entegrasyonu. Bunları söylemek "unuttum" değil "kapsamı yönetiyorum" mesajı verir.

Sistem tasarımında İngilizce: işe yarayan kalıplar

Mükemmel İngilizce gerekmez; yapı ve sinyal kelimeleri gerekir. Her adım için hazır cümleler:

Yaygın Türkçe kaynaklı hatalar: "I will make a reservation table" yerine "I'd create a reservations table"; "we can take the risk" yerine "we can accept that risk"; "it depends to" yerine "it depends on"; "more faster" yerine "faster". Cümleleri kısa tut; uzun cümlede dil hatası hem artar hem de fikrin kaybolur.

Code review: neye, hangi sırayla bakılır? (k6)

Review'da dikkat sınırlı bir kaynaktır; önce en pahalı hatalara harcanır:

1. Güvenlik: Injection, yetkilendirme (IDOR), hassas verinin log'lanması, secret'ların koda gömülmesi.
2. Doğruluk ve veri bütünlüğü: Kenar durumlar (boş liste, null, Optional.get()), eşzamanlılık (lost update), transaction sınırları, hata yönetimi.
3. Performans: N+1, sayfalamasız sorgu, index kullanamayan sorgu, döngüde dış çağrı.
4. Tasarım ve okunabilirlik: Katman sorumlulukları, isimlendirme, test edilebilirlik, API sözleşmesi.
5. Stil: Biçim, import sırası. Bunlar insanın değil formatter ve linter'ın işidir; CI'da otomatikleştir.

Yorumun ciddiyetini açıkça işaretle. Yazar hangi yorumun merge'ü engellediğini tahmin etmek zorunda kalmamalı. Yaygın bir standart Conventional Comments'tir: issue (blocking):, suggestion (non-blocking):, nitpick:, question:, praise:. Google'ın review rehberi de küçük önerilere Nit: önekini önerir ve önemli bir ilke koyar: PR mükemmel olmasa da kod tabanının genel sağlığını kesin olarak iyileştiriyorsa onaylanmalıdır. Mükemmeliyetçilik review'ı tıkar.

Yorumun dili: Kişiyi değil kodu konuş; ne, neden, nasıl üçlüsünü ver; mümkünse kod önerisiyle gel.

Zayıf:  "Bu yanlış."  /  "Neden böyle yaptın?"
İyi:    issue (blocking): `name` doğrudan SQL'e ekleniyor; "' OR '1'='1" tüm tabloyu
        döker. Parametreli sorgu kullanalım:
        jdbcTemplate.queryForList("SELECT id, name FROM customers WHERE name ILIKE ?", "%" + name + "%")
Soru:   question: Bu endpoint'i sadece admin mi çağırıyor? Değilse müşterinin kendi id'sini
        SecurityContext'ten almamız gerekir.
Övgü:   praise: Testlerin isimlendirmesi çok net, hata durumunu hemen anlatıyor.

Soru biçimindeki yorumlar ("Burada boş liste gelebilir mi?") hem yazara düşünme alanı bırakır hem de senin bir şeyi kaçırmış olma ihtimaline karşı alçakgönüllüdür. Büyük tasarım itirazlarını uzun yorum zincirleri yerine kısa bir görüşmeyle çöz, kararı PR'a not düş.

Küçük PR. Yüzlerce satırlık PR'lar dikkatli incelenemez; review kalitesi PR boyutu arttıkça düşer. Büyük işler feature flag arkasında, her biri kendi başına derlenen ve test geçen küçük PR'lara bölünür. Refactor ile davranış değişikliği ayrı PR (ya da en azından ayrı commit) olur.

İnsan yerine CI'ın yapması gerekenler: Formatter (Spotless), statik analiz (SpotBugs, Error Prone, SonarQube), bağımlılık güvenlik taraması (OWASP Dependency-Check, Dependabot), SAST, mimari kurallar (ArchUnit: "controller repository'ye doğrudan erişemez"), test ve coverage eşiği.

İyi commit (z11)

İyi bir commit:

• Atomiktir: Tek bir mantıksal değişiklik. "Refactor + yeni özellik + format düzeltmesi" üç commit'tir. Atomik commit tek başına geri alınabilir (git revert), cherry-pick edilebilir ve review'da anlaşılır.
• Her commit derlenir ve testleri geçer: Geçmişin her noktası çalışır durumda olduğu için git bisect ile hatanın girdiği commit ikili aramayla bulunabilir.
• Mesajı nedeni anlatır: "Ne" diff'te zaten görünür; mesaj "neden"i ve bağlamı anlatır.

Conventional Commits formatı: <type>[optional scope]: <description>, ardından boş satır, gövde ve footer'lar. Spesifikasyon feat (yeni özellik, semver minor) ve fix (hata düzeltme, semver patch) tiplerini tanımlar; uyumsuz değişiklik BREAKING CHANGE: footer'ı ya da tipten sonra ! ile belirtilir (semver major). refactor, test, docs, chore, build, ci, perf gibi diğer tipler spesifikasyonun izin verdiği, Angular geleneğinden gelen yaygın kullanımdır. Bu format otomatik changelog ve sürüm numarası üretimini mümkün kılar.

fix(shipping): reject unknown carrier instead of returning zero fee

Unknown carriers fell through the if/else chain and produced a fee of 0,
which meant free shipping for any typo in the carrier code.
Now an UnsupportedCarrierException is thrown and mapped to 400.

Refs: SHIP-142

Live coding'de commit atmak ilerlemeni görünür kılar: "characterization test eklendi", "strategy'ye refactor edildi, davranış aynı", "bilinmeyen kargo firması reddediliyor" gibi üç commit, mülakatçıya hem disiplinini hem düşünce sıranı anlatır.

Live coding oturumu: akış ve davranış

Spring tabanlı live coding mülakatlarında sık görülen bir format, yaklaşık iki saatlik, gerçek bir küçük kod tabanı üzerinde pair programming'dir (şirketten ve ekipten ekibe değişir): if/else ile yazılmış kargo hesaplamasını Strategy ile Open/Closed'a uygun hale getirmek, boş controller'ı doldurmak, endpoint isimlendirmesi, ortak RestTemplate kodunu toplamak, GlobalExceptionHandler eklemek, URL'leri konfigürasyona almak ve unit test yazmak. Bu tür görevlerde TDD, SOLID ve design pattern pratiklerinin uygulanması beklenir.

Örnek akış (2 saat):

Neye bakılıyor? Resmi bir rubrik yayınlanmıyor; pair programming mülakatlarının tipik boyutları:

Sesli düşünme kalıpları:

• "Önce gereksinimi doğru anladığımdan emin olayım: ... doğru mu?" (Let me make sure I understand the requirement correctly...)
• "Bu metoda dokunmadan önce mevcut davranışını bir testle sabitleyeceğim." (Before touching this, I'll pin down the current behavior with a test.)
• "Burada iki seçenek görüyorum: A ve B. A'yı seçiyorum çünkü..." (I see two options here. I'll go with A because...)
• "Önce en basit çalışan hali yazıyorum; testler yeşil olunca refactor edeceğim." (I'll write the simplest version first and refactor once the tests are green.)
• "Bilinmeyen kargo firmasında 0 TL dönüyor; bu bedava kargo demek. Hata mı dönelim, varsayılan ücret mi?" (There's an ambiguity: should an unknown carrier be an error or a default fee?)
• "Daha fazla zamanım olsaydı timeout, idempotency ve integration test eklerdim." (If I had more time, I'd add timeouts, idempotency and an integration test.)

Takılırsan: (1) Sesli söyle: "Şu an X'in neden null geldiğini anlamaya çalışıyorum"; sessizlik takılmaktan daha kötü görünür. (2) Bildiğini topla: ne bekledin, ne oldu? (3) Küçült: küçük bir test ya da debugger ile problemi izole et; stack trace'i birlikte oku. (4) Yön iste: "Hangi tarafa bakmamı önerirsiniz?" Pair programming'de ipucu istemek iş birliğidir. (5) Bir görev kilitlendiyse not al ve diğerine geç: "Buna sonra döneceğim."

Ortam tuzakları: Proje eski bir Spring sürümüyle gelebilir: Boot 2.x'te javax.*, 3.x'te jakarta.*; RestClient 3.2+, ProblemDetail Boot 3+. Lombok ya da Feign eklemek için build'le 15 dakika uğraşma; durumu söyle ve elle yaz (record'lar Lombok ihtiyacının çoğunu karşılar). JUnit 4 ve 5 annotation'larının karışması testlerin hiç çalışmamasına ("0 test") yol açar. Projenin wrapper'ını kullan (./gradlew test, ./mvnw test).

Davranışsal-teknik sorular ve STAR

"Kendinden bahset", "en zorlandığın teknik problem", "bir production incident'ı anlat", "bir teknik anlaşmazlığı nasıl çözdün" gibi sorular, teknik derinliğini gerçek bir hikaye üzerinden ölçer. Yapı için STAR:

• Situation (durum): Bağlam, 1-2 cümle. Sistem, ölçek, ekip.
• Task (görev): Senin sorumluluğun neydi, risk neydi.
• Action (eylem): Ne yaptın; "biz" değil "ben". Hikayenin ağırlığı burada olmalı: teşhis adımları, değerlendirdiğin seçenekler, neden birini seçtiğin.
• Result (sonuç): Ölçülebilir sonuç (latency %X düştü, incident süresi, hata oranı) ve ne öğrendin, neyi kalıcı olarak değiştirdin.

İki-üç dakikada bitir; mülakatçı ilgilendiği yeri soracaktır. Önceden 4-5 hikaye hazırla ve her birinin hangi soruya uyduğunu eşle: zor teknik problem, production incident, anlaşmazlık, hata yaptığın bir an, sahiplendiğin bir iyileştirme. Teknik hikayede mekanizmaya in: "yavaştı, düzelttim" değil, "p99 1,8 saniyeydi, trace'te zamanın %80'inin N+1 sorgularda geçtiğini gördüm".

Mülakatçıya sorulacak sorular

Soru sormak değerlendirmenin parçasıdır; ilgini ve neye önem verdiğini gösterir. Ezber "şirket kültürü nasıl?" yerine somut ve işle ilgili sorular:

• "Ekibin sahip olduğu domain ve servisler neler; en büyük teknik zorluğunuz şu an ne?"
• "Bir değişiklik merge'den production'a nasıl gidiyor, ne sıklıkla deploy ediyorsunuz?"
• "Code review kültürünüz nasıl; bir PR ortalama ne kadar sürede review ediliyor?"
• "On-call nasıl işliyor? Son ciddi incident'tan sonra ne değişti?"
• "Teknik borcu nasıl önceliklendiriyorsunuz?"
• "Bu pozisyonda ilk 6 ayda başarılı olmuş biri neyi başarmış olur?"
• "Test stratejiniz nasıl; integration test'leri nasıl koşuyorsunuz?"

Quiz'deki sorular: çözüm ve nedenleri

q20: Flash sale checkout tasarımı (İngilizce cevap)

Senaryo: 20:00'de 50.000 adet, müşteri başına 1, ilk dakikada ~2 milyon kullanıcı. Netleştirme ve kaba sayılar, trafik patlamasından korunma, overselling ve müşteri başına bir garantisi, rezervasyon ile ödeme arası, siparişlerin veritabanına güvenilir ulaşması ve başarısızlık senaryoları istenir.

Güçlü cevabın unsurları: (1) Netleştirme ve tahmin: ~33k rps ortalama, çok daha yüksek peak; sadece 50k başarılı olabileceği için trafiğin çoğu kenarda ucuzca reddedilmeli. (2) Koruma: CDN, gateway'de rate limit, bekleme odası, önceden ölçekleme, yük testi. (3) Redis'te tek atomik Lua script ile stok ve alıcı kontrolü; hash tag ile aynı slot; DB'de UNIQUE ve CHECK son savunma. (4) TTL'li rezervasyon ve iade. (5) Kafka + idempotent consumer + outbox + uzlaştırma. (6) Failover, hot key, ödeme sağlayıcısı yavaşlığı, dashboard ve alarmlar.

Model cevaptaki eksikler ve düzeltmeler:

• Keyspace expiry ile stok iadesi güvenilir değil. Model cevap, ödenmeyen rezervasyonun "delayed job or keyspace expiry" ile iade edilmesini öneriyor. Redis keyspace notification'ları Pub/Sub üzerinden gider ve fire-and-forget'tir: abone o an bağlı değilse event kaybolur. Ayrıca expired event'i TTL sıfıra ulaştığı an değil, anahtar fiilen silindiğinde (erişimde ya da arka plandaki temizlikte) üretilir; gecikebilir. Stok iadesi gibi para değerinde bir işlem buna bağlanmamalı. Yukarıdaki gibi bitiş zamanına göre sıralı bir sorted set ve periyodik, atomik bir süpürücü script'i (ya da veritabanı tabanlı bir zamanlanmış iş) güvenilirdir.
• "2M kullanıcı ≈ 33k rps" kullanıcı başına tek istek varsayar. Yenileme, polling ve retry'larla kenardaki istek sayısı bunun birkaç katıdır; kapasite planı buna göre yapılmalı.
• Hot key için "stoğu N kovaya böl" önerisi tek başına "müşteri başına bir" garantisini bozar. Alıcı kontrolü kovanın kümesindeyse kullanıcının deterministik olarak tek kovaya yönlendirilmesi gerekir; bunun da "kovası boşalan kullanıcı" problemi vardır (yukarıda anlatıldı).
• WAIT güçlü tutarlılık sağlamaz. Redis dokümantasyonu da WAIT'in Redis'i güçlü tutarlı bir store yapmadığını belirtir; failover'da yazma kaybı riskini azaltır, ortadan kaldırmaz. Asıl güvence veritabanı constraint'leri ve uzlaştırmadır (model cevap bunlardan da bahsediyor, doğru).
• Ödeme ile rezervasyon onayı arasındaki yarış model cevapta yok: rezervasyon süresi dolduktan hemen sonra gelen başarılı ödeme. Provizyon → atomik onay → tahsilat (ya da provizyon iptali) sırası bu durumu kapatır.

İngilizce için öneriler: "We will do a queue" yerine "We'll put users in a virtual waiting room"; "Redis is very fast so no problem" yerine "Redis executes the script atomically, so no locks are needed"; "maybe it can fail" yerine "One failure mode is...".

k6: Bu PR'ı inceleyip yorum yaz

Senaryo: CustomerController'da string birleştirmeyle kurulan bir LIKE sorgusu, siparişleri listeleyen ve log'a e-posta ile kart numarası yazan bir metot, private ve @Transactional bir updatePoints ile puan ekleyen bir POST. Yazar "küçük bir değişiklik, hızlıca onaylar mısın?" diyor.

Bulgular, ciddiyet sırasıyla:

Neden bu sıra? Güvenlik ve veri bütünlüğü hataları geri alınamaz zarar verir (sızan veri geri toplanamaz); performans ve tasarım problemleri sonradan düzeltilebilir. "Küçük değişiklik, hızlıca onayla" baskısına rağmen blocker'lar varken onay verilmez; ama ton yapıcı kalır.

Takip sorularına kısa cevaplar: Junior ve hassas bir yazara: blocker'ları net ama kişisizleştirilmiş yaz, bir övgüyle başla, büyük konular için "10 dakika birlikte bakalım mı?" de; öğretici linkler ekle. Katılmadığın bir yorum gelirse: önce gerekçeyi anlamaya çalış, kendi gerekçeni veriyle söyle, ikinci turda hâlâ anlaşamıyorsanız kısa bir görüşme ya da üçüncü bir kişinin görüşü; ego değil kod tabanının sağlığı.

z11: Live coding sırasında iyi commit pratikleri

Doğru: a, c, d.

• a) fix: reject unknown carrier instead of returning zero fee: Tip, ne değiştiği ve davranış farkı net; Conventional Commits formatında.
• c) Refactor ile davranış değişikliğini ayrı commit'lerde yapmak: Refactor commit'i "davranış aynı" iddiasını taşır ve testlerle doğrulanır; davranış değişikliği ayrı olunca review kolaylaşır, gerekirse tek başına geri alınır.
• d) Her commit'te testlerin geçmesi: Geçmişin her noktası çalışır; git bisect kullanılabilir.

Yanlış:

• b) changes / WIP / fix: Hiçbir bilgi vermez; altı ay sonra git log ve git blame işe yaramaz hale gelir.
• e) Sonda tek büyük commit: İlerleme görünmez, review zorlaşır, bir kısmı geri alınamaz; live coding'de süre biterse yarım kalan iş ile tamamlanan iş ayırt edilemez.

Production karşılığı: Conventional Commits otomatik changelog ve semantic versioning araçlarını besler; squash-merge kullanılan ekiplerde PR başlığı da bu formatta yazılır. Commit mesajında ticket referansı (Refs: SHIP-142) izlenebilirlik sağlar.

z13: Live coding'in ilk 10 dakikası

Doğru: b) Projeyi build edip testleri çalıştırmak, yapıyı hızlıca gezmek, belirsizlikleri sormak, görevleri önceliklendirip planı sesli söylemek. Bu adımlar üç şeyi birden gösterir: ortamın çalıştığından emin olma disiplini (kırık bir test varsa baştan söylemek, sonradan "ben mi bozdum?" belirsizliğini önler), problemi anlama ve önceliklendirme. "Önce şunları yapacağım, şu sırayla; uygun mu?" cümlesi mülakatçıyı sürecin ortağı yapar; mülakatçının önceliği farklıysa bunu dakika 10'da öğrenmek, dakika 60'ta öğrenmekten iyidir.

• a) Hemen ilk maddeyi kodlamak: Projeyi anlamadan yazılan kod genelde geri alınır; mülakatçı soru sorup sormadığına da bakar.
• c) Tüm projeyi kendi beğendiğin yapıya göre düzenlemek: Görev dışı, riskli ve zaman yiyici; kapsam mülakatçıyla birlikte belirlenir.
• d) Sessizce okuyup tam plan çıkana kadar konuşmamak: Mülakatçı düşünce sürecini göremez; sesli düşünmek beklenir.

Ana kavram: Çoğu zaman listedeki her şeyi bitirmen beklenmez; doğru önceliklendirme, çalışan küçük adımlar ve iletişim değerlendirilir. İki görevi testleriyle bitirmek, altı görevi yarım bırakmaktan iyidir.

Üç seviyede cevap

Soru: "Bir PR'ı nasıl review edersin? İyi bir commit'in kriterleri neler?"

Soru: "Kendinden bahseder misin?"

Soru: "Karşılaştığın en zor teknik problemi anlatır mısın?"

Soru: "Yaşadığın bir production incident'ını anlatır mısın?"

Sorulmadı ama sorulabilir

Bildirim sistemi tasarımı (kısa)

"Sipariş durumu değişince kullanıcıya push, SMS ve e-posta gönder." Ana fikirler: sipariş servisi event yayınlar (outbox ile), bildirim servisi tüketir; kanal başına ayrı kuyruk/topic ki yavaş SMS sağlayıcısı push'u bekletmesin; kullanıcı tercihleri ve sessiz saatler; şablonlar; aynı event'in tekrar gelmesine karşı event_id ile tekilleştirme (aksi halde aynı SMS iki kez gider ve para tutar); sağlayıcı hatasında backoff ile retry, sınır aşılırsa DLT; sağlayıcı rate limit'lerine uymak için çıkış tarafında throttling; gönderim durumu takibi ve teslim raporu (webhook). Ölçek: kampanya bildirimlerinde milyonlarca mesajın sağlayıcı limitlerine göre yayılarak gönderilmesi.

Tek cümle: "Event tabanlı, kanal başına izole, idempotent ve sağlayıcı limitine göre throttle eden bir bildirim hattı kurarım."

Cache stratejileri ve cache stampede

Cache-aside (uygulama önce cache'e bakar, yoksa DB'den okuyup yazar; en yaygın), read-through/write-through (cache katmanı DB'yi kendisi okur/yazar), write-back (yazma önce cache'e, DB'ye sonra; hızlı ama veri kaybı riski). Stampede: Popüler bir anahtarın süresi dolunca binlerce istek aynı anda DB'ye gider. Önlemler: aynı anahtar için tek yükleme (request coalescing; Caffeine get(key, loader), dağıtıkta kısa kilit), süresi dolmadan arka planda yenileme (refreshAfterWrite), TTL'lere rastgele sapma (jitter) ekleyip toplu süre dolmasını önlemek.

Tek cümle: "Varsayılanım cache-aside; popüler anahtarlarda stampede'e karşı tek yükleme, erken yenileme ve TTL jitter kullanırım."

Partition/shard anahtarı seçimi

Kafka partition key'i, veritabanı shard anahtarı ve Redis hash tag'i aynı soruyu sorar: hangi veriler birlikte olmalı (sıralama, atomiklik, join) ve yük eşit dağılıyor mu? Sipariş event'lerinde orderId key'i sipariş içi sıralamayı korur ve iyi dağılır; sellerId büyük satıcılarda hot partition yaratır. Kural: erişim desenine göre seç, kardinalite ve çarpıklığı (skew) ölç, sıcak anahtarlar için anahtarı tuzla (salt) ya da ayrı ele al.

Tek cümle: "Partition anahtarını sıralama ve birlikte erişim gereksinimine göre seçer, çarpıklığı ölçer, sıcak anahtarları ayrıca ele alırım."

"Bu kod tabanında nereyi iyileştirirsin?" (case study review)

Senior varyasyonunda yarım kalmış bir case study'yi inceleyip iyileştirme önermen istenebilir. Yapı: önce çalıştır ve testleri koş; sonra riske göre sırala (doğruluk ve veri bütünlüğü, güvenlik, hata yönetimi, test eksikliği, sonra tasarım ve okunabilirlik); her öneri için "şu an ne riski var, ne kadar sürer" söyle; hepsini yapmaya kalkma, en yüksek etki/maliyet oranlı ikisini canlı yap. "Neden CQRS kullandın?" gibi sorulara hazır ol: her mimari kararın bir gerekçesi ve bir bedeli olmalı; "kullanmasaydım ne olurdu?" sorusunu kendine önceden sor.

Tek cümle: "İyileştirmeleri risk ve maliyete göre sıralar, en yüksek getirili iki tanesini testleriyle canlı yaparım, geri kalanını gerekçesiyle listelerim."

Trunk-based development ve feature flag'ler

Uzun yaşayan branch'ler merge conflict ve entegrasyon riskini biriktirir. Trunk-based development'ta herkes küçük değişikliklerle sık sık ana branch'e merge eder; bitmemiş işler feature flag arkasında kapalı durur. Flag'ler kademeli açma (yüzde 1, 10, 100), anında geri alma ve A/B testi sağlar. Bedeli: flag borcu; kullanılmayan flag'ler düzenli temizlenmelidir, aksi halde kod test edilmesi zor kombinasyonlarla dolar.

Tek cümle: "Küçük ve sık merge, bitmemiş işi flag arkasında tutmak; flag'leri de teknik borç olarak takip edip temizlemek."

Teknik anlaşmazlık

"Takım arkadaşınla teknik bir konuda anlaşamadığın bir durum?" STAR ile, ama odak süreçte: varsayımları ayırmak, karşı tarafın gerekçesini kendi cümlenle tekrar etmek, kararı veriye dayandırmak (küçük bir prototip, benchmark, yük testi), karar verilince "disagree and commit", ve kararı yazılı bir ADR'ye (Architecture Decision Record) dökmek. Kaybettiğin bir tartışmayı anlatmak, kazandığını anlatmaktan çoğu zaman daha güçlü bir sinyaldir.

Tek cümle: "Anlaşmazlığı kişiden ayırıp veriyle çözerim; karar çıkınca katılmasam da arkasında dururum ve kararı yazılı hale getiririm."

Sık yapılan hatalar

• Sistem tasarımında netleştirmeden çizime başlamak → Yanlış problemi tasarlarsın, en zor kısma süre kalmaz → İlk 5 dakika gereksinim ve tahmin, sonra yönlendirmeli ilerle.
• Her kutuya bir teknoloji adı koyup mekanizmayı anlatmamak → "Kafka koyarım" bir cevap değildir → Neden, nasıl (key, idempotent consumer), ne bozulursa ne olur.
• Tek doğru kaynağı belirsiz bırakmak → Stok kararı hem cache'ten hem DB'den verilir, tutarsızlık → Karar tek bir atomik noktada, diğerleri türetilmiş ve uzlaştırılmış.
• Güvenilmez mekanizmaya para değerinde iş bağlamak → Keyspace notification kaybolur, stok iade edilmez → Sıralı küme + periyodik atomik süpürücü ya da kalıcı zamanlanmış iş.
• Başarısızlık senaryolarını atlamak → Tasarım sadece mutlu yolda çalışır → Her bileşen için "düşerse ne olur" ve gözlemlenebilirlik.
• PR'da stil yorumlarıyla blocker'ları karıştırmak → Yazar neyin önemli olduğunu ayırt edemez → Ciddiyet etiketi; stil linter'a.
• Kişiyi eleştiren yorum ("Bunu neden böyle yaptın?") → Savunmacılık, review kültürü bozulur → Kodu konuş, ne-neden-nasıl, öneriyle gel.
• WIP/fix commit mesajları, sonda tek dev commit → Geçmiş okunamaz, geri alma ve bisect imkansız → Atomik, yeşil, nedeni anlatan commit'ler.
• Live coding'de sessiz kalmak → Mülakatçı düşünceni göremez → Sesli düşün, her 15-20 dakikada durum özeti.
• Build/bağımlılık problemiyle uzun süre boğuşmak → Görev zamanı erir → Söyle, alternatif yol (elle yaz), devam et.
• Mülakatçının önerisine direnmek → İş birliği sinyali düşer → Gerekçeni söyle, sonra birlikte karar ver.
• Davranışsal soruda "biz" ile anlatmak, sonucu ölçmemek → Katkın görünmez → "Ben", sayılarla sonuç, öğrenme.
• Hikaye uydurmak ya da süslemek → Takip sorularında çöker → Gerçek hikayeleri önceden yapılandır.
• Soru sormadan bitirmek → İlgisizlik sinyali → İşle ilgili 2-3 somut soru hazırla.

Hızlı tekrar

Kaynaklar

• Redis: Scripting with Lua: Script atomikliği ve cluster'da anahtarların neden argüman olarak verilmesi gerektiği.
• Redis: Keyspace notifications: Pub/Sub'ın fire-and-forget olduğu ve expired event'lerinin zamanlamasının neden garanti olmadığı.
• Transactional outbox pattern (microservices.io): Veritabanı ve mesaj kuyruğu arasındaki dual-write probleminin standart çözümü.
• AWS Builders' Library: Making retries safe with idempotent APIs: Büyük ölçekte idempotency tasarımı.
• AWS Builders' Library: Timeouts, retries, and backoff with jitter: Retry storm'ları ve jitter'ın neden gerektiği.
• The System Design Primer: Cache, sharding, CAP ve örnek tasarımlarla geniş bir çalışma rehberi.
• Google Engineering Practices: How to do a code review: Onay ölçütü, yorum yazma ve "Nit:" kullanımı.
• Conventional Comments: Review yorumlarını ciddiyet ve niyetle etiketleme formatı.
• Conventional Commits 1.0.0: Commit mesajı spesifikasyonu ve semver ilişkisi.
• Martin Kleppmann, Designing Data-Intensive Applications: Replikasyon, tutarlılık ve stream işleme konularında sistem tasarımı cevaplarının teorik temeli.