ilik. `java.util.concurrent` de garanti verir: bir `ConcurrentHashMap`'e `put`, aynı key'i okuyan `get`'ten; `executor.submit` görevin çalışmasından; görevin bitişi `Future.get()`'ten önce olur. Data race içermeyen program sequential consistency garantisi alır; race varsa sezgiye aykırı sonuçlar mümkündür. Klasik örnekler: volatile olmayan bir `running` bayrağında JIT döngü koşulunu bir kez okuyup sonsuz döngü üretebilir; double-checked locking `volatile` olmadan yarı kurulmuş nesne yayınlayabilir. Bu hatalar x86'da gizlenip ARM'da (Graviton, Apple Silicon) çıkabilir; bu yüzden doğruluğu testle değil happens-before argümanıyla kurar, gerekirse jcstress ile doğrularım. Virtual thread'ler JMM'yi değiştirmez (bkz. Kitap Bölüm 5).6a:T496,Sırayla düşünürüm: paylaşmamak, değiştirmemek, ancak sonra senkronize etmek. Senkronizasyonda invariant'ı neyin koruduğunu açıkça yazarım: bir hesap bakiyesi ve hareket listesi birlikte değişiyorsa ikisi aynı kilidin altındadır; ayrı ayrı thread-safe iki alan, bileşik invariant'ı korumaz. `ConcurrentHashMap.compute` atomiktir ama fonksiyon kilit altında çalışır; içinde uzun iş ya da aynı map'e başka bir yazma yapmam. Kilit sırası sabit değilse (A→B ve B→A) deadlock olur; iki hesap arası transferde kilitleri hesap ID'sine göre sıralarım. Okuma ağırlıklı yapılarda `CopyOnWriteArrayList` ya da immutable snapshot + `AtomicReference`, sık yazılan metrik sayaçlarında `LongAdder` kullanırım. Java 21 virtual thread'lerinde `synchronized` blok içinde bloklayan I/O, thread'i taşıyıcıya sabitler (pinning); JDK 24 bunu büyük ölçüde çözdü, Java 21'de uzun I/O tutan kritik bölgelerde `ReentrantLock` tercih ederim. Tek JVM içindeki thread safety, çok instance'lı bir serviste veri tutarlılığı sağlamaz; orada veritabanı kilidi ya da optimistic locking gerekir (bkz. Kitap Bölüm 5 ve Bölüm 10).6b:T480,Yaşam döngüsünü proxy'nin nerede doğduğuyla anlatırım: `BeanFactoryPostProcessor`'lar tanımları değiştirir (ör. `${...}` çözümü), sonra her bean için örnekleme, injection, `BeanNameAware`/`ApplicationContextAware`, `postProcessBeforeInitialization` (`@PostConstruct`'ı `CommonAnnotationBeanPostProcessor` çağırır), `InitializingBean.afterPropertiesSet`, init-method ve `postProcessAfterInitialization`; `@Transactional`, `@Async` proxy'leri bu son adımda oluşur. Sonuç: `@PostConstruct` içinde kendi `@Transactional` metodumu çağırırsam transaction açılmaz, çünkü proxy henüz yok ve çağrı zaten `this` üzerinden. Tüm singleton'lar hazır olunca iş yapmak için `SmartInitializingSingleton` ya da `ApplicationReadyEvent` dinlerim; cache ısıtma gibi işler oraya gider. Kapanışta ters sırayla `@PreDestroy`, `DisposableBean`, destroy-method çalışır; graceful shutdown ile istekler biter. Scope seçiminde varsayılan singleton ve stateless'tır; kullanıcıya özgü durumu singleton alanında tutmak, kullanıcıların birbirinin verisini görmesine yol açan klasik hatadır (bkz. Kitap Bölüm 6).6c:T514,Akışı `refresh()` etrafında anlatırım. Boot 3'te auto-configuration listesi `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports` dosyalarından okunur (eski `spring.factories` anahtarı Boot 3'te kaldırıldı) ve `DeferredImportSelector` olduğu için kullanıcı konfigürasyonundan sonra değerlendirilir; `@ConditionalOnMissingBean`'in çalışmasının nedeni bu sıralamadır. `refresh()` adımları: `invokeBeanFactoryPostProcessors` (`ConfigurationClassPostProcessor` scan, `@Import` ve `@Bean` tanımlarını üretir), `registerBeanPostProcessors`, `onRefresh` (servlet context'te gömülü Tomcat burada oluşturulur), `finishBeanFactoryInitialization` (singleton'lar, injection, proxy'ler), `finishRefresh` (lifecycle bean'leri başlar, web sunucusu port'u dinlemeye başlar). Ardından `ApplicationStartedEvent`, runner'lar ve `ApplicationReadyEvent`; Kubernetes'te readiness `ACCEPTING_TRAFFIC` olur. Açılış sorunlarını `--debug` ile condition evaluation report'u ya da `/actuator/conditions` ile, süreyi `BufferingApplicationStartup` ve `/actuator/startup` ile incelerim. Açılış süresini düşürmek için gereksiz starter'ları kaldırmak, lazy initialization (dikkatle), CDS ve AOT/native image seçenekleri var (bkz. Kitap Bölüm 24).6d:T46e,Zinciri adım adım söylerim: Boot'un `TransactionAutoConfiguration`'ı transaction yönetimini açar; bir auto-proxy creator, `BeanFactoryTransactionAttributeSourceAdvisor`'ın pointcut'ına uyan bean'leri `postProcessAfterInitialization` aşamasında proxy'ler. Çağrıda `TransactionAspectSupport.invokeWithinTransaction`, `AnnotationTransactionAttributeSource`'tan metodun attribute'unu okur, doğru transaction manager'ı seçer ve `getTransaction` çağırır: propagation'a göre katılır, askıya alır (`REQUIRES_NEW`) ya da savepoint açar (`NESTED`, JDBC'de). `TransactionSynchronizationManager` connection holder'ı ve synchronization'ları thread'e bağlar; `@TransactionalEventListener` ve `afterCommit` callback'leri buradan çalışır. Rollback kararı `RuleBasedTransactionAttribute` ile verilir; iç bir `REQUIRED` metot exception atıp dıştaki onu yakalarsa transaction rollback-only işaretlenir ve dış commit'te `UnexpectedRollbackException` alınır. Transaction bağlamı `ThreadLocal`'da olduğu için `@Async`, `CompletableFuture.supplyAsync` ya da yeni bir thread'e taşınmaz (bkz. Kitap Bölüm 8).6e:T611,Listeyi etkisine göre sıralarım. (1) Self-invocation: çözüm metodu ayrı bean'e taşımak ya da `TransactionTemplate` ile programatik sınır; kendi proxy'sini enjekte etmek çalışır ama tasarım kokusudur. (2) Görünürlük: Spring 6'dan itibaren class tabanlı (CGLIB) proxy'lerde protected ve package-private metotlar da transactional olabilir, private ve final metotlar olamaz; arayüz proxy'lerinde metot public olmalı. (3) Rollback kuralları: checked exception commit eder; Spring Framework 6.2 ile `@EnableTransactionManagement(rollbackOn = ALL_EXCEPTIONS)` ile varsayılan değiştirilebilir. İç metotta atılıp dışta yakalanan exception rollback-only bırakır ve `UnexpectedRollbackException` gelir. (4) Transaction'da dış çağrı: ödeme servisine HTTP isteği transaction içindeyse hem connection tutulur hem de rollback dış sistemi geri almaz; outbox ya da `afterCommit` ile ayırırım. (5) `REQUIRES_NEW` her seviyede ayrı connection ister; pool küçükse eşzamanlı yükte kendi kendine deadlock olur. (6) `readOnly = true` bir garanti değil ipucudur; Hibernate'te flush'ı kapatır, bazı veritabanlarında read-only transaction açar. (7) Lazy loading transaction dışında `LazyInitializationException` verir; Boot'ta `spring.jpa.open-in-view` varsayılan açık olduğu için bu hata gizlenir ve connection view render'ına kadar tutulur; kapatırım. (8) Birden fazla `DataSource` varsa yanlış transaction manager seçilebilir; `@Transactional("ledgerTx")` ile açık belirtirim (bkz. Kitap Bölüm 8).6f:T519,Sırayla: önce hangi sorgunun önemli olduğunu bulurum (`pg_stat_statements`'ta toplam süreye göre sıralama; tek seferlik yavaş sorgu ile saniyede bin kez çalışan 20 ms'lik sorgu farklı önceliktedir). Sonra `EXPLAIN (ANALYZE, BUFFERS)` ile tahmini ve gerçek satır sayılarını karşılaştırırım; büyük sapma istatistik sorunudur ve index eklemek çözmez. Index tasarımında sorgunun tamamına bakarım: `WHERE customer_id = ? AND status = ? ORDER BY created_at DESC LIMIT 20` için `(customer_id, status, created_at DESC)` hem filtreyi hem sıralamayı karşılar; `INCLUDE` ile covering yaparsam tabloya hiç gitmez. Index'in yazma maliyeti var; her yeni index insert'i yavaşlatır, kullanılmayanları `pg_stat_user_indexes` ile bulup silerim. PostgreSQL foreign key kolonlarına otomatik index açmaz (MySQL InnoDB açar); join ve cascade için gerekir. Production'da index'i `CREATE INDEX CONCURRENTLY` ile eklerim. Denormalizasyon son araçtır: yazma tarafına tutarlılık maliyeti getirir, bu yüzden önce materialized view ya da event ile güncellenen bir okuma modeli düşünürüm. Uygulama tarafında N+1, gereksiz entity yükleme ve connection pool beklemesi de "yavaş sorgu" gibi görünür; ölçmeden veritabanını suçlamam (bkz. Kitap Bölüm 9 ve Bölüm 10).70:T484,Karşılaştırmayı "protokol mü, format mı" ve "kim neyi doğruluyor" ekseninde kurarım. OAuth 2.0 yetkilendirmedir, kimlik doğrulama değil; "kullanıcı kim" sorusunu OpenID Connect cevaplar. Güncel güvenlik önerisi (OAuth 2.0 Security BCP, RFC 9700) implicit ve password grant'ları bırakıp authorization code + PKCE kullanmayı söyler. Access token'ın formatı bir tasarım kararıdır: JWT (RFC 9068 profili) resource server'ın yerel doğrulama yapmasını sağlar, gecikme ve authorization server bağımlılığı düşer ama token süresi dolana kadar iptal etmek zordur; opak token ise her istekte introspection (RFC 7662) gerektirir ama anında iptal edilebilir. JWT doğrularken `alg`'ı token'dan değil konfigürasyondan alırım (`none` ve algoritma karıştırma saldırıları), imzayı JWKS'teki `kid` ile seçilen anahtarla doğrularım, `iss`, `aud` ve `exp`'i kontrol ederim. Payload'a hassas veri koymam; şifreleme gerekiyorsa JWE, ama çoğu zaman doğru cevap veriyi token'a koymamaktır. Spring tarafında `spring-boot-starter-oauth2-resource-server` ile `issuer-uri` vermek JWKS keşfini ve bu doğrulamaları yapar.71:T487,Önce gereksinimi netleştiririm: "logout" ile "hesap ele geçirildi, tüm oturumları şimdi kapat" farklı aciliyetlerdir. Varsayılan tasarım: 5 dakikalık access token, sunucu tarafında saklanan ve rotate edilen refresh token; logout ve parola değişikliğinde refresh token ailesi iptal edilir, en kötü durumda iptal 5 dakika gecikir. Anında iptal gerekiyorsa iki seçenek: `jti` denylist'i (sadece iptal edilen token'lar tutulur, TTL ile kendiliğinden temizlenir, liste küçüktür) ya da kullanıcı başına `revokedBefore` zaman damgası (tek kayıtla tüm oturumları kapatır). İkisi de JWT'nin "durumsuz" avantajını kısmen geri alır: her istekte bir Redis okuması. Bunu gateway'de yapar, kısa süreli yerel cache ve Redis pub/sub ile yayarım. Anahtar rotasyonu tüm token'ları birden geçersiz kılar; olay müdahalesinde kullanılır, normal logout'ta değil. Bankacılıkta yüksek riskli işlemler için çoğu zaman opak token + introspection ya da işlem anında ek doğrulama daha dürüst bir çözümdür; "JWT kullanıp her istekte merkeze sormak", opak token'ın maliyetini JWT'nin karmaşıklığıyla ödemek olabilir.72:T56f,Algoritmayı gereksinime göre seçerim. Kesin "herhangi 60 saniyede 5" için sliding window log; limit 5 olduğu için kullanıcı başına en fazla 5 `long`, yani log yaklaşımının bilinen bellek sorunu burada yok. Patlamaya izin verilen bir API kotası için token bucket (kapasite 5, 12 saniyede bir token) daha doğal ve iki sayıyla ifade edilir. Fixed window sadece kaba sınırlar için. Tasarım: `RateLimiter` arayüzü (`boolean tryAcquire(String userId)`), saat soyutlaması (monotonik, `System.nanoTime` tabanlı; duvar saati geri atlayabilir), kullanıcı başına küçük bir durum nesnesi ve kilit kapsamının yalnızca o kullanıcı olması. Bellek için idle kullanıcıları temizlerim: Caffeine'de `expireAfterAccess(1 dakika)` ya da periyodik süpürme; aksi halde her yeni kullanıcı kalıcı bir girdi bırakır ve bu bir bellek sızıntısıdır. Anahtar kimliği doğrulanmış kullanıcı ID'si; anonim uçlarda IP, ama NAT arkasındaki kullanıcıları cezalandırabileceğini bilirim. Spring'de servlet `Filter` ya da `HandlerInterceptor` içinde uygular, 429 ile `Retry-After` (en eski zaman damgası + 60 saniye − şimdi) dönerim; Bucket4j gibi bir kütüphane de bu işi yapar. Testleri sahte saatle yazarım: 5 kabul, 6. ret, 60 saniye sonra tekrar kabul, ve aynı kullanıcıya 100 thread'den eşzamanlı istekte tam 5 kabul (bkz. Kitap Bölüm 19).73:T56d,Önce rate limiter'ın nerede duracağına karar veririm: gateway'de olursa tüm servisler korunur (Spring Cloud Gateway'in `RedisRateLimiter`'ı token bucket'ı Redis'te Lua ile uygular; dakika başı limitler `replenishRate`, `burstCapacity` ve `requestedTokens` birlikte ayarlanarak ifade edilir). Redis tarafında sliding window log'u sorted set ve Lua ile kurarım; üye olarak zaman damgası artı istek ID'si kullanırım ki aynı milisaniyedeki iki istek birbirini ezmesin. Redis Cluster'da bir kullanıcının anahtarları hash tag ile (`rate:{user42}`) aynı slot'a düşer. Bedeli her istekte bir Redis gidiş-dönüşüdür; yük çok yüksekse kullanıcıyı tutarlı hashing ile hep aynı instance'a yönlendirip yerel limiter kullanırım ya da yerel ön sayaç + periyodik senkron gibi yaklaşık yöntemlere geçerim; "dakikada 5" gibi küçük ve kesin bir limitte yaklaşık yöntemler hatayı büyütür, bu yüzden merkezi sayacı tercih ederim. Çöküş davranışı bir iş kararıdır: genel API'de fail open ve instance başına kaba bir yerel limit, login ya da OTP gibi kaba kuvvete açık uçlarda fail closed. Redis'i replika ile çalıştırırım ama failover'da birkaç saniyelik sayaç kaybını kabul ederim. Metrikler: kabul/ret oranı, Redis gecikmesi, fail-open'a düşme sayısı (bkz. sistem tasarımı: dağıtık rate limiter ve Kitap Bölüm 19).74:T446,One evening our account API's error rate jumped to around 30%. I was on call, so I took the incident commander role and opened a channel so updates were in one place. First question: what changed? A release had gone out an hour earlier, but the metrics pointed elsewhere: the HikariCP pool was exhausted, and the slow query log showed a new reporting endpoint scanning a large table. The fastest safe mitigation was the feature flag on that endpoint, not a full rollback, because the release also contained a regulatory fix. Error rate went back to normal in about eight minutes from the alert. I posted updates every fifteen minutes for the business side in plain language. The next day I ran a blameless postmortem. The root cause wasn't the query alone; it was that reporting traffic shared the same pool as customer traffic. We moved reporting to a read replica with its own pool, added statement timeouts, and added an alert on pool saturation, which had been missing. The part I'd do differently: I should have pulled in the DBA earlier instead of digging alone for the first ten minutes.8:[["children",{"s":"__PAGE__","h":512,"d":{"r":["$","$1","c",{"children":[[["$","header",null,{"className":"mb-8","children":[["$","div",null,{"className":"mb-2 text-xs font-semibold tracking-[0.08em] text-accent uppercase","children":"Pratik yap"}],["$","h1",null,{"className":"text-3xl font-bold tracking-tight text-balance sm:text-4xl","children":"Rastgele quiz"}],["$","p",null,{"className":"mt-3 max-w-2xl text-[16px] leading-relaxed text-ink-2","children":"Çoktan seçmeli sorular, kitaptaki mülakat soruları ve tekrar kartları tek havuzda. Tür ve konu seç, rastgele bir set oluştur; yanlış yaptıkların ayrı bir destede toplanır."}],"$undefined"]}],["$","$Lb",null,{"pool":[{"kind":"mcq","id":"t-q1","category":"Java","label":"Teknik mülakat provası · Java · Concurrency","bodyHtml":"

Sayaç ve fiyat cache'i: 64 thread altında ne bozulur?

Ürün sayfası servisi her görüntülenmede sayacı artırıyor ve fiyatı harici bir fiyatlama servisinden çekip cache'liyor. Servis tek pod'da, Tomcat'in 64 istek thread'iyle çalışıyor.

@Service\npublic class ProductViewService {\n\n    private volatile long totalViews = 0;\n    private final Map<Long, Price> priceCache = new ConcurrentHashMap<>();\n    private final PricingClient pricingClient;\n\n    public void onView(long productId) {\n        totalViews++;\n    }\n\n    public Price price(long productId) {\n        if (!priceCache.containsKey(productId)) {\n            priceCache.put(productId, pricingClient.fetch(productId)); // ~80 ms HTTP\n        }\n        return priceCache.get(productId);\n    }\n}

Hangi ifadeler doğru? Birden fazla seçenek işaretleyebilirsin.

","multi":true,"options":[{"id":"a","ok":false,"html":"volatile sayesinde totalViews++ atomiktir; sayaç doğru kalır.","whyHtml":"Yanlış. volatile görünürlük (visibility) ve sıralama garantisi verir, atomiklik vermez. ++ işlemi oku, 1 ekle, yaz olmak üzere üç adımdır."},{"id":"b","ok":true,"html":"totalViews++ oku-artır-yaz adımlarından oluşur. İki thread aynı değeri okuyup aynı sonucu yazabilir, artışlar kaybolur.","whyHtml":"Doğru. Bu klasik bir lost update. volatile sadece en son yazılan değeri görmeyi garanti eder."},{"id":"c","ok":true,"html":"AtomicLong ya da LongAdder ile düzeltilir. Çok yazılıp az okunan sayaçlarda LongAdder daha az çekişme yaratır.","whyHtml":"Doğru. LongAdder değeri birden fazla hücreye dağıtır, her thread farklı bir hücreyi artırır, sum() bunları toplar. AtomicLong'da tek bir CAS hedefi olduğu için yük altında CAS başarısızlıkları artar."},{"id":"d","ok":true,"html":"price()'ta aynı ürün için birçok thread aynı anda pricingClient.fetch çağırabilir (check-then-act ve cache stampede).","whyHtml":"Doğru. containsKey ile put arasında boşluk var. Popüler bir ürün için ilk anda 50 istek gelirse fiyatlama servisine 50 çağrı gider."},{"id":"e","ok":false,"html":"computeIfAbsent(productId, pricingClient::fetch) her şeyi çözer. Lambda içinde 80 ms'lik HTTP çağrısı yapmak sorun değildir.","whyHtml":"Yanlış. computeIfAbsent atomiktir, ama mapping fonksiyonu çalışırken o key'in bulunduğu bin kilitli kalır. 80 ms boyunca aynı bin'e düşen başka ürünler de bekler. Javadoc, hesaplamanın kısa ve basit olması gerektiğini açıkça söyler."}],"explanationHtml":"

volatile görünürlük verir, atomiklik vermez; ++ üç adımdır. Sayaç için LongAdder kullanırım. Cache'teki containsKey+put check-then-act yaratır ve stampede'e yol açar. computeIfAbsent atomiktir ama içinde I/O yapılmaz, çünkü bin kilitli kalır. Caffeine AsyncLoadingCache ile tek yükleme, TTL ve boyut sınırı alırım, çünkü sınırsız map hem bellek sızıntısı hem bayat fiyat demek.

","links":[{"title":"Java Memory Model Unlearning Experience","url":"https://www.youtube.com/watch?v=TK-7GCCDF_I"},{"title":"Close Encounters of The Java Memory Model Kind","url":"https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/"},{"title":"ConcurrentHashMap Javadoc (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html"}]},{"kind":"mcq","id":"t-q2","category":"Java","label":"Teknik mülakat provası · Java · Core","bodyHtml":"

Sepetteki ürün kayboldu: equals/hashCode tuzağı

CartItem sınıfının equals ve hashCode metotları IDE ile üretilmiş ve hem productId hem quantity alanını kullanıyor.

public class CartItem {\n    private final long productId;\n    private int quantity;\n    // equals() ve hashCode(): productId + quantity\n\n    public void increase() { quantity++; }\n}\n\nSet<CartItem> cart = new HashSet<>();\nCartItem item = new CartItem(42L, 1);\ncart.add(item);\nitem.increase();\n\nSystem.out.println(cart.contains(item)); // (1)\nSystem.out.println(cart.size());         // (2)\ncart.remove(item);\nSystem.out.println(cart.size());         // (3)

(1), (2) ve (3) satırları ne yazdırır?

","multi":false,"options":[{"id":"a","ok":false,"html":"true, 1, 0","whyHtml":"Nesne set'in içinde, ama artık yanlış bucket'ta. HashMap önce hash'e bakar; hash değiştiği için nesneyi bulamaz."},{"id":"b","ok":true,"html":"false, 1, 1","whyHtml":"Doğru. add() sırasında hash, quantity=1'e göre hesaplanıp saklandı. quantity değişince yeni hash başka bir değer oldu. contains ve remove nesneyi bulamaz, set'te \"kayıp\" bir eleman kalır. Bu aynı zamanda bir bellek sızıntısıdır."},{"id":"c","ok":false,"html":"true, 1, 1","whyHtml":"contains da aynı hash aramasını yaptığı için false döner."},{"id":"d","ok":false,"html":"Derleme hatası: final olmayan alan hashCode'da kullanılamaz.","whyHtml":"Java böyle bir derleme kuralı uygulamaz. Hata çalışma anında ve sessizce olur. En tehlikelisi de bu."}],"explanationHtml":"

false, 1, 1. HashSet eklerken hash'i saklar. quantity değişince hash değişir, eleman yanlış bucket'ta kalır ve ne contains ne remove onu bulabilir. Hash tabanlı koleksiyondaki nesnenin hashCode'u değişmemeli. Bu yüzden key'leri immutable yaparım (record) ya da equals/hashCode'u sadece kimlik alanına dayandırırım.

","links":[{"title":"Object.hashCode / equals sözleşmesi (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html"},{"title":"dev.java · Learn","url":"https://dev.java/learn/"},{"title":"High-Performance Hibernate Tutorial (JPA equals/hashCode dahil)","url":"https://vladmihalcea.com/tutorials/hibernate/"}]},{"kind":"open","id":"t-q3","category":"Java","label":"Teknik mülakat provası · Java · Streams","bodyHtml":"

Son 30 günün en çok ciro yapan 3 satıcısı

Bir raporlama ekranı için, bellekteki sipariş listesinden son 30 günde teslim edilmiş (DELIVERED) siparişlerin satıcı bazında cirosunu hesaplayıp en yüksek 3 satıcıyı azalan sırayla döndürmen gerekiyor.

record Order(long sellerId, OrderStatus status, BigDecimal amount, Instant createdAt) {}\nrecord SellerRevenue(long sellerId, BigDecimal revenue) {}\n\nList<SellerRevenue> topSellers(List<Order> orders, Clock clock) {\n    // TODO\n}

Metodun gövdesini yaz. Stream API kullan. Ardından iki cümleyle şunu yaz: Bu hesap production'da 50 milyon sipariş için gerekseydi nerede yapardın?

","answers":{},"modelAnswerHtml":"$c","rubric":["DELIVERED statüsüne göre filtreleme","Son 30 gün filtresi, zamanın Clock'tan alınması","Satıcıya göre gruplama (groupingBy / toMap)","Ciroyu BigDecimal ile toplama (double'a çevirmeden)","Ciroya göre azalan sıralama","İlk 3 ile sınırlama","Büyük veri için hesabı DB'de (GROUP BY) ya da önceden toplanmış (pre-aggregated) bir tabloda yapma"]},{"kind":"mcq","id":"t-q4","category":"Java","label":"Teknik mülakat provası · Java 21 · Virtual Threads","bodyHtml":"

Virtual thread'lere geçiyoruz: hangileri doğru?

Ekip, sipariş servisini Java 21 ve Spring Boot 3.3'e yükseltip virtual thread'leri açmayı tartışıyor. Servis her istekte PostgreSQL'e (Hikari pool: 20) ve iki harici HTTP servisine gidiyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":false,"html":"Virtual thread'ler CPU-yoğun işleri (büyük JSON üretimi, şifreleme) platform thread'lerden daha hızlı yapar.","whyHtml":"Yanlış. Virtual thread'ler hızı değil, eşzamanlılık kapasitesini artırır. CPU-yoğun işte darboğaz CPU çekirdeği sayısıdır."},{"id":"b","ok":true,"html":"Bloklayan I/O (JDBC, HTTP) sırasında virtual thread carrier thread'i bırakır. Bu sayede binlerce eşzamanlı isteği az sayıda OS thread'iyle taşıyabilir.","whyHtml":"Doğru. Bloklama sırasında virtual thread \"unmount\" olur, carrier başka bir virtual thread'i çalıştırır."},{"id":"c","ok":false,"html":"Virtual thread'ler pahalı olduğu için bir thread pool'da havuzlanmalı.","whyHtml":"Yanlış. Virtual thread'ler ucuzdur ve havuzlanmaz; her görev için yenisi açılır. Eşzamanlılığı sınırlamak gerekiyorsa Semaphore kullanılır."},{"id":"d","ok":true,"html":"JDK 21'de synchronized blok içinde bloklayan I/O, virtual thread'i carrier'a \"pin\"leyebilir. JDK 24 (JEP 491) bu durumu büyük ölçüde çözdü.","whyHtml":"Doğru. JDK 21–23'te pinning nedeniyle carrier sayısı kadar eşzamanlılığa düşülebilir. Bu sürümlerde ReentrantLock tercih edilir."},{"id":"e","ok":false,"html":"Virtual thread'e geçince DB connection pool boyutu sorunu kendiliğinden çözülür.","whyHtml":"Yanlış. 10.000 virtual thread yine 20 connection için sıraya girer. Darboğaz thread'den DB'ye kayar; hatta DB'ye daha fazla yük biner."},{"id":"f","ok":true,"html":"Spring Boot 3.2+ ile spring.threads.virtual.enabled=true Tomcat istek işleyicilerini virtual thread'de çalıştırır.","whyHtml":"Doğru. @Async, scheduling ve bazı Kafka/RabbitMQ listener executor'ları da bu ayardan etkilenir."}],"explanationHtml":"

Virtual thread'ler I/O-bound işte eşzamanlılığı ucuzlatır, CPU-bound işi hızlandırmaz. Havuzlanmaz; eşzamanlılık Semaphore ile sınırlanır. DB pool darboğazı yerinde kalır. JDK 21'de synchronized içinde bloklama pinning yaratır, JDK 24 bunu çözdü. Spring Boot 3.2+ ile tek property ile açılır.

","links":[{"title":"Are Virtual Threads Going to Make Reactive Programming Irrelevant?","url":"https://www.youtube.com/watch?v=e9RsTS2sVW0"},{"title":"JEP 444: Virtual Threads","url":"https://openjdk.org/jeps/444"},{"title":"JEP 491: Synchronize Virtual Threads without Pinning","url":"https://openjdk.org/jeps/491"}]},{"kind":"open","id":"t-q5","category":"Spring","label":"Teknik mülakat provası · Spring · @Transactional","bodyHtml":"$d","answers":{},"modelAnswerHtml":"$e","rubric":["Commit sırasında UnexpectedRollbackException fırlar","Exception iç proxy'den geçerken transaction rollback-only olarak işaretlenir","REQUIRED nedeniyle iç metot aynı fiziksel transaction'a katılır","Sonuç: Sipariş de dahil her şey geri alınır, catch işe yaramaz","Düzeltme: noRollbackFor, ya da hatayı exception yerine sonuç tipiyle (önce doğrula) yönetmek","Alternatif: REQUIRES_NEW / NESTED (savepoint) ve maliyetleri"]},{"kind":"mcq","id":"t-q6","category":"Spring","label":"Teknik mülakat provası · Spring Boot · Auto-configuration","bodyHtml":"

Kendi RedisTemplate bean'imi tanımladım, Boot ne yapar?

Projeye spring-boot-starter-data-redis eklendi. Bir @Configuration sınıfında kendi @Bean RedisTemplate<String, Object> redisTemplate(...) metodunu yazdın. Aynı sınıfa bir de kendi @Bean ObjectMapper'ını ekledin.

Hangi ifade doğru?

","multi":false,"options":[{"id":"a","ok":false,"html":"Boot her zaman kendi bean'lerini de oluşturur. İki bean çakışır ve uygulama BeanDefinitionOverrideException ile açılmaz.","whyHtml":"Auto-configuration \"geri çekilmek\" için tasarlanmıştır. Çakışma ancak aynı isimli bean'ler override kapalıyken birbirinin üstüne yazılmaya çalışılırsa olur."},{"id":"b","ok":true,"html":"Auto-configuration sınıfları @ConditionalOnMissingBean gibi koşullarla korunur. Senin bean'in olduğu için Boot geri çekilir ve seninkini kullanır. Ama kendi ObjectMapper'ını tanımlamak Boot'un Jackson ayarlarını (ör. spring.jackson.*) devre dışı bırakır.","whyHtml":"Doğru. Kullanıcı konfigürasyonu önce işlenir, auto-config'ler sonra ve koşullu olarak değerlendirilir. ObjectMapper'ı özelleştirmenin doğru yolu Jackson2ObjectMapperBuilderCustomizer bean'idir."},{"id":"c","ok":false,"html":"Auto-config sınıfları, org.springframework.boot paketlerinin component scan ile taranmasıyla bulunur.","whyHtml":"Yanlış. Aday sınıflar META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports dosyasından okunur. Component scan ile ilgisi yoktur."},{"id":"d","ok":false,"html":"Senin @Bean'lerin auto-config'lerden sonra işlenir ve onların bean tanımlarının üzerine yazar.","whyHtml":"Sıralama tam tersi. Auto-config'ler kullanıcı tanımlarından sonra değerlendirilir; koşullar böylece \"kullanıcı zaten tanımladı mı?\" sorusunu cevaplayabilir."}],"explanationHtml":"

Boot auto-config'leri imports dosyasından ve kullanıcı tanımlarından sonra yükler. @ConditionalOnMissingBean sayesinde benim RedisTemplate'im varsa geri çekilir. Kendi ObjectMapper'ımı tanımlarsam Boot'un Jackson ayarlarını kaybederim; bu yüzden customizer kullanırım. Neyin neden yüklendiğini --debug raporu veya /actuator/conditions ile görürüm.

","links":[{"title":"Demystifying Spring Boot Magic","url":"https://www.youtube.com/watch?v=yOdfWyIHmRg"},{"title":"Creating Your Own Auto-configuration","url":"https://docs.spring.io/spring-boot/reference/features/developing-auto-configuration.html"}]},{"kind":"mcq","id":"t-q7","category":"Spring","label":"Teknik mülakat provası · Spring · Bean scope","bodyHtml":"

Kullanıcılar birbirinin indirimini görüyor

Kampanya döneminde bazı müşteriler sepette başka bir müşterinin indirim tutarını gördüğünü bildiriyor. Sorun düşük trafikte hiç tekrarlanmıyor.

@Component\npublic class PriceCalculator {\n\n    private BigDecimal discount = BigDecimal.ZERO;\n\n    public BigDecimal calculate(Cart cart, Campaign campaign) {\n        this.discount = campaign.discountFor(cart);\n        BigDecimal total = cart.total();\n        return total.subtract(discount);\n    }\n}

Kök neden nedir?

","multi":false,"options":[{"id":"a","ok":false,"html":"Spring her istek için yeni bir PriceCalculator oluşturur. Sorun JIT optimizasyonundan kaynaklanıyor.","whyHtml":"Varsayılan scope singleton'dır; her istekte yeni nesne oluşturulmaz."},{"id":"b","ok":true,"html":"Bean singleton. discount alanı tüm istek thread'leri arasında paylaşılır ve araya giren bir thread başka müşterinin değerini yazar. Çözüm: alanı kaldırıp local değişken kullanmak (stateless bean).","whyHtml":"Doğru. Spring servisleri stateless olmalıdır. İstek bazlı veri parametre ve local değişkenlerde taşınır."},{"id":"c","ok":false,"html":"BigDecimal mutable olduğu için subtract paylaşılan değeri değiştiriyor.","whyHtml":"BigDecimal immutable'dır. subtract yeni bir nesne döner."},{"id":"d","ok":false,"html":"@Component yerine @Service kullanılmalıydı; @Service thread-safe'tir.","whyHtml":"@Service sadece semantik bir stereotype'tır. Scope'u ve thread-safety'yi değiştirmez."}],"explanationHtml":"

Bean singleton, discount alanı tüm thread'lerce paylaşılıyor ve yük altında başka kullanıcının değeri okunuyor. Servisleri stateless tutarım: istek verisi local değişkende, alanlar sadece final bağımlılıklar. Prototype'ı singleton'a enjekte etmek de benzer bir tuzaktır; orada ObjectProvider kullanırım.

","links":[{"title":"Bean Scopes","url":"https://docs.spring.io/spring-framework/reference/core/beans/factory-scopes.html"}]},{"kind":"open","id":"t-q8","category":"Veri","label":"Teknik mülakat provası · JPA · Hibernate","bodyHtml":"

Tek satırlık repository metodunda kaç problem var?

items ve payments alanları Order entity'sinde iki ayrı @OneToMany List. Bazı satıcıların 2 milyon siparişi var. Satıcı paneli 20'şerli sayfalarla bu metodu çağırıyor.

public interface OrderRepository extends JpaRepository<Order, UUID> {\n\n    @EntityGraph(attributePaths = {\"items\", \"payments\"})\n    Page<Order> findBySellerId(long sellerId, Pageable pageable);\n}

Gördüğün her problemi ve çözümünü yaz. En az 3 problem var.

","answers":{},"modelAnswerHtml":"$f","rubric":["İki List (bag) birlikte fetch edilince MultipleBagFetchException ya da kartezyen çarpım oluşur","Collection fetch + pagination: Hibernate LIMIT'i SQL'e koymaz, sayfalamayı bellekte yapar (HHH90003004)","Page dönüşü her istekte büyük tabloda ek bir count(*) sorgusu çalıştırır; Slice veya Window kullanılmalı","Çözüm: İki adımlı sorgu (önce sayfa id'leri, sonra fetch) veya batch fetching","Derin sayfalar için OFFSET yerine keyset pagination","Önlem: fail_on_pagination_over_collection_fetch ayarı veya DTO projection"]},{"kind":"mcq","id":"t-q9","category":"Veri","label":"Teknik mülakat provası · PostgreSQL · Index","bodyHtml":"

\"Siparişlerim\" sayfası için en iyi index hangisi?

Müşteri uygulamasının \"Siparişlerim\" ekranı aşağıdaki sorguyu saniyede binlerce kez çalıştırıyor. orders tablosunda 800 milyon satır var. Teslim edilmiş ve iade edilmiş siparişler tüm siparişlerin yaklaşık %85'ini oluşturuyor.

SELECT id, total, created_at\n  FROM orders\n WHERE buyer_id = $1\n   AND created_at >= now() - interval '90 days'\n   AND status IN ('DELIVERED', 'RETURNED')\n ORDER BY created_at DESC\n LIMIT 20;

Bu sorgu için en uygun index hangisi?

","multi":false,"options":[{"id":"a","ok":false,"html":"(created_at DESC, buyer_id, status)","whyHtml":"Range kolonu başta. Son 90 günün tüm alıcılarının siparişleri taranır ve buyer_id filtresi sonradan uygulanır. ESR kuralını ihlal ediyor."},{"id":"b","ok":true,"html":"(buyer_id, created_at DESC) INCLUDE (status, total, id)","whyHtml":"Doğru. Alıcının satırları zaten created_at sırasında gelir; Sort gerekmez. status filtresi index içinden uygulanır ve 20 eşleşmede tarama durur. INCLUDE kolonları sayesinde Index Only Scan mümkün olur; id de dahil, çünkü PostgreSQL'de ikincil index'ler PK'yı otomatik taşımaz."},{"id":"c","ok":false,"html":"(buyer_id, status, created_at DESC)","whyHtml":"Makul ama ikinci en iyi. IN iki değer içerdiği için satırlar created_at sırasında tek parça halinde gelmez; planner iki aralığı okuyup Sort yapmak zorunda kalabilir. status çok seçici olsaydı (satırların %1'i) bu index öne geçerdi. Burada %85."},{"id":"d","ok":false,"html":"Üç ayrı tek kolonlu index: (buyer_id), (created_at), (status)","whyHtml":"Planner bunları BitmapAnd ile birleştirebilir ama sıralama kaybolur, heap'e gidilir, Sort ve LIMIT pahalı olur. Yazma maliyeti de üç kattır."}],"explanationHtml":"

Eşitlik kolonu buyer_id başa, sıralama ve aralık kolonu created_at DESC hemen arkasına gelir; böylece Sort olmadan sıralı okur ve LIMIT'te dururum. status IN iki değerli ve %85'lik olduğu için onu sıralamadan önce koymam, INCLUDE ile yaprakta filtrelerim; total ve id'yi de ekleyip Index Only Scan alırım. 800M satırda CONCURRENTLY ile oluşturup EXPLAIN ANALYZE ile doğrularım.

","links":[{"title":"The right column order in multi-column indexes","url":"https://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys"},{"title":"Index-Only Scans and Covering Indexes","url":"https://www.postgresql.org/docs/current/indexes-index-only-scans.html"},{"title":"Using EXPLAIN","url":"https://www.postgresql.org/docs/current/using-explain.html"}]},{"kind":"mcq","id":"t-q10","category":"Veri","label":"Teknik mülakat provası · PostgreSQL · Isolation & Locking","bodyHtml":"

Puanlar kayboluyor: lost update

Sadakat programında aynı kullanıcıya iki farklı olaydan aynı anda 10'ar puan ekleniyor. Başlangıç bakiyesi 100. Bazen sonuç 120 yerine 110 çıkıyor. PostgreSQL varsayılan izolasyon seviyesinde (READ COMMITTED) çalışıyor.

@Transactional\npublic void addPoints(long userId, int points) {\n    Wallet wallet = walletRepository.findById(userId).orElseThrow(); // SELECT\n    wallet.setPoints(wallet.getPoints() + points);                   // hesap Java'da\n}                                                                    // commit: UPDATE

Aşağıdakilerden hangileri lost update'i engeller?

","multi":true,"options":[{"id":"a","ok":false,"html":"READ COMMITTED'da kalmak yeterli, PostgreSQL okunan satırı zaten kilitler.","whyHtml":"Yanlış. Düz SELECT kilit almaz (MVCC'de okuma yazmayı bloklamaz). İki transaction da 100 okur ve ikisi de 110 yazar."},{"id":"b","ok":true,"html":"@Lock(PESSIMISTIC_WRITE) ile SELECT ... FOR UPDATE","whyHtml":"Doğru. İkinci transaction ilki bitene kadar bekler, sonra güncel değeri (110) okur."},{"id":"c","ok":true,"html":"Atomik UPDATE wallet SET points = points + :p WHERE user_id = :id","whyHtml":"Doğru ve en ucuzu. Hesap DB'de yapılır; satır kilidi sadece ifade süresince tutulur."},{"id":"d","ok":true,"html":"@Version ile optimistic locking + retry","whyHtml":"Doğru. İkinci commit \"WHERE version = 5\" koşulunu karşılamaz, OptimisticLockException alınır, yeniden okunup tekrar denenir. Düşük çekişmede ideal."},{"id":"e","ok":true,"html":"REPEATABLE READ: PostgreSQL ikinci transaction'ı could not serialize access due to concurrent update hatasıyla düşürür. Uygulama retry etmeli.","whyHtml":"Doğru. PostgreSQL'in snapshot isolation'ı lost update'i hata vererek engeller. Retry mantığı şarttır."},{"id":"f","ok":false,"html":"@Transactional(readOnly = true)","whyHtml":"Yanlış. Bu bir optimizasyon ipucudur (flush'ı kapatır, read replica'ya yönlendirmede kullanılabilir). Yazma bile yapmamalıdır."}],"explanationHtml":"

READ COMMITTED'da düz SELECT kilit almaz, iki transaction da 100 okur ve lost update olur. En iyisi hesabı atomik UPDATE ile DB'ye vermek. Olmuyorsa çekişme düşükse @Version + retry, yüksekse FOR UPDATE kullanırım. REPEATABLE READ'de PostgreSQL serialization hatası verir; o zaman retry gerekir.

","links":[{"title":"Transactions: myths, surprises and opportunities","url":"https://www.youtube.com/watch?v=5ZjhNTM8XU8"},{"title":"Transaction Isolation","url":"https://www.postgresql.org/docs/current/transaction-iso.html"}]},{"kind":"mcq","id":"t-q11","category":"Veri","label":"Teknik mülakat provası · Couchbase · Elasticsearch","bodyHtml":"

Ürün verisi Couchbase'de, arama Elasticsearch'te

Ürün detay verisi Couchbase'de tutuluyor. Arama ve filtreleme Elasticsearch üzerinden yapılıyor. İki sistem bir DCP connector'ı ile senkron tutuluyor (Couchbase'deki değişiklik akışı Elasticsearch'e yazılıyor).

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Couchbase'de dokümana key ile erişim (KV get) memory-first olduğu için SQL++ (N1QL) sorgusundan çok daha hızlıdır. Sık okunan veri key tasarımıyla KV'den okunmalı.","whyHtml":"Doğru. KV erişim, key'in hash'iyle doğrudan doğru node'a ve vBucket'a gider. Sorgu servisi ise index ve query planner katmanından geçer."},{"id":"b","ok":false,"html":"Elasticsearch yazılan dokümanı anında aranabilir yapar; index isteği döndüğü an search sonucunda kesin görünür.","whyHtml":"Yanlış. Elasticsearch near real-time'dır. Varsayılan refresh_interval 1 saniyedir; o süre dolmadan doküman aramada görünmeyebilir. GET by id ise hemen görür."},{"id":"c","ok":true,"html":"Bir index'in primary shard sayısı sonradan doğrudan değiştirilemez (reindex, split veya shrink gerekir). Replica sayısı ise anında değiştirilebilir.","whyHtml":"Doğru. Routing formülü shard sayısına bağlıdır. Bu yüzden shard planlaması önceden yapılır, değişiklik için alias + reindex kullanılır."},{"id":"d","ok":true,"html":"\"IŞIK\" araması \"ışık\" ile eşleşsin diye Türkçe'ye uygun bir lowercase/analyzer seçilmeli. Standart lowercase, Türkçe İ/ı dönüşümünü yanlış yapabilir.","whyHtml":"Doğru. Dile özgü olmayan lowercase \"I\"yı \"i\"ye çevirir, Türkçede ise \"ı\" olmalı. Türkçe için language: turkish lowercase filtresi kullanılır."},{"id":"e","ok":false,"html":"Elasticsearch birincil veritabanı olarak kullanılmalı, Couchbase'e gerek yoktur.","whyHtml":"Yanlış. ES bir arama motorudur: transaction yok, mapping değişikliği reindex gerektirir, yazma yükü altında maliyetlidir. Birincil kaynak ayrı tutulur, ES türetilmiş bir read model'dir."},{"id":"f","ok":true,"html":"Custom routing (ör. sellerId) ile bir satıcının dokümanları tek shard'a gider; satıcı bazlı sorgular tüm shard'lara dağılmaz.","whyHtml":"Doğru. Sorgu sadece ilgili shard'a gider. Bedeli hot shard riskidir (dev satıcılar), ayrıca routing değeri değişirse dokümanın taşınması gerekir."}],"explanationHtml":"

Couchbase'i birincil kaynak olarak kullanırım; sık erişimi key tasarımıyla KV'den yaparım, SQL++ esnek ama daha yavaştır. Elasticsearch türetilmiş bir arama modelidir: near real-time'dır, shard sayısı sonradan değişmez, Türkçe için doğru analyzer şarttır. Satıcı bazlı sorgularda custom routing kullanır, hot shard riskini izlerim. İkisi DCP ile eventually consistent.

","links":[{"title":"Elasticsearch Tutorial","url":"https://www.youtube.com/watch?v=1EnvkPf7t6Y"}]},{"kind":"mcq","id":"t-q12","category":"Dağıtık Sistemler","label":"Teknik mülakat provası · Kafka · Temeller","bodyHtml":"

6 partition, 4 pod, concurrency=3

order-events topic'inin 6 partition'ı var, replication factor 3. Kargo servisi Kubernetes'te 4 pod çalışıyor; hepsi aynı groupId'yi kullanıyor ve listener'da concurrency = \"3\" var. Producer'lar key olarak orderId gönderiyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Toplam 12 consumer thread var, ama aynı anda sadece 6'sı mesaj işler.","whyHtml":"Doğru. Bir partition grup içinde aynı anda tek consumer'a atanır. 6 thread partition alamaz, boşta bekler."},{"id":"b","ok":true,"html":"Key = orderId olduğu için aynı siparişin event'leri aynı partition'a gider ve o partition içinde sırayla işlenir.","whyHtml":"Doğru. Partition = hash(key) % 6. Sıra garantisi sadece partition içindedir."},{"id":"c","ok":false,"html":"Partition sayısını 6'dan 12'ye çıkarmak, mevcut key'lerin partition eşleşmesini değiştirmez.","whyHtml":"Yanlış. Formül hash(key) % N olduğu için N değişince key'lerin çoğu başka partition'a gider. Geçiş anında aynı siparişin eski ve yeni event'leri farklı partition'larda olabilir. Partition sayısı azaltılamaz da."},{"id":"d","ok":true,"html":"acks=all + min.insync.replicas=2 + replication factor 3 ile tek bir broker kaybında onaylanmış mesaj kaybolmaz.","whyHtml":"Doğru. Onay en az 2 replikaya yazılınca gelir; biri ölse bile diğeri leader olur."},{"id":"e","ok":false,"html":"Kafka'nın exactly-once desteği, consumer'ın PostgreSQL'e yazdığı veride de duplicate olmayacağını garanti eder.","whyHtml":"Yanlış. EOS sadece Kafka'dan okuyup Kafka'ya yazan akışlarda (transactions) geçerlidir. Dış sisteme yazarken idempotent consumer gerekir."},{"id":"f","ok":true,"html":"max.poll.interval.ms aşılırsa consumer gruptan atılır ve rebalance tetiklenir.","whyHtml":"Doğru. Heartbeat ayrı bir thread'de gitse bile, poll() çağrıları arası bu süreyi aşarsa coordinator consumer'ı takılmış sayar."}],"explanationHtml":"

Paralellik partition sayısıyla sınırlıdır: 12 thread'in 6'sı boşta kalır. Key=orderId ile sipariş bazında sıra korunur, ama partition artırınca eşleşme değişir. acks=all, min ISR 2 ve RF 3 ile onaylı mesaj kaybolmaz. EOS dış DB'yi kapsamaz; at-least-once + idempotent consumer kullanırım. max.poll.interval aşılırsa rebalance olur.

","links":[{"title":"Consumers and Consumer Group Protocol","url":"https://www.youtube.com/watch?v=ovdSOIXSyzI"},{"title":"Apache Kafka's Next-Gen Rebalance Protocol","url":"https://www.youtube.com/watch?v=yVXtWzAbcmY"},{"title":"Consumer Group Protocol (Kafka Internal Architecture kursu)","url":"https://developer.confluent.io/courses/architecture/consumer-group-protocol/"}]},{"kind":"open","id":"t-q13","category":"Dağıtık Sistemler","label":"Teknik mülakat provası · Kafka · Error handling","bodyHtml":"

Fatura consumer'ında kaç problem var?

Sipariş oluşunca e-fatura kesen consumer aşağıda. order-created topic'inin 6 partition'ı var. E-fatura sağlayıcısı kampanya günlerinde 20–40 saniye cevap vermiyor.

@KafkaListener(topics = \"order-created\", groupId = \"invoice-service\", concurrency = \"12\")\npublic void onOrderCreated(String payload) {\n    try {\n        OrderCreated event = objectMapper.readValue(payload, OrderCreated.class);\n        Invoice invoice = invoiceClient.create(event);   // harici e-fatura API, timeout ayarı yok\n        invoiceRepository.save(invoice);\n    } catch (Exception e) {\n        log.error(\"Fatura oluşturulamadı\", e);\n    }\n}

En az 4 problem bul ve her biri için çözüm yaz.

","answers":{},"modelAnswerHtml":"$10","rubric":["Exception yutuluyor: offset commit edilir, mesaj sessizce kaybolur (retry ve DLT yok)","HTTP çağrısında timeout yok: thread bloklanır, max.poll.interval aşılır, rebalance ve duplicate oluşur","Idempotent değil: retry veya rebalance'ta ikinci fatura kesilir; idempotency key veya unique constraint gerekir","concurrency 12 > 6 partition: 6 thread boşta","Harici API + DB kaydı atomik değil: fatura kesilip kayıt fail olursa tutarsızlık (önce PENDING kaydı / outbox ters yönü)","Parse hatası (poison pill) retry edilmeden doğrudan DLT'ye gitmeli; circuit breaker ile dayanıklılık"]},{"kind":"open","id":"t-q14","category":"Dağıtık Sistemler","label":"Teknik mülakat provası · Saga · Outbox","bodyHtml":"

Ödeme alındı, stok yok: dağıtık transaction

Sipariş akışı dört ayrı servisten oluşuyor: Order → Payment → Inventory → Shipment. Her servisin kendi veritabanı var, iletişim Kafka üzerinden. Bir siparişte ödeme başarıyla alındı ama Inventory servisi stok ayıramadı.

Şu soruları cevapla:

Burada neden 2PC (two-phase commit) kullanmayız?
Saga'yı choreography ile mi orchestration ile mi kurarsın? Neden?
Bu senaryodaki telafi (compensation) adımları neler, hangi özelliklere sahip olmalılar?
Event'lerin güvenilir yayınlanması ve tekrarlara dayanıklılık için hangi pattern'leri kullanırsın?

","answers":{},"modelAnswerHtml":"$11","rubric":["2PC: bloklayan protokol, coordinator tek hata noktası, availability düşer, Kafka ve NoSQL ile pratik değil","Saga: her adım lokal transaction + event, hata olursa telafi transaction'ları","Choreography ve orchestration trade-off'u (coupling, görünürlük, merkezi kontrol)","Telafi: ödeme iadesi ve siparişin iptali. Telafiler idempotent ve retry edilebilir olmalı, geri alma değil semantik ters işlemdir.","Outbox ile güvenilir yayın + idempotent consumer","Ara durumlar ve state machine (PENDING), zaman aşımı yönetimi"]},{"kind":"mcq","id":"t-q15","category":"Dağıtık Sistemler","label":"Teknik mülakat provası · Resilience · Timeout/Retry/CB","bodyHtml":"

Kargo API'si yavaşladı: dayanıklılık kuralları

Checkout servisi kargo ücretini harici bir API'den alıyor. Kampanya gününde API bazen 30 saniyeye kadar yavaşlıyor, bazen 503 dönüyor. Ekip Resilience4j ile timeout, retry ve circuit breaker ekleyecek.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Retry'lar exponential backoff + jitter ile yapılmalı. Aksi halde tüm client'lar aynı anda tekrar dener (thundering herd).","whyHtml":"Doğru. Jitter, denemeleri zamana yayarak toparlanmakta olan servisi ikinci kez ezmeyi önler."},{"id":"b","ok":true,"html":"3 katmanlı bir çağrı zincirinde her katman 3 kez retry ederse en alttaki servis tek bir kullanıcı isteği için 27 çağrı alabilir.","whyHtml":"Doğru. Retry'lar katmanlarda çarpılır. Retry genelde tek bir katmanda (en üstte veya en altta) yapılır ve retry budget ile sınırlanır."},{"id":"c","ok":false,"html":"Circuit breaker OPEN durumdayken istekler downstream'e gönderilir ama sonuçları göz ardı edilir.","whyHtml":"Yanlış. OPEN'da istekler hiç gönderilmez; anında hata (fail fast) ya da fallback dönülür. Amaç downstream'e nefes aldırmak."},{"id":"d","ok":true,"html":"HALF_OPEN durumunda sınırlı sayıda deneme isteğine izin verilir; başarılı olursa CLOSED'a, olmazsa tekrar OPEN'a döner.","whyHtml":"Doğru. Resilience4j'de bu sayı permittedNumberOfCallsInHalfOpenState ile ayarlanır."},{"id":"e","ok":false,"html":"POST /payments gibi idempotent olmayan çağrılar idempotency key olmadan güvenle retry edilebilir.","whyHtml":"Yanlış. Timeout aldığın istek sunucuda başarılı olmuş olabilir; retry çift çekim yapar. Idempotency key şart."},{"id":"f","ok":true,"html":"Bulkhead, tek bir bağımlılığın yavaşlamasının tüm thread'leri tüketmesini engellemek için o bağımlılığa giden eşzamanlı çağrı sayısını sınırlar.","whyHtml":"Doğru. Kargo API'si yavaşladığında sadece ona ayrılan kapasite dolar; ödeme ve stok çağrıları etkilenmez."},{"id":"g","ok":false,"html":"Timeout'u downstream'in p99 gecikmesine göre değil, mümkün olan en uzun süreye (ör. 60 sn) ayarlamak en güvenlisidir.","whyHtml":"Yanlış. Uzun timeout thread ve connection'ları tutar ve cascading failure yaratır. Timeout, downstream'in p99/p99.9'u ve çağıranın kendi SLA'sı dikkate alınarak belirlenir."}],"explanationHtml":"

Her çağrıya p99'a dayalı bir timeout koyarım. Retry'ı sadece geçici hatalarda, 2–3 deneme, backoff ve jitter ile, tek katmanda yaparım. Circuit breaker hata ve yavaş çağrı oranına göre açılır; OPEN'da istek göndermez, HALF_OPEN'da az sayıda deneme yapar. Bulkhead ile kargo API'sinin yavaşlığını izole ederim. Idempotent olmayan çağrıları idempotency key olmadan asla retry etmem.

","links":[{"title":"Timeouts, retries, and backoff with jitter","url":"https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/"},{"title":"Exponential Backoff And Jitter","url":"https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/"},{"title":"Resilience4j CircuitBreaker","url":"https://resilience4j.readme.io/docs/circuitbreaker"},{"title":"How to do distributed locking","url":"https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html"}]},{"kind":"open","id":"t-q16","category":"Operasyon","label":"Teknik mülakat provası · Kubernetes · JVM","bodyHtml":"

Pod sürekli restart oluyor: manifest incelemesi

Yeni deploy edilen sipariş servisi bazen OOMKilled, bazen CrashLoopBackOff durumuna düşüyor. Veritabanı 20 saniyelik bir bakım yaptığında da tüm pod'lar aynı anda restart oluyor. Spring Boot servisinin manifest'inin ilgili kısmı:

containers:\n  - name: order-service\n    image: registry.local/order-service:1.4.2\n    env:\n      - name: JAVA_TOOL_OPTIONS\n        value: \"-Xmx1024m\"\n    resources:\n      requests: { cpu: \"250m\", memory: \"1Gi\" }\n      limits:   { cpu: \"250m\", memory: \"1Gi\" }\n    livenessProbe:\n      httpGet: { path: /actuator/health, port: 8080 }\n      initialDelaySeconds: 10\n      periodSeconds: 5\n      failureThreshold: 2

En az 4 problem bul ve düzeltmesini yaz.

","answers":{},"modelAnswerHtml":"$12","rubric":["-Xmx limitle aynı: heap + metaspace + thread stack + direct buffer limiti aşar, OOMKilled olur; MaxRAMPercentage kullanılmalı","Liveness /actuator/health'e bakıyor (DB dahil): DB kesintisinde tüm pod'lar restart olur (cascading failure). /health/liveness kullanılmalı","Readiness probe yok: hazır olmayan veya kapanan pod'a trafik gider","Startup yavaşken liveness erken öldürüyor (10 sn + 2×5 sn); startupProbe gerekli","CPU limiti 250m: throttling, yavaş açılış, JVM'in 1 CPU görüp SerialGC seçmesi","Graceful shutdown ve preStop eksik"]},{"kind":"mcq","id":"t-q17","category":"Operasyon","label":"Teknik mülakat provası · Observability · CI/CD · Terraform","bodyHtml":"

Gözlemlenebilirlik ve teslimat hattı

Yeni ekibinde servisler Prometheus + Grafana ile izleniyor, tracing için OpenTelemetry kullanılıyor, altyapı Terraform ile yönetiliyor ve ekip trunk-based development uyguluyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"RED metodu servisler için Rate, Errors, Duration ölçer; USE metodu kaynaklar için Utilization, Saturation, Errors ölçer.","whyHtml":"Doğru. RED istek odaklıdır (Tom Wilkie), USE kaynak odaklıdır (Brendan Gregg)."},{"id":"b","ok":false,"html":"Latency'yi ortalama ile izlemek yeterlidir; p95 ve p99 gereksizdir.","whyHtml":"Yanlış. Ortalama kuyruğu gizler. Kullanıcıların %1'inin 5 sn beklemesi ortalamada görünmez. Histogram ve percentile kullanılır."},{"id":"c","ok":true,"html":"Aylık %99.9 availability SLO'su yaklaşık 43 dakikalık error budget demektir.","whyHtml":"Doğru. 30 gün × 24 sa × 60 dk = 43.200 dk; %0.1'i ≈ 43,2 dk. Budget biterse yeni feature yerine güvenilirliğe odaklanılır."},{"id":"d","ok":true,"html":"Distributed tracing'de trace ID servisler arasında header ile (W3C traceparent) taşınır ve log'lara da yazılarak log-trace korelasyonu sağlanır.","whyHtml":"Doğru. Kafka mesajlarında da header olarak taşınır. Micrometer Tracing / OpenTelemetry bunu otomatik yapar."},{"id":"e","ok":true,"html":"terraform plan state, konfigürasyon ve gerçek altyapıyı karşılaştırıp yapılacak değişiklikleri gösterir. State dosyası ekip için kilitli bir remote backend'de tutulur.","whyHtml":"Doğru. Remote state + locking eşzamanlı apply'ları önler. State içinde hassas veri olabilir, erişimi kısıtlanır."},{"id":"f","ok":false,"html":"Trunk-based development'ta uzun ömürlü feature branch'ler tercih edilir; tamamlanmamış iş main'e asla girmez.","whyHtml":"Yanlış. Kısa ömürlü branch'ler (≤1–2 gün) ve sık merge esastır. Tamamlanmamış iş feature flag arkasında main'e girer."},{"id":"g","ok":true,"html":"Bir Prometheus metriğine label olarak userId eklemek yüksek kardinalite yüzünden zaman serisi sayısını patlatır.","whyHtml":"Doğru. Her benzersiz label kombinasyonu ayrı bir seri demektir. userId ve orderId log veya trace'e konur, metriğe konmaz."}],"explanationHtml":"

Servisleri RED, altyapıyı USE ile izlerim; latency'yi percentile ile ölçerim. SLO ve error budget ile alarmı kullanıcı semptomuna bağlarım. Trace ID'yi HTTP ve Kafka header'larında taşıyıp log'a yazarım. Yüksek kardinaliteli label'ları metriğe koymam. Terraform'da plan'ı PR'da incelerim, state remote ve kilitli olur. Trunk-based'de kısa branch'ler ve feature flag kullanırım.

","links":[{"title":"Continuous Integration vs Feature Branch Workflow","url":"https://www.youtube.com/watch?v=pXovk-5J0Lg"},{"title":"We Tried Trunk-Based Development... The Results Were Shocking","url":"https://www.youtube.com/watch?v=CR3LP2n2dWw"},{"title":"Service Level Objectives","url":"https://sre.google/sre-book/service-level-objectives/"},{"title":"Terraform: Get Started (AWS)","url":"https://developer.hashicorp.com/terraform/tutorials/aws-get-started"}]},{"kind":"open","id":"t-q18","category":"Zanaat","label":"Teknik mülakat provası · Test · Mockito · Testcontainers","bodyHtml":"

Stok yetersizken ne sipariş ne event yazılmalı

Projedeki OrderService.placeOrder metodu sırasıyla stockReservationService.reserve(...), orderRepository.save(...) ve outboxEventRepository.save(...) çağırıyor. reserve metodu void döner ve stok yetmezse InsufficientStockException fırlatır. Constructor: (StockReservationService, OrderRepository, OutboxEventRepository, ObjectMapper, Clock).

1) JUnit 5 + Mockito ile bir unit test yaz: stok yetersizse exception fırlamalı ve ne sipariş ne outbox kaydı yapılmalı.

2) Bu sınıfın hangi davranışını unit test yerine Testcontainers ile entegrasyon testi olarak yazarsın? Neden?

","answers":{},"modelAnswerHtml":"$13","rubric":["Mockito kurulumu (@ExtendWith(MockitoExtension.class), @Mock)","void metot için doThrow(...).when(mock).reserve(...)","Exception'ı assertThrows / assertThatThrownBy ile doğrulama","Repository'lerle hiç etkileşim olmadığını doğrulama (verify never / verifyNoInteractions)","Entegrasyon testi gerekçesi: transaction rollback, atomik UPDATE, eşzamanlılık ve SQL'i mock'lar doğrulayamaz","Clock.fixed ile deterministik zaman"]},{"kind":"open","id":"t-q19","category":"Zanaat","label":"Teknik mülakat provası · SOLID · Design Patterns","bodyHtml":"

Her yeni kargo firmasında bu metoda dokunuyoruz

Her yeni kargo firması eklendiğinde bu metot değişiyor, TEX mantığı her sprint büyüyor ve PR'larda sürekli çakışma çıkıyor.

public BigDecimal shippingFee(Order order) {\n    switch (order.carrier()) {\n        case \"ARAS\":\n            return order.weightKg() > 5 ? new BigDecimal(\"89.90\") : new BigDecimal(\"49.90\");\n        case \"YURTICI\":\n            return order.total().compareTo(new BigDecimal(\"500\")) >= 0\n                    ? BigDecimal.ZERO : new BigDecimal(\"54.90\");\n        case \"TEX\":\n            return calculateTexFee(order);\n        default:\n            throw new IllegalArgumentException(\"Unknown carrier \" + order.carrier());\n    }\n}

Hangi SOLID ilkesi ihlal ediliyor? Hangi pattern ile ve Spring'de nasıl refactor edersin? Kısa bir kod iskeleti yaz (interface, bir implementasyon, seçici sınıf).

","answers":{},"modelAnswerHtml":"$14","rubric":["Open/Closed Principle ihlali (yeni davranış için mevcut kodu değiştirmek); SRP de zayıf","Strategy pattern","Ortak bir interface (feeFor/carrier metotlarıyla)","Spring'in List enjeksiyonu ile Map'e dönüştürüp seçmek","Magic value'ları (ücret, eşik, carrier string'i) enum/config'e taşımak","Her strategy'nin bağımsız unit test edilebilmesi; bilinmeyen carrier'ın ele alınması"]},{"kind":"open","id":"t-q20","category":"Zanaat","label":"Teknik mülakat provası · System Design · English","bodyHtml":"

Design a flash sale checkout (answer in English)

İlanda iyi İngilizce şartı var, bu yüzden bu soruyu İngilizce cevapla.

\"At 20:00 we start a flash sale: 50,000 units of a single phone at a big discount, maximum one per customer. We expect around 2 million users to open the app within the first minute. Design the stock reservation and checkout flow.\"

Cover: clarifying questions and rough numbers, how you protect the system from the spike, how you guarantee no overselling and one-per-customer, what happens between reservation and payment, how orders reach the database reliably, and what can fail.

","answers":{},"modelAnswerHtml":"$15","rubric":["Clarifying requirements and back-of-the-envelope numbers (QPS, read vs write)","Protect the core: CDN/static content, rate limiting, waiting room / queue, pre-scaling","Atomic stock decrement (Redis Lua / DECR or DB conditional update) to prevent overselling","One per customer: idempotency / unique constraint (SETNX, unique(user, campaign))","Reservation with TTL; release stock if payment doesn't complete","Async, reliable persistence: Kafka/outbox, eventual consistency, reconciliation","Failure modes and observability: Redis failover, hot key, monitoring/alerting, load test"]},{"kind":"mcq","id":"j-j1","category":"Java","label":"Java & Spring temelleri · OOP · Polymorphism","bodyHtml":"

Overloading, overriding ve static: ekrana ne yazar?

Ödeme modülünde bir alt sınıf, üst sınıfın bazı metotlarını eziyor. Kod derleniyor ve çalışıyor.

class Payment {\n    void pay(Object o)  { System.out.print(\"P-Object \"); }\n    void pay(String s)  { System.out.print(\"P-String \"); }\n    static String type() { return \"Payment\"; }\n}\n\nclass CardPayment extends Payment {\n    @Override\n    void pay(Object o)  { System.out.print(\"C-Object \"); }\n    static String type() { return \"Card\"; }\n}\n\nPayment p = new CardPayment();\nObject arg = \"TR123\";\np.pay(arg);\np.pay(\"TR123\");\nSystem.out.println(p.type());

Çıktı nedir?

","multi":false,"options":[{"id":"a","ok":false,"html":"C-Object C-Object Card","whyHtml":"pay(\"TR123\") için derleyici daha spesifik olan pay(String)'i seçer. Alt sınıf onu ezmediği için Payment'taki çalışır. type() ise static'tir; override edilmez."},{"id":"b","ok":false,"html":"P-String P-String Payment","whyHtml":"Overload seçimi, değişkenin çalışma anındaki tipine (String) değil derleme anındaki tipine (Object) göre yapılır. arg'ın derleme tipi Object olduğu için pay(Object) seçilir."},{"id":"c","ok":true,"html":"C-Object P-String Payment","whyHtml":"Doğru. 1) Overload derleme anında seçilir: arg'ın tipi Object, yani pay(Object). Override çalışma anında seçilir: nesne CardPayment, C-Object. 2) \"TR123\" literal'i için en spesifik overload pay(String); ezilmediği için P-String. 3) Static metotlar referansın derleme tipine göre çağrılır (method hiding): Payment."},{"id":"d","ok":false,"html":"C-Object P-String Card","whyHtml":"Static metotlar polimorfik değildir. p'nin derleme tipi Payment olduğu için Payment.type() çağrılır. IDE \"static method should be accessed via class\" uyarısı verir."}],"explanationHtml":"

Overload derleme anında, argümanın derleme tipine göre seçilir; override çalışma anında, nesnenin gerçek tipine göre. arg Object olduğu için pay(Object) seçilir ve CardPayment'ınki çalışır: C-Object. Literal String için pay(String) seçilir, ezilmediği için P-String. Static metotlar override edilmez, gizlenir; derleme tipine göre Payment döner. Spring proxy'lerinin final/private/static metotlarda çalışmamasının nedeni de bu.

","links":[{"title":"Overriding and Hiding Methods","url":"https://docs.oracle.com/javase/tutorial/java/IandI/override.html"},{"title":"JLS §15.12: Method Invocation Expressions","url":"https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.12"}]},{"kind":"mcq","id":"j-j2","category":"Java","label":"Java & Spring temelleri · OOP · Abstract class & Interface","bodyHtml":"

Ödeme yöntemlerini modelliyoruz: abstract class mı, interface mi?

Kart, havale ve cüzdan ödemelerini modelliyorsun. Hepsinin ortak bir pay() davranışı var. Bazılarının ortak doğrulama ve loglama kodu da var. Yeni ödeme tipleri sadece ödeme ekibi tarafından eklenebilmeli.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Java 8+ interface'lerde default ve static metot, Java 9+ ile private metot tanımlanabilir.","whyHtml":"Doğru. default metotlar mevcut implementasyonları kırmadan interface'e davranış eklemek için geldi (ör. Collection.stream())."},{"id":"b","ok":false,"html":"Interface'ler instance alanı (state) tutabilir; her implementasyon kendi kopyasını alır.","whyHtml":"Yanlış. Interface'te tanımlanan alanlar örtük olarak public static final'dır (sabit). State tutmak için abstract class gerekir."},{"id":"c","ok":true,"html":"Abstract class constructor ve state içerebilir. Bir sınıf sadece bir sınıfı extend edebilir, ama birden fazla interface implemente edebilir.","whyHtml":"Doğru. Java'da sınıf seviyesinde çoklu kalıtım yoktur; tip seviyesinde (interface) vardır."},{"id":"d","ok":true,"html":"Bir sınıf aynı imzalı default metoda sahip iki interface'i implemente ederse metodu override etmek zorundadır ve A.super.validate() ile istediğini çağırabilir.","whyHtml":"Doğru. Bu \"diamond problem\"in Java'daki çözümü. Derleyici belirsizliği senin çözmeni ister."},{"id":"e","ok":false,"html":"Abstract class'larda somut (gövdesi olan) metot olamaz; hepsi abstract olmalıdır.","whyHtml":"Yanlış. Abstract class hem abstract hem somut metot içerebilir. Template Method pattern'in temeli de bu."},{"id":"f","ok":true,"html":"sealed interface PaymentMethod permits Card, Transfer, Wallet (Java 17) implementasyonları sınırlar. switch pattern matching'de tüm durumlar ele alınmazsa derleyici hata verir.","whyHtml":"Doğru. Sealed tipler kapalı bir hiyerarşi kurar. Yeni bir tip eklenince ele alınmayan switch'ler derleme hatası verir."}],"explanationHtml":"

Sözleşmeyi interface ile tanımlarım: çoklu implementasyon, test ve DI için. Ortak state veya akış varsa abstract class ile Template Method kurarım. Interface'te state olmaz, default/static/private metot olabilir; çakışan default'larda override zorunludur. Kapalı bir hiyerarşi gerekiyorsa sealed interface + record + switch pattern matching kullanırım; yeni bir tip eklendiğinde derleyici beni uyarır.

","links":[{"title":"Abstract Methods and Classes","url":"https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html"},{"title":"dev.java · Learn (interfaces, records, sealed, pattern matching)","url":"https://dev.java/learn/"}]},{"kind":"open","id":"j-j3","category":"Java","label":"Java & Spring temelleri · OOP · Composition vs Inheritance","bodyHtml":"

Sayaç neden 6 diyor? Kırılgan üst sınıf

Bir analitik ekibi, sepete eklenen ürünleri saymak için HashSet'ten türeyen bir sınıf yazdı. Testte 3 eleman eklendiği halde sayaç 6 gösteriyor.

public class CountingSet<E> extends HashSet<E> {\n    private int addCount = 0;\n\n    @Override\n    public boolean add(E e) {\n        addCount++;\n        return super.add(e);\n    }\n\n    @Override\n    public boolean addAll(Collection<? extends E> c) {\n        addCount += c.size();\n        return super.addAll(c);\n    }\n\n    public int getAddCount() { return addCount; }\n}\n\nCountingSet<String> s = new CountingSet<>();\ns.addAll(List.of(\"a\", \"b\", \"c\"));\nSystem.out.println(s.getAddCount());   // 6

Neden 6? Bu tasarımın kök problemi ne, hangi ilkeyle ve nasıl düzeltirsin? Kısa bir kod iskeleti de yazabilirsin.

","answers":{},"modelAnswerHtml":"$16","rubric":["HashSet.addAll (AbstractCollection) içeride her eleman için override edilmiş add()'i çağırır; sayım iki kez yapılır","Kök problem: kalıtım encapsulation'ı bozar; üst sınıfın iç implementasyon detayına bağımlılık (fragile base class)","Çözüm: composition / forwarding (wrapper, decorator); Set'i içeride tutup arayüzü implemente etmek","İlke: Favor composition over inheritance (is-a değil has-a); kalıtım sadece gerçek is-a ilişkisi ve kalıtım için tasarlanmış sınıflarda","LSP veya JDK sürümüyle davranışın değişebileceği riski; ya da final sınıflar / dokümantasyon"]},{"kind":"mcq","id":"j-j4","category":"Java","label":"Java & Spring temelleri · OOP · Immutability","bodyHtml":"

\"Immutable\" sipariş nesnesi gerçekten immutable mı?

Sipariş nesnesi birden fazla thread arasında paylaşılıyor ve cache'leniyor. Ekip sınıfı \"immutable\" diye işaretlemiş.

public final class Order {\n    private final List<OrderLine> lines;\n    private final Date createdAt;\n\n    public Order(List<OrderLine> lines, Date createdAt) {\n        this.lines = lines;\n        this.createdAt = createdAt;\n    }\n\n    public List<OrderLine> getLines() { return lines; }\n    public Date getCreatedAt()        { return createdAt; }\n}

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":false,"html":"Alanların final olması sınıfı immutable yapmaya yeter.","whyHtml":"Yanlış. final sadece referansın değişmeyeceğini söyler; referans verilen List ve Date'in içi değiştirilebilir."},{"id":"b","ok":true,"html":"Constructor'da List.copyOf(lines) ile savunmacı kopya alınmalı. Aksi halde çağıran taraf elindeki listeyi değiştirerek siparişi değiştirebilir.","whyHtml":"Doğru. List.copyOf hem kopyalar hem değiştirilemez bir liste döner (ve null elemanı reddeder)."},{"id":"c","ok":true,"html":"Mevcut haliyle getLines().add(...) siparişin içeriğini dışarıdan değiştirir.","whyHtml":"Doğru. İç referans olduğu gibi dışarı sızıyor. Kopya ya da değiştirilemez görünüm dönmek gerekir."},{"id":"d","ok":true,"html":"Date mutable olduğu için yerine Instant kullanılmalı ya da kopyalanmalı.","whyHtml":"Doğru. getCreatedAt().setTime(0) siparişin tarihini değiştirir. java.time tipleri immutable'dır."},{"id":"e","ok":true,"html":"OrderLine mutable ise Order da tam olarak immutable sayılmaz.","whyHtml":"Doğru. Immutability derin (transitive) bir özelliktir. Liste değişmese bile içindeki OrderLine'ın fiyatı değişebilir."},{"id":"f","ok":false,"html":"Bunu record Order(List<OrderLine> lines, Instant createdAt) yaparsak bileşenler otomatik olarak derin kopyalanır.","whyHtml":"Yanlış. Record'lar sığ (shallow) immutable'dır. Compact constructor'da elle lines = List.copyOf(lines) yazmak gerekir."}],"explanationHtml":"

final sadece referansı sabitler; List ve Date'in içi değişebilir. Girişte List.copyOf ile kopya alırım, dışarıya değiştirilemez liste veririm, Date yerine Instant kullanırım, OrderLine'ı da immutable record yaparım. Record'lar sığ immutable'dır; kopyayı compact constructor'da elle yaparım. Kazancım bedava thread-safety ve güvenli cache key.

","links":[{"title":"A Strategy for Defining Immutable Objects","url":"https://docs.oracle.com/javase/tutorial/essential/concurrency/imstrat.html"},{"title":"List (Java 21) · copyOf / of","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List.html"}]},{"kind":"mcq","id":"j-j5","category":"Java","label":"Java & Spring temelleri · Java · Exceptions","bodyHtml":"

finally içindeki return neyi yutar?

Bir yardımcı metot, hata durumunda varsayılan değer dönmesi için yazılmış.

static int compute() {\n    try {\n        throw new IllegalStateException(\"stok servisi cevap vermedi\");\n    } catch (IllegalStateException e) {\n        return 1;\n    } finally {\n        return 2;\n    }\n}\n\nSystem.out.println(compute());

Çıktı nedir?

","multi":false,"options":[{"id":"a","ok":false,"html":"1","whyHtml":"catch'teki return değeri hazırlanır, ama metot dönmeden önce finally çalışır ve kendi return'ü onu ezer."},{"id":"b","ok":true,"html":"2","whyHtml":"Doğru. finally her zaman çalışır ve içindeki return, try veya catch'in dönüş değerini (ve fırlatılmakta olan exception'ı) ezer. Bu yüzden finally'de return yazmak bir anti-pattern'dir."},{"id":"c","ok":false,"html":"IllegalStateException fırlar.","whyHtml":"Exception catch'te yakalandı. Yakalanmasaydı bile finally'deki return onu sessizce yutardı."},{"id":"d","ok":false,"html":"Derleme hatası.","whyHtml":"Derlenir; derleyici sadece \"finally block does not complete normally\" uyarısı verir."}],"explanationHtml":"

2 yazar. finally her durumda çalışır ve içindeki return, catch'in dönüşünü ve fırlatılmakta olan exception'ı ezer. Bu yüzden finally'de asla return yazmam. Kaynakları try-with-resources ile kapatırım; ikincil hatalar suppressed olarak korunur. Domain hataları için unchecked exception kullanır, cause'u korur, HTTP'ye ControllerAdvice ile çeviririm.

","links":[{"title":"The try-with-resources Statement","url":"https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html"},{"title":"Unchecked Exceptions: The Controversy","url":"https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html"}]},{"kind":"mcq","id":"j-j6","category":"Java","label":"Java & Spring temelleri · Java · Generics","bodyHtml":"

Wildcard'lar: hangi satırlar derlenir?

Bir raporlama yardımcı sınıfında sayısal listelerle çalışan generic metotlar yazılıyor.

List<? extends Number> producer = new ArrayList<Integer>();\nproducer.add(1);                       // (1)\nNumber n = producer.get(0);            // (2)\n\nList<? super Integer> consumer = new ArrayList<Number>();\nconsumer.add(1);                       // (3)\nInteger i = consumer.get(0);           // (4)

Hangi satırlar derlenir?

","multi":false,"options":[{"id":"a","ok":false,"html":"Hepsi derlenir.","whyHtml":"(1) ve (4) derlenmez. Wildcard'lar okuma ve yazma yönünü kısıtlar."},{"id":"b","ok":true,"html":"Sadece (2) ve (3).","whyHtml":"Doğru. \"? extends Number\" bir üretici: içinden Number okunur ama ne tür bir listeye eklediğini bilmediğin için ekleme yapılamaz (Double listesi olabilir). \"? super Integer\" bir tüketici: içine Integer eklenir, ama okunan değerin tipi sadece Object olarak garanti edilir."},{"id":"c","ok":false,"html":"Sadece (1) ve (4).","whyHtml":"Tam tersi. extends okumaya, super yazmaya izin verir."},{"id":"d","ok":false,"html":"Sadece (2).","whyHtml":"(3) de derlenir: Integer, Integer'ın herhangi bir üst tipinin listesine güvenle eklenebilir."}],"explanationHtml":"

Sadece 2 ve 3 derlenir. ? extends üreticidir: Number okurum ama ekleyemem, çünkü liste Double listesi olabilir. ? super tüketicidir: Integer eklerim ama okurken Object alırım. Kural PECS; Collections.copy imzası bunun örneği. Generic'ler invariant'tır, diziler kovaryant olduğu için ArrayStoreException riski taşır. Erasure yüzünden çalışma anında tip bilgisi yoktur; Jackson'da TypeReference kullanırım.

","links":[{"title":"Guidelines for Wildcard Use","url":"https://docs.oracle.com/javase/tutorial/java/generics/wildcardGuidelines.html"},{"title":"Wildcard (Java)","url":"https://en.wikipedia.org/wiki/Wildcard_(Java)"}]},{"kind":"mcq","id":"j-j7","category":"Java","label":"Java & Spring temelleri · String · Pool & ==","bodyHtml":"

String pool: hangi karşılaştırmalar true?

Bir kod incelemesinde kampanya kodları == ile karşılaştırılmış. \"Testte çalışıyordu\" deniyor.

String a = \"backend\";\nString b = \"back\" + \"end\";\nString c = \"back\";\nString d = c + \"end\";\nString e = d.intern();\n\nSystem.out.println(a == b);       // (1)\nSystem.out.println(a == d);       // (2)\nSystem.out.println(a == e);       // (3)\nSystem.out.println(a.equals(d));  // (4)

(1)–(4) sırasıyla ne yazar?

","multi":false,"options":[{"id":"a","ok":false,"html":"true, true, true, true","whyHtml":"(2) false olur: c final olmayan bir değişken olduğu için c + \"end\" çalışma anında yeni bir String nesnesi üretir."},{"id":"b","ok":true,"html":"true, false, true, true","whyHtml":"Doğru. (1) İki literal'in birleşimi derleme anında sabit olarak katlanır (constant folding) ve pool'daki aynı nesneye işaret eder. (2) Çalışma anında yeni nesne oluşur. (3) intern() pool'daki kanonik nesneyi döner, o da a'dır. (4) equals içerik karşılaştırır."},{"id":"c","ok":false,"html":"false, false, true, true","whyHtml":"(1) true'dur: \"back\" + \"end\" bir compile-time constant expression'dır ve derleyici onu \"backend\" literal'ine çevirir."},{"id":"d","ok":false,"html":"true, false, false, true","whyHtml":"intern(), içerik pool'da varsa oradaki referansı döner. \"backend\" literal'i zaten pool'da, yani a'nın kendisi."}],"explanationHtml":"

Sonuç true, false, true, true. Literal birleşimi derleme anında katlanır ve pool'daki aynı nesneyi gösterir. Final olmayan değişkenle birleştirme çalışma anında yeni nesne üretir. intern pool'daki kanonik referansı döner. String'i her zaman equals ile karşılaştırırım; == literal'lerde tesadüfen çalışır. Türkçe metinlerde toLowerCase'in locale'ine dikkat ederim.

","links":[{"title":"Guide to Java String Pool","url":"https://www.baeldung.com/java-string-pool"},{"title":"String (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/String.html"}]},{"kind":"mcq","id":"j-j8","category":"Java","label":"Java & Spring temelleri · String · Immutability & StringBuilder","bodyHtml":"

String neden immutable? Döngüde birleştirme

Bir batch job 200.000 satırlık CSV'yi şu şekilde üretiyor ve job dakikalar sürüyor:

String csv = \"\";\nfor (Order o : orders) {\n    csv += o.id() + \";\" + o.total() + \"\\n\";\n}

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"String immutable olduğu için hashCode'u cache'lenebilir ve HashMap key'i olarak güvenlidir.","whyHtml":"Doğru. String.hashCode ilk hesaplamadan sonra alanında saklanır."},{"id":"b","ok":true,"html":"Immutable olduğu için thread'ler arasında senkronizasyon olmadan paylaşılabilir ve String pool güvenle var olabilir.","whyHtml":"Doğru. Bir referansın değeri başka bir kod tarafından değiştirilemez."},{"id":"c","ok":true,"html":"Güvenlik: dosya yolu, URL veya class adı doğrulandıktan sonra başka bir kod tarafından değiştirilemez.","whyHtml":"Doğru. Doğrulama ile kullanım arasında içerik değişseydi güvenlik açığı oluşurdu (TOCTOU)."},{"id":"d","ok":false,"html":"Java 9+ invokedynamic tabanlı birleştirme sayesinde döngüdeki += artık O(n) çalışır, StringBuilder gereksizdir.","whyHtml":"Yanlış. indy sadece tek bir ifadenin içindeki birleştirmeyi optimize eder. Döngünün her turunda büyüyen içerik yeniden kopyalanır; toplam maliyet O(n²) olur."},{"id":"e","ok":false,"html":"StringBuilder thread-safe'tir, StringBuffer değildir.","whyHtml":"Tam tersi. StringBuffer'ın metotları synchronized'dır; StringBuilder değildir ve tek thread'de daha hızlıdır."},{"id":"f","ok":true,"html":"Java 9+ Compact Strings: Latin-1'e sığan içerik karakter başına 1 byte (byte[]) ile tutulur.","whyHtml":"Doğru. JEP 254. Türkçe karakterler (ş, ğ, ı) Latin-1'de olmadığı için o String'ler UTF-16 (2 byte) ile tutulur."},{"id":"g","ok":true,"html":"Şifreler String yerine char[]'da tutulur; String immutable olduğu için kullanım sonrası sıfırlanamaz ve GC'ye kadar bellekte (heap dump'ta) kalır.","whyHtml":"Doğru. char[] kullanım sonrası Arrays.fill ile temizlenebilir."}],"explanationHtml":"

String immutable olduğu için hash'i cache'lenir, thread'ler arasında güvenle paylaşılır, pool mümkün olur ve doğrulanan değer sonradan değiştirilemez. Döngüde += her turda tüm içeriği kopyalar, O(n²) ve büyük GC baskısı demek; StringBuilder ya da joining kullanırım. Büyük çıktıyı belleğe toplamak yerine stream'lerim. Şifreleri char[]'da tutarım.

","links":[{"title":"JEP 254: Compact Strings","url":"https://openjdk.org/jeps/254"},{"title":"JEP 280: Indify String Concatenation","url":"https://openjdk.org/jeps/280"}]},{"kind":"mcq","id":"j-j9","category":"Java","label":"Java & Spring temelleri · JVM · Heap & Stack","bodyHtml":"

Bu metotta ne nerede yaşar?

Aşağıdaki metot bir istek thread'inde çalışıyor. cache, sınıfın static bir Map alanı.

private static final Map<Long, Order> cache = new ConcurrentHashMap<>();\n\nvoid process() {\n    int count = 5;                              // (1)\n    Order order = new Order(42L);               // (2)\n    List<Order> list = new ArrayList<>();       // (3)\n    list.add(order);\n    cache.put(42L, order);\n}

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"count bu metodun stack frame'inde (local variable table) tutulur.","whyHtml":"Doğru. Local primitive'ler stack frame'de yaşar ve metot bitince yok olur."},{"id":"b","ok":true,"html":"order referansı stack'te, işaret ettiği Order nesnesi heap'tedir.","whyHtml":"Doğru. Nesneler heap'te oluşturulur (JIT'in escape analysis optimizasyonları hariç; bu nesne zaten static cache'e kaçıyor)."},{"id":"c","ok":false,"html":"Metot bittiğinde Order nesnesi GC'ye uygun hale gelir.","whyHtml":"Yanlış. static cache, GC root'tan erişilebilir bir referans tutuyor. Nesne cache'ten çıkarılana kadar yaşar. Sınırsız bir static cache, klasik bellek sızıntısı kaynağıdır."},{"id":"d","ok":true,"html":"Her thread'in kendi stack'i vardır; heap tüm thread'ler tarafından paylaşılır.","whyHtml":"Doğru. Bu yüzden local değişkenler doğal olarak thread-safe'tir, heap'teki paylaşılan nesneler değildir."},{"id":"e","ok":true,"html":"Derin veya sonsuz recursion StackOverflowError, heap dolması OutOfMemoryError: Java heap space verir.","whyHtml":"Doğru. Stack boyutu -Xss ile, heap -Xmx veya MaxRAMPercentage ile ayarlanır."},{"id":"f","ok":false,"html":"Primitive tipler her zaman stack'te tutulur.","whyHtml":"Yanlış. Bir nesnenin primitive alanı (Order.quantity) nesneyle birlikte heap'tedir. Sadece local primitive'ler stack'tedir."},{"id":"g","ok":true,"html":"Sınıf metadata'sı Metaspace'te (native bellek) tutulur; static alanların değerleri Java 8+ ile heap'teki Class nesnesiyle birlikte durur.","whyHtml":"Doğru. PermGen Java 8'de kaldırıldı. Metaspace sınırsız büyüyebilir; MaxMetaspaceSize ile sınırlanır."}],"explanationHtml":"

Local primitive'ler ve referanslar thread'in stack frame'inde; nesneler paylaşılan heap'te. Stack thread'e özel olduğu için local'ler thread-safe'tir. Nesne static cache'e konduğu için GC root'tan erişilebilir kalır ve metot bitince toplanmaz; sınırsız static cache sızıntı demek. Sınıf metadata'sı Metaspace'te, static alan değerleri heap'te. Derin recursion StackOverflowError, dolu heap OOM verir.

","links":[{"title":"Java Stack vs Heap: Memory Explained!","url":"https://www.youtube.com/watch?v=5Hs0RZSjfd4"},{"title":"Java Stack and Heap - Java Memory Management","url":"https://www.youtube.com/watch?v=450maTzSIvA"},{"title":"HotSpot GC Tuning Guide (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/gctuning/"}]},{"kind":"mcq","id":"j-j10","category":"Java","label":"Java & Spring temelleri · Java · Pass-by-value","bodyHtml":"

Java pass-by-reference mı?

Order sınıfının quantity alanı varsayılan olarak 0. getId() constructor'a verilen id'yi döner.

static void apply(Order o, int qty) {\n    o.setQuantity(qty);\n    o = new Order(99L);\n    o.setQuantity(100);\n    qty = 0;\n}\n\nOrder order = new Order(1L);\nint q = 5;\napply(order, q);\nSystem.out.println(order.getId() + \" \" + order.getQuantity() + \" \" + q);

Çıktı nedir?

","multi":false,"options":[{"id":"a","ok":false,"html":"1 0 5","whyHtml":"İlk satır (o.setQuantity(5)) orijinal nesneyi değiştirir; o henüz aynı nesneyi gösteriyor."},{"id":"b","ok":true,"html":"1 5 5","whyHtml":"Doğru. Java her şeyi değerle geçirir; nesneler için geçirilen değer referansın kopyasıdır. Kopya referansla nesneyi değiştirebilirsin (quantity = 5), ama kopyayı başka nesneye yönlendirmek (o = new ...) çağıranın değişkenini etkilemez. qty de kopyadır."},{"id":"c","ok":false,"html":"99 100 5","whyHtml":"Bu, Java pass-by-reference olsaydı geçerli olurdu. Değil."},{"id":"d","ok":false,"html":"1 5 0","whyHtml":"int değerle geçer; metot içindeki qty = 0 çağıranın q'sunu etkilemez."}],"explanationHtml":"

1 5 5 yazar. Java her zaman pass-by-value'dur; nesnelerde referansın kopyası geçer. Kopya üzerinden nesneyi değiştirmek çağıranı etkiler, kopyayı yeni nesneye yönlendirmek etkilemez. Bu yüzden mutable parametrelerin yan etkilerine ve JPA'da managed entity'lerin dirty checking ile sessizce güncellenmesine dikkat ederim.

","links":[{"title":"Passing Information to a Method or a Constructor","url":"https://docs.oracle.com/javase/tutorial/java/javaOO/arguments.html"}]},{"kind":"open","id":"j-j11","category":"Java","label":"Java & Spring temelleri · JVM · GC & Memory leak","bodyHtml":"$17","answers":{},"modelAnswerHtml":"$18","rubric":["ThreadLocal temizlenmiyor: thread havuzu thread'leri yeniden kullanır; hem sızıntı hem başka kullanıcının verisinin görünmesi (veri sızıntısı)","AUDIT static ve sınırsız: her session için sonsuza kadar büyür (GC root'tan erişilebilir)","Map değeri ArrayList: aynı session'a eşzamanlı eklemelerde thread-safe değil","Teşhis: heap dump (jcmd GC.heap_dump, HeapDumpOnOutOfMemoryError) ve MAT ile dominator tree / retained size analizi","Teşhis: GC logları ve metrikler (GC sonrası old gen tabanının yükselmesi)","Düzeltme: finally'de remove, bounded cache (Caffeine, TTL/size) ya da audit'i asenkron bir sisteme (Kafka/log) yazmak"]},{"kind":"mcq","id":"j-j12","category":"Java","label":"Java & Spring temelleri · Lambda · Functional interface","bodyHtml":"

Lambda'lar ve functional interface'ler

Kampanya motorunda kurallar lambda'larla tanımlanıyor: Predicate<Cart> ile uygunluk, Function<Cart, BigDecimal> ile indirim hesabı.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Lambda sadece effectively final local değişkenleri yakalayabilir.","whyHtml":"Doğru. Yakalanan değer kopyalanır. Değişebilseydi lambda'nın (belki başka bir thread'de) hangi değeri göreceği belirsiz olurdu."},{"id":"b","ok":true,"html":"@FunctionalInterface tek bir abstract metot içerir; default ve static metotlar bu sayıya dahil değildir.","whyHtml":"Doğru. Object'in public metotlarının (equals vb.) yeniden bildirimi de sayılmaz. Anotasyon zorunlu değildir ama derleyiciye kontrol ettirir."},{"id":"c","ok":true,"html":"Supplier<T> parametre almaz, Consumer<T> değer döndürmez, Predicate<T> boolean döner, Function<T,R> T'yi R'ye çevirir.","whyHtml":"Doğru. Bunlara Bi- versiyonları (BiFunction) ve primitive özelleşmeleri (IntPredicate, ToLongFunction) eşlik eder."},{"id":"d","ok":true,"html":"Lambda içindeki this, çevreleyen sınıfın instance'ını gösterir; anonim sınıfta ise anonim sınıfın kendisini.","whyHtml":"Doğru. Lambda yeni bir scope açmaz (lexical scoping); anonim sınıf açar."},{"id":"e","ok":false,"html":"String::length bir Function<String, Integer> olarak kullanılamaz.","whyHtml":"Yanlış. Unbound instance method reference'ta ilk parametre receiver olur: s -> s.length()."},{"id":"f","ok":false,"html":"Checked exception fırlatan bir metot doğrudan Function'a verilebilir; derleyici exception'ı otomatik sarar.","whyHtml":"Yanlış. Function.apply checked exception bildirmez. Lambda içinde yakalayıp unchecked'e sarmak ya da kendi functional interface'ini tanımlamak gerekir."}],"explanationHtml":"

Lambda'lar functional interface'lerin, yani tek abstract metotlu tiplerin implementasyonudur. Yakalanan local'ler effectively final olmalı, çünkü kopyalanırlar. this çevreleyen sınıfı gösterir. Supplier, Consumer, Predicate ve Function'ı and, negate, andThen ile birleştirip kural motoru gibi bildirimsel yapılar kurarım. Checked exception'lar Function'a doğrudan girmez; sarmalarım.

","links":[{"title":"Lambda Expressions","url":"https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html"},{"title":"java.util.function paketi (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/function/package-summary.html"}]},{"kind":"mcq","id":"j-j13","category":"Java","label":"Java & Spring temelleri · Stream · Laziness","bodyHtml":"

Stream tembeldir: ekrana tam olarak ne yazar?

Bir geliştirici, stream'in her elemanı önce filter'dan, sonra toplu olarak map'ten geçirdiğini düşünüyor.

List<String> result = Stream.of(\"kalem\", \"defter\", \"silgi\", \"kitap\")\n        .filter(s -> { System.out.print(\"F:\" + s + \" \"); return s.startsWith(\"k\"); })\n        .map(s -> { System.out.print(\"M:\" + s + \" \"); return s.toUpperCase(); })\n        .limit(1)\n        .toList();

Konsola ne yazılır?

","multi":false,"options":[{"id":"a","ok":false,"html":"F:kalem F:defter F:silgi F:kitap M:kalem M:kitap","whyHtml":"Stream'ler aşama aşama (önce hepsi filter, sonra hepsi map) değil, eleman eleman (dikey) işlenir."},{"id":"b","ok":true,"html":"F:kalem M:kalem","whyHtml":"Doğru. \"kalem\" filter'dan geçer, map'lenir, limit(1) dolar. limit short-circuiting bir işlemdir: kaynaktan başka eleman çekilmez."},{"id":"c","ok":false,"html":"Hiçbir şey; stream tembel olduğu için çalışmaz.","whyHtml":"Tembellik terminal işleme kadar bekler demektir. toList() terminal işlemdir ve pipeline'ı çalıştırır."},{"id":"d","ok":false,"html":"F:kalem M:kalem F:defter F:silgi F:kitap M:kitap","whyHtml":"limit(1) dolunca işlem durur. Kalan elemanlar kaynaktan hiç çekilmez."}],"explanationHtml":"

F:kalem M:kalem yazar. Stream'ler tembeldir ve terminal işlem gelene kadar çalışmaz. Çalışınca elemanları aşama aşama değil, eleman eleman işler. limit short-circuiting olduğu için ilk sonuçtan sonra kaynaktan eleman çekmez. Bu yüzden önce filter, sonra pahalı map yazarım; sorted gibi stateful işlemlerin dikey akışı bozduğunu bilirim.

","links":[{"title":"java.util.stream paketi (Stream operations and pipelines)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/package-summary.html"},{"title":"Collectors in the wild!","url":"https://www.youtube.com/watch?v=yddwA3458eo"}]},{"kind":"open","id":"j-j14","category":"Java","label":"Java & Spring temelleri · Stream · Collectors","bodyHtml":"$19","answers":{},"modelAnswerHtml":"$1a","rubric":["1) flatMap ile siparişlerden satırlara inmek","1) groupingBy(category) + BigDecimal toplama (reducing veya toMap merge)","1) BigDecimal::add ile toplama (double kullanmadan)","2) partitioningBy ile ikiye ayırma, compareTo ile karşılaştırma","3) map + distinct + sorted (ya da TreeSet)","4) max(Comparator.comparing(Order::total)) ile Optional dönmek"]},{"kind":"mcq","id":"j-j15","category":"Java","label":"Java & Spring temelleri · Optional · Stream tuzakları","bodyHtml":"

Optional ve stream tuzakları

Kod incelemesinde Optional ve stream kullanımlarıyla ilgili yorumlar yazılıyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"flatMap her elemanı bir Stream'e çevirip tek bir Stream'de düzleştirir.","whyHtml":"Doğru. Örn. siparişlerden sipariş satırlarına inmek."},{"id":"b","ok":true,"html":"isPresent() + get() yerine map, orElse, orElseThrow, ifPresentOrElse tercih edilir.","whyHtml":"Doğru. isPresent/get, null kontrolünün aynısıdır ve Optional'ın amacını boşa çıkarır."},{"id":"c","ok":false,"html":"Optional, entity alanı ve metot parametresi olarak kullanılması önerilen bir tiptir.","whyHtml":"Yanlış. Optional dönüş tipi için tasarlandı. Alan olarak Serializable değildir ve JPA desteklemez; parametre olarak çağıranı zorlar."},{"id":"d","ok":true,"html":"orElse(createDefault()) Optional dolu olsa bile createDefault()'u çalıştırır; orElseGet(this::createDefault) çalıştırmaz.","whyHtml":"Doğru. orElse'nin argümanı çağrıdan önce hesaplanır. Pahalı veya yan etkili varsayılanlar (DB çağrısı) için orElseGet kullanılır."},{"id":"e","ok":false,"html":"Bir Stream tüketildikten sonra tekrar terminal işlem çağrılabilir.","whyHtml":"Yanlış. IllegalStateException: stream has already been operated upon or closed. Tekrar gerekiyorsa Supplier kullanılır."},{"id":"f","ok":true,"html":"peek debug amaçlıdır; bazı durumlarda (örneğin boyutu bilinen bir kaynakta count()) hiç çalışmayabilir.","whyHtml":"Doğru. Java 9+ count(), boyutu kaynaktan biliyorsa pipeline'ı çalıştırmayabilir. peek'e iş mantığı koyma."},{"id":"g","ok":true,"html":"parallelStream() ortak ForkJoinPool.commonPool()'u kullanır; bloklayan I/O yapan işlerde tüm uygulamayı yavaşlatabilir.","whyHtml":"Doğru. Parallel stream büyük, CPU-yoğun ve yan etkisiz işler içindir. Web isteklerinde nadiren doğru tercihtir."}],"explanationHtml":"

Optional'ı sadece dönüş tipinde kullanırım, alan ya da parametre olarak değil. isPresent/get yerine map, orElseThrow ve pahalı varsayılanlar için orElseGet kullanırım. Stream'ler tek kullanımlıktır, peek sadece debug içindir. parallelStream commonPool'u kullandığı için I/O'lu web kodunda tercih etmem.

","links":[{"title":"Optional (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html"},{"title":"Guide To Java Optional","url":"https://www.baeldung.com/java-optional"}]},{"kind":"mcq","id":"j-j16","category":"Java","label":"Java & Spring temelleri · Collectors.toMap","bodyHtml":"

Satıcı → ürün haritası production'da patladı

Ürün listesinden satıcı bazında bir harita üretiliyor. Testte her satıcının tek ürünü vardı.

record Product(long id, long sellerId, String name) {}\n\nMap<Long, String> bySeller = products.stream()\n        .collect(Collectors.toMap(Product::sellerId, Product::name));

Aynı satıcıya ait iki ürün varsa ne olur?

","multi":false,"options":[{"id":"a","ok":false,"html":"Son gelen ürünün adı sessizce yazılır (HashMap.put gibi).","whyHtml":"toMap, HashMap.put'tan farklı davranır; varsayılan olarak çakışmaya izin vermez."},{"id":"b","ok":false,"html":"İlk gelen ürünün adı korunur.","whyHtml":"Bu davranışı elde etmek için merge fonksiyonu vermek gerekir: (a, b) -> a."},{"id":"c","ok":true,"html":"IllegalStateException: Duplicate key ... fırlar.","whyHtml":"Doğru. İki parametreli toMap çakışmada exception fırlatır. Ayrıca value null ise NullPointerException fırlatır (içeride HashMap.merge kullanılır)."},{"id":"d","ok":false,"html":"Derleme hatası; key'ler unique olmak zorunda.","whyHtml":"Derleyici veriyi bilemez; hata çalışma anında oluşur."}],"explanationHtml":"

İki parametreli toMap duplicate key'de IllegalStateException, null değerde NPE fırlatır. Satıcı başına birden fazla ürün varsa groupingBy + mapping kullanırım; tek değer gerçekten isteniyorsa merge fonksiyonuyla çakışma kuralını açıkça yazarım. Test verisine duplicate ve null gibi kenar durumları koyarım.

","links":[{"title":"Collectors.toMap (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html"}]},{"kind":"mcq","id":"j-j17","category":"Java","label":"Java & Spring temelleri · ConcurrentHashMap · Internals","bodyHtml":"

ConcurrentHashMap içeride nasıl çalışır?

Ürün bazlı görüntülenme sayıları, 200 istek thread'inin aynı anda yazdığı bir map'te tutuluyor. Ekip HashMap, Collections.synchronizedMap ve ConcurrentHashMap arasında seçim yapıyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Java 8+ ConcurrentHashMap, Java 7'deki segment kilitleri yerine boş bucket'a CAS ile, dolu bucket'a o bucket'ın ilk node'u üzerinde synchronized ile yazar.","whyHtml":"Doğru. Kilit kapsamı tek bir bucket'tır; farklı bucket'lara yazan thread'ler birbirini beklemez."},{"id":"b","ok":true,"html":"get() çoğu durumda kilit almaz; volatile okumalarla güncel değeri görür.","whyHtml":"Doğru. Okumalar ölçeklenir."},{"id":"c","ok":true,"html":"ConcurrentHashMap null key ve null value kabul etmez.","whyHtml":"Doğru. get() null dönerse \"key yok\" mu yoksa \"değer null\" mı belirsiz kalırdı; eşzamanlı ortamda containsKey ile ayırt etmek de race'li olurdu."},{"id":"d","ok":false,"html":"size() eşzamanlı güncellemeler sırasında bile her zaman anlık ve kesin değeri verir.","whyHtml":"Yanlış. size, isEmpty ve containsValue gibi toplu metotlar eşzamanlı güncelleme sırasında sadece yaklaşık bilgi verir (Javadoc). Büyük map'lerde mappingCount() tercih edilir."},{"id":"e","ok":false,"html":"Iteration sırasında başka thread map'i değiştirirse ConcurrentModificationException fırlar.","whyHtml":"Yanlış. Iterator'lar weakly consistent'tir: exception fırlatmaz, iterator oluşturulduktan sonraki değişiklikleri görebilir de görmeyebilir de."},{"id":"f","ok":true,"html":"Çok çakışan bir bucket'taki bağlı liste 8 eleman eşiğinde (tablo en az 64 olduğunda) dengeli ağaca (TreeBin) dönüşür.","whyHtml":"Doğru. Kötü hashCode veya hash flooding saldırısında arama O(n) yerine O(log n) olur. HashMap'te de aynı mekanizma var."},{"id":"g","ok":false,"html":"Collections.synchronizedMap ConcurrentHashMap kadar iyi ölçeklenir, çünkü ikisi de thread-safe'tir.","whyHtml":"Yanlış. synchronizedMap tüm map için tek bir kilit kullanır; okumalar dahil her şey sıraya girer."}],"explanationHtml":"

Java 8+ CHM boş bucket'a CAS, dolu bucket'a bucket seviyesinde synchronized ile yazar; okumalar kilitsizdir. Null kabul etmez, iterator'ları weakly consistent'tir, size eşzamanlı yazmada yaklaşıktır. Çakışan bucket 8 elemanda ağaca döner. Asıl önemli nokta, bileşik işlemleri merge veya compute ile atomik yapmak; yüksek çekişmeli sayaç için LongAdder kullanırım. synchronizedMap tek kilitle çalıştığı için ölçeklenmez.

","links":[{"title":"ConcurrentHashMap (Java 21)","url":"https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html"},{"title":"Java Memory Model Unlearning Experience","url":"https://www.youtube.com/watch?v=TK-7GCCDF_I"}]},{"kind":"open","id":"j-j18","category":"Java","label":"Java & Spring temelleri · CompletableFuture","bodyHtml":"

Ürün sayfası: üç servisi paralel çağır

Ürün detay sayfası fiyat, stok ve kampanya bilgisini üç ayrı servisten alıyor. Her biri 100–200 ms sürüyor; sıralı çağırınca sayfa 500 ms'yi geçiyor.

Fiyat veya stok alınamazsa sayfa hata dönmeli.
Kampanya servisi yavaşsa veya hata verirse sayfa kampanyasız (Campaign.NONE) açılmalı.
Her çağrı en fazla 300 ms beklenmeli.

public ProductView load(long productId) {\n    // Kullanılabilir: priceClient.get(id), stockClient.get(id), campaignClient.get(id)\n    // Executor ioExecutor (I/O için ayrılmış havuz), Campaign.NONE\n    // new ProductView(Price, Stock, Campaign)\n}

Metodu CompletableFuture ile yaz. Ardından bir cümleyle: orTimeout, alttaki HTTP çağrısını gerçekten durdurur mu?

","answers":{},"modelAnswerHtml":"$1b","rubric":["supplyAsync ile çağrıları paralel başlatmak","Ayrı I/O executor vermek (commonPool'u kullanmamak)","Zaman aşımı: orTimeout / completeOnTimeout","Kampanya için fallback: exceptionally / handle / completeOnTimeout(NONE)","Sonuçları birleştirmek: allOf + join / thenCombine","orTimeout future'ı tamamlar ama HTTP çağrısını iptal etmez; client'ta da timeout gerekir"]},{"kind":"open","id":"j-j19","category":"Java","label":"Java & Spring temelleri · Concurrency · Deadlock","bodyHtml":"

Cüzdanlar arası transfer donuyor

Kullanıcılar arası para transferi bazen hiç bitmiyor. Thread'ler BLOCKED durumda kalıyor ve servis yavaş yavaş cevap veremez hale geliyor.

public void transfer(Wallet from, Wallet to, BigDecimal amount) {\n    synchronized (from) {\n        synchronized (to) {\n            from.withdraw(amount);\n            to.deposit(amount);\n        }\n    }\n}\n\n// Thread 1: transfer(ali, ayse, 100)\n// Thread 2: transfer(ayse, ali, 50)

Ne oluyor, nasıl tespit edersin, nasıl düzeltirsin? Aynı problemin veritabanı karşılığını da düşün.

","answers":{},"modelAnswerHtml":"$1c","rubric":["Deadlock: T1 ali'yi tutup ayse'yi, T2 ayse'yi tutup ali'yi bekler; döngüsel bekleme","Tespit: thread dump (jstack / jcmd Thread.print), 'Found one Java-level deadlock'","Çözüm: global kilit sırası (ör. wallet id'ye göre önce küçük olanı kilitle)","Alternatif: ReentrantLock.tryLock(timeout) ile geri çekilip yeniden denemek","Asıl doğru yer: DB'de transaction + satır kilidi / atomik UPDATE; JVM kilidi çok pod'da işe yaramaz","DB'de de deadlock olur: satırları aynı sırada kilitle; PostgreSQL birini abort eder, retry gerekir"]},{"kind":"mcq","id":"j-j20","category":"Spring","label":"Java & Spring temelleri · Spring · IoC & DI","bodyHtml":"

IoC container ve dependency injection

Projede iki ödeme sağlayıcısı var: IyzicoGateway ve StripeGateway. İkisi de PaymentGateway interface'ini implemente ediyor ve ikisi de @Component. CheckoutService constructor'ında PaymentGateway istiyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"IoC, nesne oluşturma ve bağımlılıkları bağlama kontrolünün uygulama kodundan container'a geçmesidir; DI bunun uygulanış biçimidir.","whyHtml":"Doğru. Sınıf bağımlılığını new ile kendisi oluşturmaz, dışarıdan alır."},{"id":"b","ok":true,"html":"Constructor injection, field injection'a tercih edilir: alanlar final olur, nesne eksik bağımlılıkla oluşamaz, testte new ile kurulur.","whyHtml":"Doğru. Tek constructor varsa @Autowired yazmaya da gerek yoktur."},{"id":"c","ok":false,"html":"Aynı tipte iki bean varken Spring bunlardan birini rastgele seçip enjekte eder.","whyHtml":"Yanlış. NoUniqueBeanDefinitionException ile açılmaz. @Primary, @Qualifier, parametre adının bean adıyla eşleşmesi ya da List/Map enjeksiyonu ile çözülür."},{"id":"d","ok":true,"html":"Kendi sınıfların @Component + component scan ile, üçüncü parti sınıflar (ör. bir SDK client'ı) @Configuration içindeki @Bean metotlarıyla tanımlanır.","whyHtml":"Doğru. Kaynak koduna anotasyon ekleyemediğin sınıflar @Bean ile kaydedilir."},{"id":"e","ok":true,"html":"@Configuration sınıfında bir @Bean metodundan başka bir @Bean metodunu çağırmak aynı singleton'ı döner; @Component içindeki @Bean (lite mode) her çağrıda yeni nesne üretir.","whyHtml":"Doğru. @Configuration sınıfları CGLIB ile proxy'lenir (proxyBeanMethods=true) ve metot çağrısı container'a yönlendirilir."},{"id":"f","ok":false,"html":"Spring, singleton bean'leri varsayılan olarak ilk kullanıldıklarında (lazy) oluşturur.","whyHtml":"Yanlış. Singleton'lar context açılırken eager oluşturulur; konfigürasyon hataları açılışta yakalanır. @Lazy ile değiştirilebilir."}],"explanationHtml":"

IoC, nesne oluşturma ve bağlama kontrolünün container'a geçmesidir; DI ile sınıflar soyutlamaya bağlı kalır ve test edilebilir olur. Constructor injection kullanırım: final alanlar, eksiksiz nesne. Aynı tipte iki bean varsa Spring rastgele seçmez, hata verir; @Qualifier, @Primary ya da Map enjeksiyonuyla çözerim. Üçüncü parti sınıfları @Bean ile tanımlarım. @Configuration proxy'lendiği için içindeki @Bean çağrıları singleton döner.

","links":[{"title":"Dependency Injection & IoC Explained","url":"https://www.youtube.com/watch?v=dT10m_5POfs"},{"title":"Introduction to the Spring IoC Container and Beans","url":"https://docs.spring.io/spring-framework/reference/core/beans/introduction.html"},{"title":"Basic Concepts: @Bean and @Configuration (full vs lite mode)","url":"https://docs.spring.io/spring-framework/reference/core/beans/java/basic-concepts.html"}]},{"kind":"mcq","id":"j-j21","category":"Spring","label":"Java & Spring temelleri · Spring · Bean scopes","bodyHtml":"

Prototype sepet herkese ortak oldu

Bir geliştirici, her kullanıcının kendi sepeti olsun diye ShoppingCart'ı prototype scope'lu yaptı.

@Component\n@Scope(\"prototype\")\nclass ShoppingCart {\n    final List<Item> items = new ArrayList<>();\n}\n\n@Service\nclass CheckoutService {\n    private final ShoppingCart cart;\n\n    CheckoutService(ShoppingCart cart) { this.cart = cart; }\n\n    void add(Item item) { cart.items.add(item); }\n}

Production'da ne olur?

","multi":false,"options":[{"id":"a","ok":false,"html":"Her HTTP isteği yeni bir ShoppingCart alır, çünkü prototype her kullanımda yeni nesne üretir.","whyHtml":"Prototype, her enjeksiyonda (ya da getBean çağrısında) yeni nesne üretir, her metot çağrısında değil. CheckoutService singleton olduğu için enjeksiyon bir kez yapılır."},{"id":"b","ok":true,"html":"CheckoutService singleton olduğu için sepet bir kez enjekte edilir ve tüm kullanıcılar aynı sepeti paylaşır. Üstelik ArrayList thread-safe olmadığı için veri de bozulur.","whyHtml":"Doğru. Bu, prototype-in-singleton tuzağı. Asıl düzeltme şu: sepet bir bean değil, kullanıcıya ait bir veridir; Redis veya DB'de userId ile tutulmalı."},{"id":"c","ok":false,"html":"Uygulama açılmaz; singleton'a prototype enjekte edilemez.","whyHtml":"Enjekte edilebilir ve sessizce çalışır. Tehlikesi de bu."},{"id":"d","ok":false,"html":"Spring, prototype bean'i her metot çağrısında otomatik olarak proxy ile yeniler.","whyHtml":"Bu ancak @Scope(value = \"prototype\", proxyMode = ScopedProxyMode.TARGET_CLASS) ile olur. O da her metot çağrısında yeni sepet verir, ki bu da yanlıştır."}],"explanationHtml":"

CheckoutService singleton olduğu için prototype sepet bir kez enjekte edilir ve herkes aynı sepeti paylaşır; ArrayList de thread-safe değil. Prototype her enjeksiyonda yeni nesne demektir, her çağrıda değil. Kısa ömürlü bean gerekiyorsa ObjectProvider veya scoped proxy kullanırım. Ama sepet bir bean değil, kullanıcı verisidir: Redis veya DB'de tutar, servisleri stateless bırakırım.

","links":[{"title":"Bean Scopes","url":"https://docs.spring.io/spring-framework/reference/core/beans/factory-scopes.html"},{"title":"Quick Guide to Spring Bean Scopes","url":"https://www.baeldung.com/spring-bean-scopes"}]},{"kind":"mcq","id":"j-j22","category":"Spring","label":"Java & Spring temelleri · Spring · Bean lifecycle & AOP","bodyHtml":"

Bean yaşam döngüsü ve proxy'nin doğduğu an

Uygulama açılırken ürün kataloğunu belleğe yüklemek isteniyor. İlk deneme şöyle:

@Service\npublic class CatalogWarmup {\n\n    @PostConstruct\n    public void init() {\n        loadAll();\n    }\n\n    @Transactional(readOnly = true)\n    public void loadAll() {\n        productRepository.findAll().forEach(cache::put);\n    }\n}

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Sıra: constructor → bağımlılık enjeksiyonu → BeanPostProcessor (before) → @PostConstruct → BeanPostProcessor (after; AOP proxy burada oluşur) → kullanım → @PreDestroy.","whyHtml":"Doğru. @Transactional, @Async ve @Cacheable proxy'leri postProcessAfterInitialization aşamasında oluşturulur."},{"id":"b","ok":true,"html":"init() içindeki loadAll() çağrısında @Transactional devreye girmez.","whyHtml":"Doğru. Çağrı this üzerinden yapılıyor (self-invocation) ve proxy henüz oluşmamış bile. Lazy ilişkiler LazyInitializationException verebilir."},{"id":"c","ok":true,"html":"Açılış sonrası iş için ApplicationReadyEvent dinlemek ya da ApplicationRunner kullanmak ve işi başka bir bean'in transactional metoduna yaptırmak uygundur.","whyHtml":"Doğru. Context tamamen hazırdır, proxy'ler oluşmuştur, çağrı proxy'den geçer."},{"id":"d","ok":false,"html":"Spring, prototype bean'ler için de @PreDestroy metodunu otomatik çağırır.","whyHtml":"Yanlış. Spring prototype bean'leri oluşturup teslim eder, ama yaşam döngüsünün sonunu yönetmez. Temizlik çağıranın sorumluluğundadır."},{"id":"e","ok":false,"html":"BeanFactoryPostProcessor, bean örnekleri oluşturulduktan sonra onları değiştirmek için kullanılır.","whyHtml":"Yanlış. BeanFactoryPostProcessor bean tanımları (metadata) üzerinde, örnekler oluşmadan çalışır (ör. property placeholder çözümü). Örnekleri işleyen BeanPostProcessor'dır."},{"id":"f","ok":true,"html":"Constructor injection ile döngüsel bağımlılık (A→B→A) Spring Boot 2.6+ varsayılanında açılışta hata verir.","whyHtml":"Doğru. spring.main.allow-circular-references varsayılan olarak false. Döngü genelde tasarım hatasıdır; sorumluluk ayrıştırılır ya da event kullanılır."}],"explanationHtml":"

Yaşam döngüsü: constructor, enjeksiyon, BeanPostProcessor before, PostConstruct, BeanPostProcessor after; AOP proxy'leri bu son adımda oluşur. Bu yüzden PostConstruct içinden this.loadAll() çağırınca @Transactional çalışmaz. Warm-up'ı ApplicationReadyEvent dinleyicisinden ayrı bir bean'in transactional metoduyla yaparım ve bitene kadar readiness'ı kapalı tutarım. Prototype'lar için PreDestroy çağrılmaz; döngüsel bağımlılık Boot 2.6+ ile açılışta hata verir.

","links":[{"title":"Customizing the Nature of a Bean (lifecycle callbacks)","url":"https://docs.spring.io/spring-framework/reference/core/beans/factory-nature.html"},{"title":"Spring Transaction Management: @Transactional In-Depth","url":"https://www.marcobehler.com/guides/spring-transaction-management-transactional-in-depth"}]},{"kind":"open","id":"j-j23","category":"Spring","label":"Java & Spring temelleri · Spring Boot vs Spring Framework","bodyHtml":"

Junior soruyor: Spring Boot ile Spring Framework farkı ne?

Ekibe yeni katılan bir geliştirici soruyor: \"Spring Boot, Spring'in yerine mi geçti? Boot olmasaydı aynı REST + PostgreSQL servisini nasıl kurardık?\"

Mülakatta anlatır gibi açıkla: Framework neyi sağlar, Boot neyi ekler, @SpringBootApplication neyin kısaltmasıdır, Boot olmadan neleri elle yapardık?

","answers":{},"modelAnswerHtml":"$1d","rubric":["Framework çekirdek özellikleri sağlar: IoC/DI, AOP, MVC, transaction yönetimi, data access","Boot, Framework'ün üzerine kurulu opinionated bir katmandır, yerine geçmez","Auto-configuration (classpath'e ve koşullara göre bean'ler)","Starter'lar ve uyumlu sürüm yönetimi (BOM / dependency management)","Embedded server ve çalıştırılabilir fat jar (WAR deploy gerekmez)","Externalized configuration (application.yml, profiles), Actuator","@SpringBootApplication = @Configuration (@SpringBootConfiguration) + @EnableAutoConfiguration + @ComponentScan"]},{"kind":"mcq","id":"j-j24","category":"Spring","label":"Java & Spring temelleri · Spring Boot · Configuration","bodyHtml":"

Konfigürasyon: hangi değer kazanır?

Sipariş servisinin application.yml'ında server.port: 8080 ve spring.datasource.url var. Production'da prod profili aktif ve servis Kubernetes'te ortam değişkenleriyle çalışıyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Komut satırı argümanı (--server.port=9090), application.yml'deki değeri ezer.","whyHtml":"Doğru. Komut satırı argümanları, property kaynakları arasında en yüksek önceliklilerdendir (test property'leri hariç)."},{"id":"b","ok":true,"html":"SPRING_DATASOURCE_URL ortam değişkeni, relaxed binding ile spring.datasource.url'e bağlanır ve dosyadaki değeri ezer.","whyHtml":"Doğru. Kubernetes'te Secret'tan gelen env değişkenleriyle konfigürasyon bu şekilde verilir."},{"id":"c","ok":true,"html":"application-prod.yml, aynı anahtar için application.yml'deki değeri ezer.","whyHtml":"Doğru. Profile özel dosyalar genel dosyanın üzerine uygulanır."},{"id":"d","ok":false,"html":"Tipli, doğrulanabilir ve gruplu konfigürasyon için @Value, @ConfigurationProperties'ten daha uygundur.","whyHtml":"Yanlış. @ConfigurationProperties (record ile immutable) tip güvenliği, @Validated ile doğrulama, IDE metadata'sı ve relaxed binding verir. @Value tekil değerler içindir."},{"id":"e","ok":false,"html":"Veritabanı şifresini application.yml'e yazıp git'e commit etmek, repo private ise kabul edilebilir.","whyHtml":"Yanlış. Git geçmişi kalıcıdır ve erişim genişler. Secret'lar Kubernetes Secret / Vault / AWS Secrets Manager'dan env veya config tree olarak gelmelidir."},{"id":"f","ok":true,"html":"@Profile(\"!prod\") ile işaretlenen bean, prod dışındaki tüm profillerde aktif olur.","whyHtml":"Doğru. Profile ifadeleri !, &, | destekler. Örneğin sahte bir ödeme gateway'ini sadece lokal ve test ortamında açmak için."}],"explanationHtml":"

Komut satırı ve env değişkenleri dosyadaki değeri ezer; profile özel dosya genel dosyayı ezer. SPRING_DATASOURCE_URL relaxed binding ile bağlanır. Tipli ve doğrulanan ayarlar için @ConfigurationProperties'i record olarak kullanırım. Secret'ları asla yml'e yazmam; Kubernetes Secret veya Vault'tan env olarak alırım. Aynı imaj her ortamda çalışır, sadece konfigürasyon değişir.

","links":[{"title":"Externalized Configuration","url":"https://docs.spring.io/spring-boot/reference/features/external-config.html"}]},{"kind":"open","id":"j-j25","category":"Veri","label":"Java & Spring temelleri · SQL · Join, Group By, Window","bodyHtml":"

CRM ekibi iki rapor istiyor

Tablolar (PostgreSQL):

customers   (id, name, created_at)\norders      (id, customer_id, status, created_at)        -- status: 'DELIVERED', 'CANCELLED', ...\norder_items (order_id, product_id, category, quantity, unit_price)

A) \"Geri kazanım\" kampanyası: Toplamda en az 3 teslim edilmiş siparişi olan ama son 30 günde hiç teslim edilmiş siparişi olmayan müşteriler (id, ad, sipariş sayısı, son sipariş tarihi).

B) Son 90 günde teslim edilen siparişlere göre her kategoride ciroya göre en çok satan 3 ürün.

","answers":{},"modelAnswerHtml":"$1e","rubric":["A: orders ile JOIN ve DELIVERED filtresi","A: GROUP BY müşteri + HAVING count >= 3","A: son 30 gün koşulu (HAVING max(created_at) < now() - 30 gün ya da NOT EXISTS)","B: ürün bazında ciro: sum(quantity * unit_price), son 90 gün","B: window function: ROW_NUMBER / RANK / DENSE_RANK OVER (PARTITION BY category ORDER BY ... DESC)","B: window sonucunu dış sorguda / CTE'de filtrelemek (WHERE'de doğrudan kullanılamaz)"]},{"kind":"mcq","id":"j-j26","category":"Veri","label":"Java & Spring temelleri · DB · ACID, izolasyon, normalizasyon","bodyHtml":"

ACID, anomaliler ve normal formlar

Yeni bir iade (return) modülünün veri modeli tasarlanıyor. Ekip tutarlılık garantilerini ve tablo yapısını tartışıyor.

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"Atomicity: bir transaction'daki işlemlerin ya hepsi uygulanır ya hiçbiri.","whyHtml":"Doğru. İade kaydı yazılıp stok artırılamazsa iade kaydı da geri alınır."},{"id":"b","ok":true,"html":"Durability: commit edilen veri, hemen ardından sunucu çökse bile kaybolmaz; PostgreSQL bunu WAL (write-ahead log) ile sağlar.","whyHtml":"Doğru. Commit, WAL diske yazıldığında (fsync) döner."},{"id":"c","ok":true,"html":"PostgreSQL'de READ UNCOMMITTED seçilse bile dirty read oluşmaz.","whyHtml":"Doğru. PostgreSQL READ UNCOMMITTED'ı READ COMMITTED gibi uygular; MVCC commit edilmemiş sürümleri göstermez."},{"id":"d","ok":true,"html":"Phantom read: aynı WHERE koşuluyla tekrar sorgulandığında başka bir transaction'ın eklediği yeni satırların görünmesidir.","whyHtml":"Doğru. Non-repeatable read ise aynı satırın değerinin değişmesidir."},{"id":"e","ok":true,"html":"3NF: anahtar olmayan her kolon sadece anahtara bağlı olmalı; başka bir anahtar olmayan kolon üzerinden geçişli bağımlılık olmamalı.","whyHtml":"Doğru. Örn. returns tablosunda customer_id ile birlikte customer_email tutmak geçişli bağımlılıktır (email müşteriye bağlı)."},{"id":"f","ok":false,"html":"Denormalizasyon her durumda kötü bir tasarımdır ve kaçınılmalıdır.","whyHtml":"Yanlış. Okuma ağırlıklı sistemlerde bilinçli denormalizasyon (read model, sipariş anındaki fiyatın siparişe kopyalanması) doğru tercihtir. Bedeli tutarlılığı yönetmektir."},{"id":"g","ok":false,"html":"Index eklemek her zaman sorguları hızlandırır ve yazma performansını etkilemez.","whyHtml":"Yanlış. Her index her INSERT/UPDATE/DELETE'de güncellenir, disk ve bellek tüketir. Düşük seçicilikli sorgularda planner index'i zaten kullanmaz."}],"explanationHtml":"

ACID: hep ya da hiç, constraint'lerin korunması, izolasyon ve WAL ile kalıcılık. PostgreSQL varsayılan olarak READ COMMITTED'dır, dirty read hiç yoktur; REPEATABLE READ snapshot ile phantom'u da önler. Tabloları 3NF'e kadar normalize ederim, ama sipariş anındaki fiyat gibi tarihsel verileri ve read model'leri bilinçli olarak denormalize ederim. Index'in yazma maliyetini de hesaba katarım.

","links":[{"title":"Learn Database Normalization - 1NF, 2NF, 3NF, 4NF, 5NF","url":"https://www.youtube.com/watch?v=GFQaEYEc8_8"},{"title":"Transactions: myths, surprises and opportunities","url":"https://www.youtube.com/watch?v=5ZjhNTM8XU8"},{"title":"Transaction Isolation","url":"https://www.postgresql.org/docs/current/transaction-iso.html"}]},{"kind":"open","id":"j-j27","category":"Veri","label":"Java & Spring temelleri · PostgreSQL · Index neden kullanılmıyor?","bodyHtml":"$1f","answers":{},"modelAnswerHtml":"$20","rubric":["(1) Kolona fonksiyon uygulanmış; expression index ON customers (lower(email)) ya da citext","(2) date() fonksiyonu sargable değil; aralık sorgusuna çevir (>= gün AND < ertesi gün)","(3) Baştaki % ile B-tree kullanılamaz; pg_trgm GIN index, full-text search ya da Elasticsearch","(4) Düşük seçicilik (%97): Seq Scan doğru tercih; planner haklı","(5) Composite index'te leftmost prefix: created_at ikinci kolon; created_at'li index (veya kolon sırası) gerekli. Mevcut orders(created_at) index'i de kullanılabilir.","Doğrulama: EXPLAIN (ANALYZE, BUFFERS), güncel istatistikler (ANALYZE)"]},{"kind":"mcq","id":"j-j28","category":"Veri","label":"Java & Spring temelleri · CAP · PACELC · BASE","bodyHtml":"

CAP teoremi ve gerçek sistemler

Ürün verisi PostgreSQL'de (birincil + async replica), arama Elasticsearch'te (Kafka ile güncelleniyor), sepet Redis Cluster'da tutuluyor. Mülakatçı soruyor: \"Bu sistem CP mi, AP mi?\"

Hangi ifadeler doğru?

","multi":true,"options":[{"id":"a","ok":true,"html":"CAP: Ağ bölünmesi (partition) olduğunda dağıtık bir sistem, tutarlılık (her okuma en son yazmayı görür) ile erişilebilirlik (her istek cevap alır) arasında seçim yapmak zorundadır.","whyHtml":"Doğru. Partition kaçınılmaz olduğu için asıl seçim, partition sırasında C mi A mı sorusudur."},{"id":"b","ok":false,"html":"\"CA\" bir sistem, dağıtık bir sistem için gerçekçi ve yaygın bir seçimdir.","whyHtml":"Yanlış. Ağ üzerinden haberleşen bir sistemde partition'dan kaçınamazsın; P bir seçim değil, bir gerçek. CA ancak tek node'lu bir sistem için anlamlıdır."},{"id":"c","ok":true,"html":"PACELC: Partition varsa A ile C arasında, yoksa (Else) Latency ile Consistency arasında seçim yapılır.","whyHtml":"Doğru. Normal çalışmada bile senkron replikasyon tutarlılık verir ama gecikme ekler; async replikasyon hızlıdır ama bayat okuma riski taşır."},{"id":"d","ok":true,"html":"BASE: Basically Available, Soft state, Eventually consistent. Birçok NoSQL ve event-driven mimarinin yaklaşımıdır.","whyHtml":"Doğru. ACID'in karşısında konumlanır: tutarlılık anında değil, zamanla sağlanır."},{"id":"e","ok":true,"html":"Kafka ile beslenen Elasticsearch arama modeli eventual consistency örneğidir: ürün güncellendikten hemen sonra aramada eski hali görünebilir.","whyHtml":"Doğru. Bu yüzden ürün detayı birincil kaynaktan okunur; arama sonucu kısa süre bayat kalabilir."},{"id":"f","ok":false,"html":"CAP'teki \"Consistency\" ile ACID'deki \"Consistency\" aynı kavramdır.","whyHtml":"Yanlış. CAP'teki C, linearizability'dir (tüm node'ların tek kopya gibi davranması). ACID'deki C, constraint ve invariant'ların korunmasıdır."},{"id":"g","ok":true,"html":"Async replica'dan okuma yapan bir servis, kullanıcının az önce yazdığı veriyi göremeyebilir (read-your-writes ihlali). Kritik okumalar birincil node'a yönlendirilir.","whyHtml":"Doğru. Replication lag yüzünden. Örneğin sipariş verdikten hemen sonra \"siparişlerim\" sayfası primary'den okunur."}],"explanationHtml":"

CAP, partition sırasında tutarlılık ile erişilebilirlik arasında seçim yapmaktır; partition kaçınılmaz olduğu için CA dağıtık sistemde anlamsızdır. PACELC normal çalışmada da gecikme ile tutarlılık arasında seçim olduğunu söyler. Sistemleri tek bir etiketle değil, işlem bazında değerlendiririm: stok ve ödeme tutarlı ve primary'den, arama ve listeleme eventually consistent. Async replica'larda read-your-writes için kritik okumaları primary'ye yönlendiririm.

","links":[{"title":"CAP Theorem & PACELC in Distributed System","url":"https://www.youtube.com/watch?v=BaKtC-VIYrM"},{"title":"Please stop calling databases CP or AP","url":"https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html"},{"title":"Consistency and Partition Tolerance: Understanding CAP vs PACELC","url":"https://blog.bytebytego.com/p/consistency-and-partition-tolerance"},{"title":"The System Design Primer","url":"https://github.com/donnemartin/system-design-primer"}]},{"kind":"mcq","id":"lc-z1","category":"Zanaat","label":"Live coding hızlı quiz · REST · Status kodları","bodyHtml":"Yeni bir sipariş POST /api/v1/orders ile başarıyla oluşturuldu. En doğru cevap hangisi?","multi":false,"options":[{"id":"a","ok":false,"html":"200 OK + sipariş gövdesi","whyHtml":"Çalışır ama semantik olarak eksik; yeni bir kaynak oluştuğunu söylemez."},{"id":"b","ok":true,"html":"201 Created + Location: /api/v1/orders/{id} + (opsiyonel) gövde","whyHtml":"Doğru. Spring: ResponseEntity.created(uri).body(dto)."},{"id":"c","ok":false,"html":"202 Accepted","whyHtml":"İşlem asenkron kuyruğa alındıysa ve henüz tamamlanmadıysa kullanılır."},{"id":"d","ok":false,"html":"204 No Content","whyHtml":"Gövdesiz başarılı cevap; genelde DELETE ve bazı PUT'lar için."}],"explanationHtml":"Hızlı tablo: 200 OK · 201 Created · 202 Accepted · 204 No Content · 400 Bad Request (sözdizimi/validasyon) · 401 kimlik yok · 403 yetki yok · 404 yok · 409 Conflict (çakışma, duplicate) · 422 Unprocessable (iş kuralı) · 429 Too Many Requests · 500 sunucu hatası · 502 upstream hatası · 503 geçici olarak hizmet yok · 504 upstream timeout.","links":[]},{"kind":"mcq","id":"lc-z2","category":"Dağıtık Sistemler","label":"Live coding hızlı quiz · HTTP · Idempotency","bodyHtml":"Hangi HTTP metotları idempotenttir (aynı isteği N kez göndermek, 1 kez göndermekle aynı sonuç durumunu üretir)?","multi":true,"options":[{"id":"a","ok":true,"html":"GET","whyHtml":"Güvenli ve idempotent; durumu değiştirmez."},{"id":"b","ok":true,"html":"PUT","whyHtml":"Kaynağı verilen hale getirir; tekrarı aynı sonucu verir."},{"id":"c","ok":true,"html":"DELETE","whyHtml":"İkinci çağrıda 404 dönebilir ama sunucu durumu aynıdır."},{"id":"d","ok":false,"html":"POST","whyHtml":"Her çağrı yeni kaynak oluşturabilir. Idempotency-Key ile idempotent hale getirilir."},{"id":"e","ok":false,"html":"PATCH","whyHtml":"Garanti değil: \"stoğu 1 azalt\" gibi göreli bir patch idempotent değildir."}],"explanationHtml":"Retry yapan istemciler (mobil, gateway, Kafka consumer) için kritik bir konu. Ödeme ve sipariş gibi POST'larda istemci bir Idempotency-Key üretir, sunucu bu key'i unique olarak saklar ve tekrar gelen isteğe ilk cevabı döner.","links":[]},{"kind":"mcq","id":"lc-z3","category":"Zanaat","label":"Live coding hızlı quiz · REST · İsimlendirme","bodyHtml":"Bir ürünün yorumlarını sayfalı getiren endpoint için en iyi tasarım hangisi?","multi":false,"options":[{"id":"a","ok":false,"html":"GET /getProductReviews?id=5","whyHtml":"URL'de fiil var, versiyon yok, kaynak hiyerarşisi yok."},{"id":"b","ok":true,"html":"GET /api/v1/products/5/reviews?page=0&size=20&sort=createdAt,desc","whyHtml":"Doğru. Çoğul isimler, hiyerarşik kaynak, versiyon, sayfalama ve sıralama query parametresinde."},{"id":"c","ok":false,"html":"POST /api/v1/reviews/search gövdede {productId: 5}","whyHtml":"Karmaşık arama kriterleri için bazen kabul edilir, ama basit bir listeleme için GET doğru; cache'lenebilir ve paylaşılabilir."},{"id":"d","ok":false,"html":"GET /api/v1/product/5/review/list","whyHtml":"Tekil isim ve \"list\" fiili REST kalıplarına uymaz."}],"explanationHtml":"Kurallar: Kaynaklar çoğul isimdir, aksiyonu HTTP metodu anlatır, URL'ler küçük harf ve kebab-case olur (/shipping-fee), versiyon /api/v1, filtre ve sayfalama query parametresinde. Kaynağa uymayan aksiyonlar için alt kaynak kullanılır: POST /api/v1/orders/42/cancellation.","links":[]},{"kind":"mcq","id":"lc-z4","category":"Spring","label":"Live coding hızlı quiz · Spring · Validation","bodyHtml":"İstek DTO'sunda @NotEmpty List<ItemRequest> items var; ItemRequest içinde @Positive int quantity tanımlı. Controller'da @Valid @RequestBody kullanılıyor, ama quantity: -3 olan istek geçiyor. Neden?","multi":false,"options":[{"id":"a","ok":false,"html":"@Positive int'lerde çalışmaz; Integer olmalı.","whyHtml":"@Positive primitive int'lerde de çalışır."},{"id":"b","ok":true,"html":"Liste elemanlarının doğrulanması için kaskad gerekir: List<@Valid ItemRequest> (ya da alanın üstüne @Valid).","whyHtml":"Doğru. Bean Validation iç içe nesnelere varsayılan olarak inmez."},{"id":"c","ok":false,"html":"spring-boot-starter-validation olmadan @NotEmpty de çalışmaz, yani hiçbir validasyon çalışmıyor.","whyHtml":"Starter eksikse tüm validasyon çalışmaz; ama soru @NotEmpty'nin çalıştığını varsayıyor."},{"id":"d","ok":false,"html":"@Valid yerine @Validated yazılmalı.","whyHtml":"@Validated grup desteği ve method validation içindir; kaskad problemi aynıdır."}],"explanationHtml":"Validasyon hatası MethodArgumentNotValidException fırlatır. @RestControllerAdvice'ta yakalanıp alan bazlı hata listesiyle 400 dönülür. Path ve query parametrelerinin validasyonu için controller'a @Validated eklenir.","links":[]},{"kind":"mcq","id":"lc-z5","category":"Zanaat","label":"Live coding hızlı quiz · Test · Mockito","bodyHtml":"void reserve(long productId, int qty) metodunun bir mock'ta exception fırlatmasını istiyorsun. Doğru yazım hangisi?","multi":false,"options":[{"id":"a","ok":false,"html":"when(stock.reserve(1L, 2)).thenThrow(new InsufficientStockException())","whyHtml":"Derlenmez: void bir metot when(...) içine argüman olarak verilemez."},{"id":"b","ok":true,"html":"doThrow(new InsufficientStockException()).when(stock).reserve(1L, 2)","whyHtml":"Doğru. void metotlar için do* ailesi kullanılır: doThrow, doNothing, doAnswer."},{"id":"c","ok":false,"html":"given(stock.reserve(1L, 2)).willThrow(...)","whyHtml":"BDD stili de aynı sebeple void metotta derlenmez. Doğrusu: willThrow(...).given(stock).reserve(1L, 2)."},{"id":"d","ok":false,"html":"verify(stock).reserve(1L, 2).thenThrow(...)","whyHtml":"verify davranış tanımlamaz, çağrıyı doğrular."}],"explanationHtml":"Mockito özeti: when(...).thenReturn (dönüş değeri olan metotlar), doThrow().when() (void), verify(mock, times(1)).m(), verify(mock, never()), verifyNoInteractions, ArgumentCaptor, any()/eq() (karıştırma kuralı: bir argümanda matcher kullanırsan hepsinde kullan).","links":[]},{"kind":"mcq","id":"lc-z6","category":"Zanaat","label":"Live coding hızlı quiz · Test · İyi pratikler","bodyHtml":"Live coding'de yazacağın testler için hangileri iyi pratiktir?","multi":true,"options":[{"id":"a","ok":true,"html":"Her test tek bir davranışı doğrular ve adı o davranışı anlatır (rejectsUnknownCarrier).","whyHtml":"Test fail ettiğinde ismi neyin bozulduğunu söyler."},{"id":"b","ok":true,"html":"Arrange-Act-Assert (given-when-then) yapısı.","whyHtml":"Okunurluk."},{"id":"c","ok":false,"html":"Asenkron sonucu beklemek için Thread.sleep(2000).","whyHtml":"Yavaş ve kırılgan (flaky). Awaitility ile koşullu bekleme kullanılır."},{"id":"d","ok":false,"html":"Testlerin belirli bir sırayla çalışmasına güvenmek.","whyHtml":"Her test bağımsız olmalı; sıra garanti edilmez."},{"id":"e","ok":true,"html":"Sınır değerleri test etmek (eşik değerin tam kendisi, bir altı, bir üstü).","whyHtml":"Off-by-one hatalarını yakalar."},{"id":"f","ok":false,"html":"Sadece mutlu yolu test etmek; hata durumları zaman kaybıdır.","whyHtml":"Hata durumları ve kenar durumlar en çok bug çıkan yerlerdir."}],"explanationHtml":"Zaman kısıtlıysa mülakatçıya söyle: \"Önce en riskli davranışın testini yazıyorum; zaman kalırsa şu senaryoları da eklerim.\" Test listesi çıkarmak bile puan getirir.","links":[]},{"kind":"mcq","id":"lc-z7","category":"Zanaat","label":"Live coding hızlı quiz · Design pattern","bodyHtml":"Ödeme sağlayıcısı (Iyzico, PayTR, Papara) çalışma anında istek parametresine göre seçilecek. Her birinin authorize/refund mantığı farklı ama sözleşmesi aynı. En uygun pattern hangisi?","multi":false,"options":[{"id":"a","ok":true,"html":"Strategy (+ Spring'in List/Map enjeksiyonuyla bir registry)","whyHtml":"Doğru. Aynı arayüzü uygulayan değiştirilebilir algoritmalar, çalışma anında seçim."},{"id":"b","ok":false,"html":"Singleton","whyHtml":"Nesne sayısını kısıtlar; seçim problemini çözmez. Spring bean'leri zaten singleton."},{"id":"c","ok":false,"html":"Observer","whyHtml":"Bir olaya birden çok dinleyicinin tepki vermesi içindir."},{"id":"d","ok":false,"html":"Builder","whyHtml":"Karmaşık nesne kurulumu içindir."}],"explanationHtml":"Sık karıştırılanlar: Strategy (davranış seçimi), Factory (nesne oluşturmayı soyutlama; registry'den seçmek bazen \"factory\" diye de adlandırılır), Template Method (sabit akış, değişen adımlar: abstract class), Decorator (davranışı sarma: loglama, retry), Adapter (farklı bir API'yi kendi arayüzüne uydurma: her ödeme sağlayıcısının mapping'i aslında bir adapter'dır).","links":[]},{"kind":"mcq","id":"lc-z8","category":"Zanaat","label":"Live coding hızlı quiz · SOLID","bodyHtml":"\"Her yeni kargo firması eklendiğinde ShippingService.calculate metoduna yeni bir else if ekliyoruz.\" Bu, en doğrudan hangi ilkenin ihlalidir?","multi":false,"options":[{"id":"a","ok":false,"html":"Liskov Substitution","whyHtml":"Alt tiplerin üst tipin yerine kullanılabilmesiyle ilgilidir."},{"id":"b","ok":true,"html":"Open/Closed","whyHtml":"Doğru. Yeni davranış eklemek için mevcut, test edilmiş kodu değiştiriyoruz."},{"id":"c","ok":false,"html":"Interface Segregation","whyHtml":"Şişman arayüzlerle ilgilidir."},{"id":"d","ok":false,"html":"Dependency Inversion","whyHtml":"Üst katmanın somut sınıfa bağımlı olmasıyla ilgilidir. Kısmen ilgili ama asıl ihlal OCP."}],"explanationHtml":"Aynı metot birden fazla firmanın kuralını bildiği için SRP de zayıftır. Mülakatta ilkeyi adıyla söyleyip neden önemli olduğunu bir cümleyle açıkla: \"Her eklemede test edilmiş kodu değiştirmek regresyon riski ve merge conflict yaratır.\"","links":[]},{"kind":"mcq","id":"lc-z9","category":"Spring","label":"Live coding hızlı quiz · Spring · Katmanlar","bodyHtml":"@Transactional en doğru hangi katmanda kullanılır?","multi":false,"options":[{"id":"a","ok":false,"html":"Controller metodunda; istek boyunca transaction açık kalsın.","whyHtml":"Connection HTTP isteği boyunca tutulur, transaction sınırı web katmanına sızar."},{"id":"b","ok":true,"html":"Servis katmanındaki public, bir iş akışını (use case) temsil eden metotta.","whyHtml":"Doğru. Transaction sınırı = iş akışının atomiklik sınırı."},{"id":"c","ok":false,"html":"Her repository metodunda ayrı ayrı.","whyHtml":"Spring Data zaten her metodu kendi transaction'ında çalıştırır; ama birden fazla yazmayı atomik yapmak için servis seviyesinde sınır gerekir."},{"id":"d","ok":false,"html":"Entity sınıfında.","whyHtml":"Entity'ler Spring bean'i değildir; anlamı yok."}],"explanationHtml":"Transaction içinde harici HTTP çağrısı yapma: connection'ı boşuna tutar ve dış sistem rollback edilemez. Okuma metotlarında @Transactional(readOnly = true) kullan.","links":[]},{"kind":"mcq","id":"lc-z10","category":"Spring","label":"Live coding hızlı quiz · Spring · Hata yönetimi","bodyHtml":"Bir projenin her controller metodunda try { ... } catch (Exception e) { return ResponseEntity.status(500).body(\"error\"); } var. En iyi düzeltme hangisi?","multi":false,"options":[{"id":"a","ok":false,"html":"catch'e e.printStackTrace() eklemek.","whyHtml":"Hâlâ her şey 500, istemci hiçbir şey öğrenmez, log yapılandırılmamış."},{"id":"b","ok":true,"html":"try/catch'leri kaldırıp domain exception'ları + @RestControllerAdvice içinde @ExceptionHandler'lar ile merkezi olarak doğru status'a (ProblemDetail) çevirmek.","whyHtml":"Doğru. Tek yer, tutarlı format, doğru status kodları, beklenmeyen hatalar loglanır."},{"id":"c","ok":false,"html":"Her controller'da exception tipine göre ayrı catch blokları yazmak.","whyHtml":"Tekrar eden kod; tutarsızlık riski."},{"id":"d","ok":false,"html":"Exception'ları servis katmanında yakalayıp null dönmek.","whyHtml":"Hata bilgisi kaybolur, NPE'ye davetiye."}],"explanationHtml":"Hiyerarşi önerisi: BusinessException(errorCode, status) → NotFoundException, ConflictException, ValidationException. Handler: BusinessException → kendi status'u; MethodArgumentNotValidException → 400 + alan hataları; Exception → 500 + log (detay istemciye değil log'a).","links":[]},{"kind":"mcq","id":"lc-z11","category":"Zanaat","label":"Live coding hızlı quiz · Git · Commit","bodyHtml":"Live coding sırasında commit atıyorsun. Hangileri iyi pratiktir?","multi":true,"options":[{"id":"a","ok":true,"html":"fix: reject unknown carrier instead of returning zero fee","whyHtml":"Ne ve neden net; Conventional Commits formatında."},{"id":"b","ok":false,"html":"changes / WIP / fix","whyHtml":"Hiçbir bilgi vermez."},{"id":"c","ok":true,"html":"Refactor (davranış değişmez) ve davranış değişikliğini ayrı commit'lerde yapmak.","whyHtml":"Review kolaylaşır, gerekirse tek tek geri alınır."},{"id":"d","ok":true,"html":"Her commit'te testlerin geçiyor olması.","whyHtml":"Geçmişte her nokta çalışır durumda olur; git bisect kullanılabilir."},{"id":"e","ok":false,"html":"Tüm görevleri bitirip sonda tek büyük commit atmak.","whyHtml":"İlerlemeni gösteremezsin, review zorlaşır."}],"explanationHtml":"Conventional Commits: feat:, fix:, refactor:, test:, docs:, chore:, build:, ci:, perf:. Mesajın gövdesinde \"neden\" yazılır; \"ne\" diff'te zaten görünür.","links":[]},{"kind":"mcq","id":"lc-z12","category":"Spring","label":"Live coding hızlı quiz · Spring · HTTP client'lar","bodyHtml":"Harici servis çağrıları için hangi ifadeler doğru?","multi":true,"options":[{"id":"a","ok":true,"html":"RestClient Spring Framework 6.1 / Boot 3.2 ile gelen senkron ve akıcı (fluent) API'dir; yeni kodda RestTemplate yerine önerilir.","whyHtml":"Doğru. RestTemplate bakım modunda."},{"id":"b","ok":true,"html":"WebClient reactive ve non-blocking'dir; WebFlux bağımlılığı getirir.","whyHtml":"Doğru. Bloklayan bir Spring MVC uygulamasında sadece HTTP client olarak kullanmak çoğu zaman gereksiz karmaşıklıktır."},{"id":"c","ok":true,"html":"new RestTemplate() varsayılan olarak sınırsız bekler (connect/read timeout tanımlı değildir); timeout bilinçli olarak ayarlanmalıdır.","whyHtml":"Doğru. Yavaş bir sağlayıcı tüm thread'leri tüketebilir."},{"id":"d","ok":true,"html":"OpenFeign deklaratif bir client sunar; Spring Cloud sürümünün Spring Boot sürümüyle uyumlu olması gerekir.","whyHtml":"Doğru. Bir aday, eski Spring sürümünde Feign eklemekte zorlandığını anlatıyor."},{"id":"e","ok":false,"html":"HTTP client'ları her çağrıda new ile oluşturmak en güvenli yoldur.","whyHtml":"Yanlış. Connection pool'u ve konfigürasyonu paylaşmak için tek bir yapılandırılmış bean (ya da builder) kullanılır."}],"explanationHtml":"Mülakatta \"dış çağrı\" gördüğün her yerde şu dört kelimeyi düşün: timeout, retry (sadece idempotent işlemde), circuit breaker, idempotency key.","links":[]},{"kind":"mcq","id":"lc-z13","category":"Zanaat","label":"Live coding hızlı quiz · Live coding davranışı","bodyHtml":"Live coding başladı, sana bir proje ve 6 maddelik bir görev listesi verildi. İlk 10 dakikada en iyi yaklaşım hangisi?","multi":false,"options":[{"id":"a","ok":false,"html":"Zaman kaybetmemek için hemen ilk maddeyi kodlamaya başlamak.","whyHtml":"Projeyi anlamadan yazılan kod genelde geri alınır. Mülakatçı da soru sorup sormadığına bakar."},{"id":"b","ok":true,"html":"Projeyi build edip testleri çalıştırmak, yapıyı hızlıca gezmek, belirsizlikleri sormak, görevleri önceliklendirip planı sesli söylemek.","whyHtml":"Doğru. \"Önce şunları yapacağım, şu sırayla; uygun mu?\" cümlesi hem iletişim hem önceliklendirme becerisini gösterir."},{"id":"c","ok":false,"html":"Önce tüm projeyi kendi beğendiğin yapıya göre yeniden düzenlemek.","whyHtml":"Görev dışı ve riskli. Kapsamı mülakatçıyla birlikte belirle."},{"id":"d","ok":false,"html":"Sessizce okuyup tam bir plan çıkana kadar konuşmamak.","whyHtml":"Mülakatçı ne düşündüğünü göremez. Sesli düşünmek beklenir."}],"explanationHtml":"Adayların ortak tavsiyesi: \"Sesli düşünerek, neyi neden yazdığınızı kısaca açıklarsanız görüşmenize artı puan gelir.\" Çoğu zaman listedeki her şeyi bitirmen beklenmez; doğru önceliklendirme ve yaklaşım değerlendirilir.","links":[]},{"kind":"mcq","id":"lc-z14","category":"Zanaat","label":"Live coding hızlı quiz · REST · Çakışma","bodyHtml":"Kayıt endpoint'ine, sistemde zaten kayıtlı bir e-posta ile istek geldi. Hangi status kodu en uygun?","multi":false,"options":[{"id":"a","ok":false,"html":"400 Bad Request","whyHtml":"İstek sözdizimi olarak geçerli; sorun mevcut durumla çakışması."},{"id":"b","ok":false,"html":"404 Not Found","whyHtml":"İlgisiz."},{"id":"c","ok":true,"html":"409 Conflict","whyHtml":"Doğru. İstek, kaynağın mevcut durumuyla çakışıyor (unique constraint)."},{"id":"d","ok":false,"html":"500 Internal Server Error","whyHtml":"DB'nin unique violation'ını yakalamadan 500'e düşürmek klasik bir hata."}],"explanationHtml":"DataIntegrityViolationException'ı yakalayıp 409'a çevirmek, \"önce var mı diye bak, sonra ekle\" yarışını DB constraint'iyle güvenli kapatmanın HTTP tarafıdır.","links":[]},{"kind":"mcq","id":"sorular/ci-cd#m1","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Aşağıdakilerden hangisi Continuous Integration'ın özünü en iyi anlatır?","multi":false,"options":[{"id":"a","ok":false,"md":"Ekipte bir CI sunucusu (Jenkins, GitHub Actions) kurulu olması","whyMd":"Araç pratiği otomatikleştirir ama tek başına CI yapıldığı anlamına gelmez."},{"id":"b","ok":true,"md":"Geliştiricilerin değişikliklerini sık sık ana dala entegre etmesi ve her commit'in otomatik build ve testten geçmesi","whyMd":"CI, sık entegrasyon ve her değişikliğin otomatik doğrulanması pratiğidir."},{"id":"c","ok":false,"md":"Her özelliğin kendi uzun ömürlü branch'inde tamamlanıp sonra merge edilmesi","whyMd":"Uzun ömürlü branch'ler entegrasyonu sona erteler; CI'ın tersidir."},{"id":"d","ok":false,"md":"Her gece tüm testlerin bir kez koşturulması","whyMd":"Gece build'i geri bildirimi bir güne kadar geciktirir; her commit doğrulanmaz."}],"explanationMd":"CI bir araç değil, sık entegrasyon ve hızlı otomatik geri bildirim alışkanlığıdır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m2","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Continuous delivery ile continuous deployment arasındaki temel fark nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Delivery staging'e kadar, deployment prod'a kadar otomatik deploy eder","whyMd":"Delivery'de de pipeline prod'a kadar uzanır; fark sadece son adımın onaylı olmasıdır."},{"id":"b","ok":true,"md":"Delivery'de prod'a çıkış bir onay ya da karar gerektirir; deployment'ta kontrollerden geçen her değişiklik otomatik prod'a gider","whyMd":"Fark prod'a çıkıştaki manuel onay ya da karardır."},{"id":"c","ok":false,"md":"Delivery sadece JAR üretir, deployment Docker image üretir","whyMd":"Artifact türü bu kavramlarla ilgili değildir."},{"id":"d","ok":false,"md":"İkisi aynı şeyi anlatır, sadece farklı araçların terimidir","whyMd":"İki terim farklı bir otomasyon düzeyini anlatır."}],"explanationMd":"Delivery'de ana dal her an çıkarılabilir durumdadır ve çıkış bir karardır; deployment'ta bu karar otomasyona devredilmiştir.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m3","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"\"Build once, deploy many\" ilkesine göre production'a ne gitmelidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Aynı commit'ten prod için yeniden build edilmiş bir image","whyMd":"Yeniden build aynı binary'yi garanti etmez; bağımlılıklar veya base image değişmiş olabilir."},{"id":"b","ok":false,"md":"Prod profiliyle (`-Pprod`) build edilmiş ayrı bir JAR","whyMd":"Ortama özel build, test edilmemiş bir artifact'ı prod'a gönderir."},{"id":"c","ok":true,"md":"Staging'de test edilmiş image'ın aynısı (aynı digest), prod konfigürasyonuyla","whyMd":"Test edilen artifact prod'a taşınır, ortam farkı sadece konfigürasyondadır."},{"id":"d","ok":false,"md":"Registry'deki `latest` etiketli image","whyMd":"`latest` değişken bir etikettir; hangi image'ın çalıştığı belirsizleşir."}],"explanationMd":"Artifact bir kez üretilir ve ortamlar arasında terfi ettirilir; böylece prod'a giden şey test edilen şeyin ta kendisidir.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m4","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Production deploy'larında image'ı `latest` etiketiyle kullanmanın temel sorunu nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"`latest` etiketli image'lar daha büyük olur","whyMd":"Etiket image boyutunu etkilemez."},{"id":"b","ok":true,"md":"Etiket değişkendir; hangi kodun çalıştığı bilinmez ve rollback için net bir hedef kalmaz","whyMd":"Değişken etiket izlenebilirliği ve tekrarlanabilir rollback'i bozar."},{"id":"c","ok":false,"md":"Registry'ler `latest` etiketini kabul etmez","whyMd":"Registry'ler `latest` etiketini sorunsuz kabul eder; sorun teknik değil süreçseldir."},{"id":"d","ok":false,"md":"`latest` etiketi image taramasını devre dışı bırakır","whyMd":"Tarama etiketle değil image içeriğiyle ilgilidir."}],"explanationMd":"Değişmez etiketler (commit SHA) ve digest, prod'da neyin çalıştığını kesin olarak söyler.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m5","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Maven projesinde `*IT` adlı integration testleri varsayılan olarak hangi plugin çalıştırır?","multi":false,"options":[{"id":"a","ok":false,"md":"maven-surefire-plugin, `test` fazında","whyMd":"Surefire unit testleri `test` fazında koşar; `*IT` sınıfları varsayılan desenlerinde yoktur."},{"id":"b","ok":true,"md":"maven-failsafe-plugin, `integration-test` ve `verify` fazlarında","whyMd":"Failsafe integration testleri koşar ve sonucu `verify` fazında değerlendirir."},{"id":"c","ok":false,"md":"maven-compiler-plugin, `compile` fazında","whyMd":"Compiler plugin derleme yapar, test koşmaz."},{"id":"d","ok":false,"md":"maven-jar-plugin, `package` fazında","whyMd":"JAR plugin paketleme yapar, test koşmaz."}],"explanationMd":"`mvn verify` hem Surefire ile unit testleri hem Failsafe ile integration testleri çalıştırır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m6","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Uygulamanın veritabanı şifresi için aşağıdakilerden hangisi uygun bir yerdir?","multi":false,"options":[{"id":"a","ok":false,"md":"Private repo'daki `application-prod.yml` dosyası","whyMd":"Git geçmişi kalıcıdır ve repo erişimi olan herkes şifreyi görür."},{"id":"b","ok":false,"md":"Dockerfile içinde `ENV DB_PASSWORD=...`","whyMd":"Image'ı çeken herkes `docker inspect` veya image geçmişiyle şifreyi okuyabilir."},{"id":"c","ok":true,"md":"Vault ya da AWS Secrets Manager gibi bir secret manager; değer runtime'da uygulamaya verilir","whyMd":"Secret, erişimi denetlenen ve rotasyon destekleyen bir yerde durur."},{"id":"d","ok":false,"md":"Pipeline log'una yazılan ve oradan kopyalanan bir değer","whyMd":"Log'lar geniş erişimlidir ve uzun süre saklanır; secret log'a yazılmaz."}],"explanationMd":"Secret'lar Git'e ve image'a girmez; secret manager'dan runtime'da gelir.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m7","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","bodyMd":"Hızlı geri bildirim ilkesine göre aşağıdaki pipeline sıralamalarından hangisi en mantıklıdır?","multi":false,"options":[{"id":"a","ok":false,"md":"Image build, staging deploy, e2e test, unit test","whyMd":"Ucuz unit testler en sona kalmış; hatalı kod için image ve deploy boşuna yapılır."},{"id":"b","ok":true,"md":"Unit test, integration test, image build, staging deploy, smoke test","whyMd":"Ucuz ve hızlı kontroller önce, ortam gerektirenler sonra gelir."},{"id":"c","ok":false,"md":"Staging deploy, unit test, image build, integration test","whyMd":"Test edilmemiş kod staging'e gidiyor."},{"id":"d","ok":false,"md":"E2e test, integration test, unit test, image build","whyMd":"En pahalı test en önde; geri bildirim en geç gelir."}],"explanationMd":"Pipeline, en ucuz kontrolle en erken düşecek şekilde sıralanır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m8","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","bodyMd":"Bir test aynı commit'te bazen geçip bazen kalıyor. En doğru ilk yaklaşım hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Surefire'da otomatik yeniden deneme açıp konuyu kapatmak","whyMd":"Retry gerçek bir eşzamanlılık hatasını gizleyebilir ve kalıcı çözüm değildir."},{"id":"b","ok":false,"md":"Testi silmek","whyMd":"Test gerçek bir hatanın tek işareti olabilir; silmek son seçenektir."},{"id":"c","ok":true,"md":"Testi sahibi ve kaydı olan bir karantinaya almak, kök nedenini (paylaşılan durum, zaman, asenkron bekleme) bulup düzeltmek","whyMd":"Karantina hattı korur, kök neden analizi sorunu kalıcı çözer."},{"id":"d","ok":false,"md":"Kırmızı build'leri görmezden gelmeyi ekip kuralı yapmak","whyMd":"Kırmızıya alışan ekip gerçek kırılmaları da kaçırır."}],"explanationMd":"Flaky test pipeline'a güveni yok eder; görünür, sahipli ve geçici bir karantina ile kök neden düzeltmesi gerekir.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m9","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","bodyMd":"Canary deployment için aşağıdakilerden hangileri doğrudur?","multi":true,"options":[{"id":"a","ok":true,"md":"Trafiğin küçük bir yüzdesi yeni sürüme yönlendirilir ve metrikler iyiyse yüzde artırılır","whyMd":"Canary'nin tanımı budur."},{"id":"b","ok":true,"md":"Anlamlı karar için metrik analizi ve trafik bölme altyapısı gerekir","whyMd":"Trafik bölme ve otomatik analiz olmadan canary kararları yavaş ve tutarsızdır."},{"id":"c","ok":false,"md":"Her zaman iki kat altyapı kaynağı gerektirir","whyMd":"İki kat kaynak blue-green'in özelliğidir; canary az ek kaynakla çalışır."},{"id":"d","ok":false,"md":"Eski ve yeni sürüm birlikte çalışmadığı için veritabanı uyumluluğu gerekmez","whyMd":"Canary boyunca iki sürüm aynı veritabanını kullanır; şema ikisiyle de uyumlu olmalıdır."}],"explanationMd":"Canary riski kademeli açar ama metrik, trafik bölme ve geriye uyumlu şema ister.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m10","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","bodyMd":"GitHub Actions'ta bir job'ın OIDC ile AWS rolü üstlenebilmesi için workflow'da hangi izin gereklidir?","multi":false,"options":[{"id":"a","ok":false,"md":"`contents: write`","whyMd":"Repo içeriğine yazma iznidir; OIDC token'ı ile ilgisi yoktur."},{"id":"b","ok":true,"md":"`id-token: write`","whyMd":"Job'ın OIDC kimlik token'ı isteyebilmesi için bu izin gerekir."},{"id":"c","ok":false,"md":"`actions: write`","whyMd":"Workflow ve run yönetimiyle ilgilidir, OIDC token'ı vermez."},{"id":"d","ok":false,"md":"`packages: read`","whyMd":"Paket okuma iznidir; AWS kimliğiyle ilgisi yoktur."}],"explanationMd":"`id-token: write` olmadan job OIDC token'ı alamaz; rolün kimin tarafından üstlenilebileceği ise AWS tarafında trust policy'deki `sub` koşuluyla kısıtlanır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m11","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","bodyMd":"Expand/contract ile bir kolonu kaldırırken eski kolonun `DROP` edilmesi ne zaman güvenlidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Yeni kolonun eklendiği migration ile aynı release'te","whyMd":"Rollout sırasında eski pod'lar hâlâ eski kolonu kullanır ve kırılır."},{"id":"b","ok":false,"md":"Kod yeni kolona yazmaya başladığı anda","whyMd":"Eski sürümler hâlâ çalışıyor ya da rollback ile dönülebilir olabilir."},{"id":"c","ok":true,"md":"Eski kolonu bilen hiçbir sürüm çalışmadığında ve o sürümlere rollback ihtimali kalmadığında","whyMd":"Contract adımı, eski yapıya bağımlı hiçbir sürüm kalmadığında yapılır."},{"id":"d","ok":false,"md":"Gece trafiği azaldığında, hangi adımda olunduğundan bağımsız olarak","whyMd":"Düşük trafik kesintiyi küçültür ama uyumsuzluğu ortadan kaldırmaz."}],"explanationMd":"Contract, rollback penceresi kapandıktan sonra ayrı bir release'te yapılır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m12","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","bodyMd":"GitOps modelinde CI pipeline'ının tipik rolü nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Prod kümesine `kubectl apply` ile doğrudan deploy etmek","whyMd":"Bu push modelidir; GitOps'ta CI'ın küme kimlik bilgisi taşıması gerekmez."},{"id":"b","ok":true,"md":"Image'ı build edip push'lamak ve Git'teki manifest'te image etiketini güncellemek","whyMd":"Kümeye uygulamayı küme içindeki controller yapar; CI istenen durumu Git'te değiştirir."},{"id":"c","ok":false,"md":"Argo CD'yi her deploy'da yeniden kurmak","whyMd":"Controller kalıcı olarak kümede çalışır."},{"id":"d","ok":false,"md":"Kümedeki değişiklikleri Git'e geri yazmak","whyMd":"Yön tersidir: controller Git'teki durumu kümeye uygular."}],"explanationMd":"GitOps'ta deploy bir Git commit'idir; Argo CD/Flux Git'i kümeyle sürekli uzlaştırır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m13","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","bodyMd":"Aşağıdakilerden hangisi DORA'nın yazılım teslimat performansı metriklerinden biri değildir?","multi":false,"options":[{"id":"a","ok":false,"md":"Change lead time","whyMd":"Commit'ten production'a geçen süre, DORA'nın throughput metriğidir."},{"id":"b","ok":false,"md":"Change fail rate","whyMd":"Acil müdahale gerektiren deploy oranı, DORA'nın instability metriğidir."},{"id":"c","ok":true,"md":"Kod coverage yüzdesi","whyMd":"Coverage bir kod kalitesi sinyalidir, DORA teslimat metriği değildir."},{"id":"d","ok":false,"md":"Deployment frequency","whyMd":"Deploy sıklığı DORA'nın throughput metriğidir."}],"explanationMd":"Güncel DORA tanımında throughput (lead time, deployment frequency, failed deployment recovery time) ve instability (change fail rate, deployment rework rate) metrikleri vardır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m14","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","bodyMd":"Yeni sürüm, eski sürümün tanımadığı yeni bir enum değerini veritabanına yazmaya başladı ve bir sorun yüzünden rollback yapıldı. En olası sonuç ve doğru önlem hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Sorun olmaz; rollback veritabanını da otomatik geri alır","whyMd":"Image rollback şemaya ve veriye dokunmaz."},{"id":"b","ok":true,"md":"Eski sürüm o satırları okurken hata verir; önce yeni değeri okuyabilen bir sürüm çıkarılmalı, yazmaya ancak sonra başlanmalıdır","whyMd":"Okuyucuyu önce, yazıcıyı sonra yayınlamak rollback'i güvenli kılar."},{"id":"c","ok":false,"md":"Sorun olmaz; JPA bilinmeyen enum değerlerini otomatik olarak null yapar","whyMd":"`@Enumerated` ile eşlenen bilinmeyen değer varsayılan olarak hata fırlatır."},{"id":"d","ok":false,"md":"Sadece yeni satırlar etkilenir, bu yüzden önlem gerekmez","whyMd":"Yeni satırları okuyan her eski sürüm isteği hata alır; etki gerçek kullanıcılara yansır."}],"explanationMd":"Geriye uyumluluk veri için de geçerlidir: eski sürümün okuyamayacağı veri, rollback penceresi kapanmadan yazılmamalıdır.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/ci-cd#m15","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","bodyMd":"Container image'ını pipeline'da imzalamak ve deploy'da imzayı doğrulamak neyi sağlar?","multi":false,"options":[{"id":"a","ok":false,"md":"Image'da bilinen zafiyet olmadığını garanti eder","whyMd":"İmza köken ve bütünlük hakkındadır; zafiyet için tarama ve SBOM gerekir."},{"id":"b","ok":true,"md":"Image'ın güvenilen bir kimlik tarafından üretildiğini ve sonradan değiştirilmediğini doğrular","whyMd":"İmza ve doğrulama, image'ın kimden geldiğini ve değişmediğini kanıtlar."},{"id":"c","ok":false,"md":"Image boyutunu küçültür","whyMd":"İmza image içeriğini değiştirmez."},{"id":"d","ok":false,"md":"Uygulamanın runtime secret'larını şifreler","whyMd":"Secret yönetimiyle ilgisi yoktur."}],"explanationMd":"İmza, provenance ve SBOM farklı soruları cevaplar; imza ancak deploy tarafında doğrulanırsa koruma sağlar.","links":[],"href":"/sorular/ci-cd/"},{"kind":"mcq","id":"sorular/docker#m1","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"Container ile sanal makine (VM) arasındaki temel fark hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Container kendi kernel'ini çalıştırır, VM host kernel'ini paylaşır.","whyMd":"Tam tersi; container'da ayrı bir kernel açılmaz."},{"id":"b","ok":true,"md":"Container'lar host kernel'ini paylaşır; VM kendi kernel'iyle tam bir işletim sistemi çalıştırır.","whyMd":"Container namespace ve cgroup ile izole edilmiş bir süreçtir ve host kernel'ini kullanır."},{"id":"c","ok":false,"md":"Container sadece Linux'ta, VM sadece Windows'ta çalışır.","whyMd":"VM her işletim sisteminde çalışabilir; Linux container'ı Mac ve Windows'ta da arkadaki bir Linux VM ile çalışır."},{"id":"d","ok":false,"md":"Container içinde ağ yoktur, VM'de vardır.","whyMd":"Container'ın network namespace'i sayesinde kendi ağ arayüzü vardır."}],"explanationMd":"Kernel paylaşımı container'ı hızlı ve hafif yapar, ama izolasyonun güvenlik sınırını da kernel'e çeker.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m2","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"Çalışan bir container içinde `/app/config.yml` dosyasını değiştirip container'ı silersen ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"Değişiklik image'a yazılır, yeni container'lar da değişmiş dosyayı görür.","whyMd":"Image salt okunurdur; container'daki yazmalar image'ı değiştirmez."},{"id":"b","ok":true,"md":"Değişiklik container'ın yazılabilir katmanındaydı ve container ile birlikte kaybolur.","whyMd":"Yazmalar copy-on-write ile container'a özel katmana gider; container silinince o katman da silinir."},{"id":"c","ok":false,"md":"Docker değişikliği otomatik olarak bir volume'a taşır.","whyMd":"Volume ancak açıkça tanımlanırsa kullanılır."},{"id":"d","ok":false,"md":"Container silinemez, önce image'ın yeniden build edilmesi gerekir.","whyMd":"Container silmek için image'la ilgili bir işlem gerekmez."}],"explanationMd":"Kalıcı veri volume'a, kalıcı değişiklik Dockerfile'a girmelidir; container geçici kabul edilir.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m3","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"`docker run -p 9090:8080 order-service` komutu için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Host'un 8080 port'u container'ın 9090 port'una yönlendirilir.","whyMd":"Sıra ters; sol taraf host, sağ taraf container port'udur."},{"id":"b","ok":true,"md":"Host'un 9090 port'u container'ın 8080 port'una yönlendirilir.","whyMd":"Biçim HOST:CONTAINER şeklindedir."},{"id":"c","ok":false,"md":"Container hem 9090 hem 8080 port'unu dinlemeye başlar.","whyMd":"Uygulamanın dinlediği port'u Docker değiştirmez; sadece yönlendirme kurar."},{"id":"d","ok":false,"md":"Komut sadece Dockerfile'da `EXPOSE 9090` varsa çalışır.","whyMd":"Port publish için EXPOSE gerekmez."}],"explanationMd":"Host'tan `localhost:9090` ile container'daki 8080'de çalışan uygulamaya erişilir.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m4","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"Dockerfile'daki `EXPOSE 8080` talimatı ne yapar?","multi":false,"options":[{"id":"a","ok":false,"md":"Container'ın 8080 port'unu host'a otomatik olarak açar.","whyMd":"Dışarı açmak için `docker run -p` ya da compose'da `ports` gerekir."},{"id":"b","ok":false,"md":"Uygulamayı 8080 port'unda dinlemeye zorlar.","whyMd":"Uygulamanın port'unu uygulama konfigürasyonu belirler."},{"id":"c","ok":true,"md":"Image'ın hangi port'u kullandığını belgeler; tek başına port'u dışarı açmaz.","whyMd":"EXPOSE metadata'dır; sadece `-P` kullanıldığında rastgele host port'larına publish için kullanılır."},{"id":"d","ok":false,"md":"Container'lar arası trafiği 8080 dışındaki port'larda engeller.","whyMd":"EXPOSE bir firewall kuralı değildir."}],"explanationMd":"EXPOSE belgeleme amaçlıdır; port publish çalıştırma zamanında yapılır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m5","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"Compose dosyasında `app` ve `postgres` adlı iki servis var; postgres `ports: [\"15432:5432\"]` ile publish edilmiş. `app` container'ı veritabanına hangi URL ile bağlanmalı?","multi":false,"options":[{"id":"a","ok":false,"md":"`jdbc:postgresql://localhost:5432/orders`","whyMd":"Container içindeki localhost, app container'ının kendisidir."},{"id":"b","ok":false,"md":"`jdbc:postgresql://localhost:15432/orders`","whyMd":"Hem localhost yanlış hem de 15432 sadece host'tan erişim için publish edilen port'tur."},{"id":"c","ok":true,"md":"`jdbc:postgresql://postgres:5432/orders`","whyMd":"Compose ağında servis adı DNS adıdır ve container'lar arası trafik container port'unu kullanır."},{"id":"d","ok":false,"md":"`jdbc:postgresql://postgres:15432/orders`","whyMd":"Servis adı doğru ama container'dan container'a host port'u değil container port'u kullanılır."}],"explanationMd":"Host port sadece ağ dışından erişim içindir; servisler birbirine servis adı ve container port'uyla ulaşır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m6","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"Container içindeki bir Spring Boot uygulaması log'larını nereye yazmalıdır?","multi":false,"options":[{"id":"a","ok":false,"md":"Container içinde `/var/log/app.log` dosyasına.","whyMd":"Dosya container'ın yazılabilir katmanında kalır, `docker logs` göstermez ve disk dolar."},{"id":"b","ok":true,"md":"stdout ve stderr'e; Docker ve log toplama ajanları buradan alır.","whyMd":"Container dünyasında standart sözleşme budur; `docker logs` ve Kubernetes bu akışı okur."},{"id":"c","ok":false,"md":"Doğrudan host'taki bir dosyaya, bind mount üzerinden.","whyMd":"Çalışabilir ama uygulamayı host'un dizin yapısına bağlar ve toplama sistemini atlar."},{"id":"d","ok":false,"md":"Log yazmamalı, sadece metrik üretmeli.","whyMd":"Log ve metrik farklı soruları cevaplar; ikisi de gerekir."}],"explanationMd":"Uygulama akışa yazar, akışı toplamak ve saklamak platformun işidir.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m7","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","bodyMd":"`docker ps -a` çıktısında container'ın `Exited (137)` ile durduğunu görüyorsun. 137 neyi gösterir?","multi":false,"options":[{"id":"a","ok":false,"md":"Uygulama `System.exit(137)` çağırdı, başka anlamı yok.","whyMd":"Teorik olarak mümkün ama 137 pratikte sinyalle ölümü gösterir."},{"id":"b","ok":true,"md":"Süreç SIGKILL ile öldürüldü (128 + 9); bellek limiti ya da stop süresinin dolması olabilir.","whyMd":"Sinyalle sonlanan süreçte çıkış kodu 128 + sinyal numarasıdır; SIGKILL 9'dur."},{"id":"c","ok":false,"md":"Süreç SIGTERM aldı ve düzgün kapandı.","whyMd":"SIGTERM ile kapanan JVM 143 (128 + 15) döner."},{"id":"d","ok":false,"md":"Image bulunamadı.","whyMd":"Image bulunamazsa container hiç oluşmaz."}],"explanationMd":"137 tek başına OOM demek değildir; `docker inspect` çıktısındaki `State.OOMKilled` ile ayırt edilir.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m8","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","bodyMd":"Bir Maven projesi için hangi Dockerfile sırası, sadece Java kodu değiştiğinde bağımlılıkların yeniden indirilmesini önler?","multi":false,"options":[{"id":"a","ok":false,"md":"`COPY . .` sonra `RUN ./mvnw package`","whyMd":"Her kod değişikliği COPY cache'ini bozar ve sonrasındaki package bütün bağımlılıkları yeniden indirir."},{"id":"b","ok":false,"md":"`COPY src/ src/` sonra `COPY pom.xml .` sonra `RUN ./mvnw package`","whyMd":"src önce kopyalandığı için kod değişince sonraki tüm adımlar yeniden çalışır."},{"id":"c","ok":true,"md":"`COPY pom.xml .` sonra `RUN ./mvnw dependency:go-offline` sonra `COPY src/ src/` sonra `RUN ./mvnw package`","whyMd":"Bağımlılık katmanı sadece pom.xml değiştiğinde yeniden üretilir."},{"id":"d","ok":false,"md":"Sıra fark etmez, Docker değişmeyen dosyaları zaten cache'ten alır.","whyMd":"Cache zincirleme çalışır; bozulan adımdan sonraki her şey yeniden çalışır."}],"explanationMd":"Az değişen adımlar üste, sık değişenler alta konur; cache mount ile bu daha da hızlanır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m9","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","bodyMd":"Dockerfile'da `ENTRYPOINT [\"java\", \"-jar\", \"app.jar\"]` ve `CMD [\"--spring.profiles.active=prod\"]` var. `docker run image --server.port=9090` çalıştırılınca hangi komut çalışır?","multi":false,"options":[{"id":"a","ok":false,"md":"`java -jar app.jar --spring.profiles.active=prod --server.port=9090`","whyMd":"Run'a verilen argümanlar CMD'ye eklenmez, CMD'nin yerine geçer."},{"id":"b","ok":true,"md":"`java -jar app.jar --server.port=9090`","whyMd":"CMD ezilir, ENTRYPOINT kalır ve yeni argümanlar ona eklenir."},{"id":"c","ok":false,"md":"`--server.port=9090` (ENTRYPOINT ezilir)","whyMd":"ENTRYPOINT'i değiştirmek için `--entrypoint` gerekir."},{"id":"d","ok":false,"md":"`java -jar app.jar --spring.profiles.active=prod`","whyMd":"Run'a argüman verildiği için CMD kullanılmaz."}],"explanationMd":"ENTRYPOINT sabit program, CMD ezilebilir varsayılan argümanlardır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m10","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","bodyMd":"Compose'da `depends_on: [postgres]` (kısa yazım) neyi garanti eder?","multi":false,"options":[{"id":"a","ok":false,"md":"Postgres bağlantı kabul etmeye hazır olana kadar app başlatılmaz.","whyMd":"Hazır olmayı beklemek için healthcheck ve `condition: service_healthy` gerekir."},{"id":"b","ok":true,"md":"Postgres container'ı app'ten önce başlatılır; hazır olması beklenmez.","whyMd":"Kısa yazım sadece başlatma sırasını belirler."},{"id":"c","ok":false,"md":"Postgres çökerse app de otomatik durdurulur.","whyMd":"depends_on çalışma zamanında böyle bir bağ kurmaz."},{"id":"d","ok":false,"md":"App ve postgres aynı container'da çalışır.","whyMd":"Her servis kendi container'ında çalışır."}],"explanationMd":"Başlatılmış olmak ile hazır olmak farklıdır; uygulama yine de bağlantı hatalarına dayanıklı olmalıdır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m11","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","bodyMd":"Multi-stage bir Dockerfile'da son aşama `FROM eclipse-temurin:21-jre` ile başlıyor ve build aşamasından sadece katmanlara ayrılmış jar içeriği kopyalanıyor. Son image'da ne bulunmaz?","multi":false,"options":[{"id":"a","ok":false,"md":"Java çalışma ortamı (JRE)","whyMd":"JRE son aşamanın taban image'ından gelir."},{"id":"b","ok":false,"md":"Uygulamanın derlenmiş sınıfları ve bağımlılıkları","whyMd":"Bunlar COPY --from ile alınan katmanlardır."},{"id":"c","ok":true,"md":"Maven, JDK derleyicisi ve kaynak kod","whyMd":"Build araçları ve kaynak kod build aşamasında kalır, son image'a kopyalanmaz."},{"id":"d","ok":false,"md":"Taban image'ın işletim sistemi kullanıcı alanı dosyaları","whyMd":"Temurin JRE image'ı bir Linux dağıtımının kullanıcı alanı dosyalarını içerir."}],"explanationMd":"Multi-stage'in amacı çalışmak için gerekmeyen her şeyi son image'ın dışında bırakmaktır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m12","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","bodyMd":"`ENTRYPOINT java -jar /app/app.jar` (shell form) kullanılan bir container'da `server.shutdown=graceful` açık. `docker stop` sonrası 10 saniye beklenip container 137 ile kapanıyor. En olası neden nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Spring Boot'ta graceful shutdown Docker'da desteklenmez.","whyMd":"Graceful shutdown SIGTERM'e bağlıdır, ortamdan bağımsızdır."},{"id":"b","ok":true,"md":"PID 1 `/bin/sh` olduğu için SIGTERM Java'ya iletilmedi; süre dolunca SIGKILL geldi.","whyMd":"Shell form komutu sh -c altında çalıştırır, shell sinyali çocuk sürece iletmez."},{"id":"c","ok":false,"md":"JVM SIGTERM'i yok sayar, sadece SIGINT ile kapanır.","whyMd":"JVM SIGTERM'de shutdown hook'larını çalıştırıp kapanır."},{"id":"d","ok":false,"md":"Container'ın bellek limiti aşıldı.","whyMd":"OOM'da bekleme olmaz; ayrıca davranış docker stop'la tetikleniyor."}],"explanationMd":"Exec form ENTRYPOINT ya da script'te `exec java ...` ile Java PID 1 olur ve SIGTERM'i alır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m13","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","bodyMd":"1 GiB bellek limiti olan bir container'da JVM'e `-Xmx1g` verilmiş. Yük altında en olası sonuç nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Heap dolunca `OutOfMemoryError: Java heap space` fırlatılır ve heap dump alınır.","whyMd":"Heap dolmadan önce toplam süreç belleği limiti aşar; kernel öldürmesinde exception ve dump yoktur."},{"id":"b","ok":true,"md":"Heap dışı bellek (metaspace, thread stack, direct memory) yüzünden toplam limit aşılır ve kernel süreci öldürür (OOMKilled, 137).","whyMd":"Heap limitin tamamını alınca heap dışı alanlara yer kalmaz."},{"id":"c","ok":false,"md":"JVM limiti aşmamak için heap'i otomatik olarak 256 MB'a düşürür.","whyMd":"Açık -Xmx verildiğinde JVM yüzde hesabını kullanmaz."},{"id":"d","ok":false,"md":"Docker limiti aşan belleği swap'e taşır, sorun olmaz.","whyMd":"Limit aşımı swap ile tolere edilmez; varsayılan sonuç öldürülmektir."}],"explanationMd":"Heap'i -XX:MaxRAMPercentage ile limitin bir yüzdesi olarak vermek ve heap dışını ölçmek gerekir (bkz. Kitap Bölüm 3).","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m14","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","bodyMd":"Aşağıdakilerden hangileri bir build secret'ını image'a ya da image geçmişine sızdırabilir? (Birden fazla doğru var.)","multi":true,"options":[{"id":"a","ok":true,"md":"`ARG NPM_TOKEN` tanımlayıp `RUN` içinde kullanmak ve `--build-arg` ile vermek","whyMd":"Build arg'lar image metadata'sında ve build geçmişinde görünebilir."},{"id":"b","ok":true,"md":"`ENV NPM_TOKEN=...` ile token'ı ortam değişkeni yapmak","whyMd":"ENV değeri image config'ine yazılır ve her container'da görünür."},{"id":"c","ok":true,"md":"`COPY .npmrc .` ile dosyayı kopyalayıp sonraki bir `RUN rm .npmrc` ile silmek","whyMd":"Dosya COPY katmanında durur; sonraki katmandaki silme onu ortadan kaldırmaz."},{"id":"d","ok":false,"md":"`RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci` kullanmak","whyMd":"Secret sadece o RUN süresince bağlanır ve hiçbir katmana yazılmaz."}],"explanationMd":"Build secret'ları için BuildKit secret mount, çalışma zamanı secret'ları için ortamın secret mekanizması kullanılır.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/docker#m15","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","bodyMd":"Kubernetes 1.24 ile dockershim kaldırıldı. Docker ile build edilip registry'ye push edilmiş bir Spring Boot image'ı için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Image artık çalışmaz; Kubernetes için image'ı Kaniko ile yeniden build etmek gerekir.","whyMd":"Kaldırılan şey runtime bağlantısıdır; image formatı değişmedi."},{"id":"b","ok":true,"md":"Image OCI uyumlu olduğu için containerd ya da CRI-O ile çalışmaya devam eder.","whyMd":"Docker'ın ürettiği image standart OCI image'ıdır ve CRI uyumlu runtime'lar onu çalıştırır."},{"id":"c","ok":false,"md":"Image sadece node'lara Docker Engine kurulursa çalışır.","whyMd":"Kubelet CRI üzerinden containerd ya da CRI-O ile konuşur, Docker Engine gerekmez."},{"id":"d","ok":false,"md":"Image çalışır ama ENTRYPOINT yok sayılır.","whyMd":"ENTRYPOINT ve CMD image config'inin parçasıdır ve runtime tarafından uygulanır."}],"explanationMd":"Build aracı, image formatı ve runtime ayrı katmanlardır; OCI standartları bunları birbirinden bağımsız kılar.","links":[],"href":"/sorular/docker/"},{"kind":"mcq","id":"sorular/git#m1","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"`git fetch` komutu ne yapar?","multi":false,"options":[{"id":"a","ok":false,"md":"Remote'taki değişiklikleri indirir ve aktif branch'e merge eder.","whyMd":"Bu `git pull`'un davranışıdır (fetch + merge)."},{"id":"b","ok":true,"md":"Remote'taki yeni commit'leri indirir ve sadece `origin/main` gibi remote-tracking ref'leri günceller.","whyMd":"Fetch nesneleri indirir, remote-tracking ref'leri günceller; yerel branch'e ve working tree'ye dokunmaz."},{"id":"c","ok":false,"md":"Sadece remote'ta değişiklik olup olmadığını kontrol eder, hiçbir şey indirmez.","whyMd":"Fetch nesneleri gerçekten indirir; sadece entegrasyon yapmaz."},{"id":"d","ok":false,"md":"Yerel commit'leri remote'a gönderir.","whyMd":"Bu `git push`'tur."}],"explanationMd":"`git pull` = `git fetch` + entegrasyon (merge ya da rebase). Fetch yan etkisizdir; gelenleri `git log main..origin/main` ile inceleyebilirsin.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m2","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"Git'te bir branch teknik olarak nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Proje dosyalarının ayrı bir kopyası","whyMd":"Branch açmak dosya kopyalamaz; bu yüzden anlıktır."},{"id":"b","ok":true,"md":"Bir commit'e işaret eden hareketli bir isim (ref)","whyMd":"Branch, `.git/refs/heads/` altında tek bir commit hash'i tutan ve commit attıkça ilerleyen bir işaretçidir."},{"id":"c","ok":false,"md":"Sunucuda tutulan ayrı bir repository","whyMd":"Branch aynı repository içindeki bir ref'tir; remote'ta da aynı şekilde bir ref olarak tutulur."},{"id":"d","ok":false,"md":"Henüz commit'lenmemiş değişikliklerin listesi","whyMd":"Bu working tree ve index'in durumudur, branch değil."}],"explanationMd":"Branch'in 'içeriği', işaret ettiği commit'ten parent'lara doğru ulaşılabilen geçmiştir.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m3","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"`git add Foo.java` yaptın, sonra `Foo.java`'yı tekrar değiştirdin ve `git commit` dedin. Commit'e ne girer?","multi":false,"options":[{"id":"a","ok":false,"md":"Dosyanın son (diskteki) hali","whyMd":"Commit working tree'den değil index'ten oluşturulur."},{"id":"b","ok":true,"md":"Dosyanın `git add` anındaki hali; sonraki değişiklik unstaged olarak kalır","whyMd":"`git add` içeriği o anki haliyle index'e yazar; commit index'ten oluşur."},{"id":"c","ok":false,"md":"Hiçbir şey; Git dosya değiştiği için hata verir","whyMd":"Git hata vermez; `git status` dosyayı hem staged hem unstaged olarak gösterir."},{"id":"d","ok":false,"md":"İki değişikliğin ayrı ayrı iki commit'i","whyMd":"Tek bir commit oluşur."}],"explanationMd":"Index bir sonraki commit'in taslağıdır. `git diff --staged` commit'e girecek olanı, `git diff` henüz stage edilmemiş olanı gösterir.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m4","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"Daha önce commit'lenmiş `application.log` dosyasını `.gitignore`'a ekledin ama `git status` hâlâ değişikliklerini gösteriyor. Neden?","multi":false,"options":[{"id":"a","ok":false,"md":"`.gitignore` sadece bir sonraki clone'da etkili olur.","whyMd":"Ignore kuralları anında uygulanır, clone ile ilgisi yoktur."},{"id":"b","ok":true,"md":"`.gitignore` sadece izlenmeyen dosyalara uygulanır; dosya takipten `git rm --cached` ile çıkarılmalı.","whyMd":"Takip edilen dosyalar ignore kurallarından etkilenmez; index'ten çıkarılınca kural devreye girer."},{"id":"c","ok":false,"md":"Desen yanlış yazılmıştır; `*.log` her zaman takip edilen dosyaları da gizler.","whyMd":"Hiçbir desen takip edilen bir dosyayı gizlemez."},{"id":"d","ok":false,"md":"`.gitignore` dosyası commit'lenmeden etkili olmaz.","whyMd":"Commit'lenmemiş `.gitignore` da yerelde hemen etkilidir."}],"explanationMd":"`git rm --cached application.log` dosyayı diskte bırakıp index'ten siler; sonraki commit'ten itibaren dosya izlenmez. Geçmişteki kopyalar silinmez.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m5","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"Push edilmemiş son commit'inin mesajında yazım hatası var. En uygun komut hangisi?","multi":false,"options":[{"id":"a","ok":false,"md":"`git revert HEAD`","whyMd":"Revert değişikliğin tersini uygulayan yeni bir commit ekler; mesajı düzeltmez."},{"id":"b","ok":true,"md":"`git commit --amend -m \"düzgün mesaj\"`","whyMd":"Amend son commit'i yeni mesajla yeni bir commit olarak yeniden yazar; push edilmemişse güvenlidir."},{"id":"c","ok":false,"md":"`git reset --hard HEAD~1` ve değişiklikleri yeniden yazmak","whyMd":"Gereksiz ve tehlikeli; değişiklikler working tree'den de silinir."},{"id":"d","ok":false,"md":"`git rebase main`","whyMd":"Rebase commit'leri yeni tabana taşır, mesajı değiştirmez."}],"explanationMd":"Amend yeni SHA üretir. Commit push edildiyse remote'u güncellemek force push ister; paylaşılan branch'te bunu yapma.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m6","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"`git stash` varsayılan olarak hangi değişiklikleri saklamaz?","multi":false,"options":[{"id":"a","ok":false,"md":"Staged değişiklikleri","whyMd":"Staged değişiklikler stash'e girer."},{"id":"b","ok":false,"md":"Takip edilen dosyalardaki unstaged değişiklikleri","whyMd":"Takip edilen dosyalardaki unstaged değişiklikler stash'e girer."},{"id":"c","ok":true,"md":"İzlenmeyen (yeni, hiç `git add` edilmemiş) dosyaları","whyMd":"İzlenmeyen dosyalar için `git stash -u` gerekir; aksi halde working tree'de kalırlar."},{"id":"d","ok":false,"md":"Silinmiş takip edilen dosyaları","whyMd":"Takip edilen bir dosyanın silinmesi de bir değişikliktir ve stash'e girer."}],"explanationMd":"`-u` (`--include-untracked`) izlenmeyenleri, `-a` ignore edilenleri de dahil eder. `stash pop` conflict verirse kayıt silinmez.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m7","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","bodyMd":"`git push origin main` komutunun tag'lerle ilişkisi için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Tüm yerel tag'leri de otomatik gönderir.","whyMd":"Varsayılan push tag göndermez."},{"id":"b","ok":true,"md":"Tag'leri göndermez; `git push origin v1.4.0` ya da `--follow-tags` gerekir.","whyMd":"Tag'ler ayrıca push edilir; `--follow-tags` push edilen commit'lere ulaşılabilen annotated tag'leri ekler."},{"id":"c","ok":false,"md":"Sadece lightweight tag'leri gönderir.","whyMd":"Varsayılan push hiçbir tag türünü göndermez."},{"id":"d","ok":false,"md":"Tag'ler remote'a hiçbir şekilde gönderilemez.","whyMd":"Tag'ler `git push origin ` ya da `--tags` ile gönderilir."}],"explanationMd":"Release için annotated tag (`git tag -a`) tercih edilir; `push.followTags` ayarı bunu otomatikleştirir.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m8","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","bodyMd":"`main`'den sonra kendi branch'inde 3 commit attın; `git reset --soft HEAD~3` sonrası durum nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Üç commit'in değişiklikleri tamamen silinir.","whyMd":"Bu `--hard`'ın working tree üzerindeki etkisidir; `--soft` hiçbir değişikliği silmez."},{"id":"b","ok":true,"md":"Branch üç commit geri gider; değişiklikler index'te (staged) kalır.","whyMd":"`--soft` sadece branch işaretçisini taşır; index ve working tree aynı kalır, böylece tek commit'te toplayabilirsin."},{"id":"c","ok":false,"md":"Branch üç commit geri gider; değişiklikler working tree'de unstaged kalır.","whyMd":"Bu `--mixed` (varsayılan) davranışıdır."},{"id":"d","ok":false,"md":"Üç commit'in tersini uygulayan üç yeni commit oluşur.","whyMd":"Bu revert'ün davranışıdır."}],"explanationMd":"soft: HEAD; mixed: HEAD + index; hard: HEAD + index + working tree. Eski uç `ORIG_HEAD` ve reflog'da kalır.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m9","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","bodyMd":"Rebase ile ilgili hangileri doğrudur? (Birden fazla seçenek doğru olabilir.)","multi":true,"options":[{"id":"a","ok":true,"md":"Rebase edilen commit'ler içerikleri aynı kalsa da yeni SHA'lar alır.","whyMd":"Parent değiştiği için commit nesnesi ve dolayısıyla hash değişir."},{"id":"b","ok":false,"md":"Rebase, eski commit'leri anında ve geri dönülmez şekilde siler.","whyMd":"Eski commit'ler reflog'da ve `ORIG_HEAD`'de kalır; süre dolup `gc` çalışana kadar kurtarılabilir."},{"id":"c","ok":true,"md":"Rebase sırasında `--ours` üzerine taşındığın tabanı, `--theirs` senin commit'ini gösterir.","whyMd":"Rebase, tabanın üzerine senin commit'lerini uyguladığı için taraflar merge'e göre yer değiştirir."},{"id":"d","ok":false,"md":"Paylaşılmış ve başkalarının üzerine iş kurduğu commit'leri rebase etmek güvenlidir.","whyMd":"Paylaşılmış commit'leri yeniden yazmak başkalarının geçmişini ayrıştırır; altın kural bunu yasaklar."}],"explanationMd":"Rebase geçmişi yeniden yazar: yerel düzenleme için güçlü, paylaşılan geçmişte zararlı.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m10","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","bodyMd":"`main`'e merge edilip push edilmiş bir merge commit'ini geri alman gerekiyor. Doğru komut hangisi?","multi":false,"options":[{"id":"a","ok":false,"md":"`git revert `","whyMd":"Merge commit'i için hangi parent'ın ana hat olduğu belirtilmeden revert hata verir."},{"id":"b","ok":true,"md":"`git revert -m 1 `","whyMd":"`-m 1` ilk parent'ı (main) ana hat kabul eder ve merge'ün getirdiği değişikliği geri alan yeni bir commit oluşturur."},{"id":"c","ok":false,"md":"`git reset --hard ~1` ve `git push --force`","whyMd":"Paylaşılan branch'in geçmişini yeniden yazar; başkalarının işini bozar."},{"id":"d","ok":false,"md":"`git cherry-pick `","whyMd":"Cherry-pick değişikliği uygular, geri almaz."}],"explanationMd":"Dikkat: revert edilen branch'i sonradan tekrar merge etmek değişiklikleri getirmez ('Already up to date'); önce revert commit'i revert edilir.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m11","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","bodyMd":"Bir PR squash merge ile `main`'e alındı. Hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"`main`'e iki parent'lı bir merge commit eklenir.","whyMd":"Bu merge commit yöntemidir."},{"id":"b","ok":true,"md":"PR'ın tüm değişikliği tek parent'lı tek bir yeni commit olarak eklenir; branch'teki commit'ler `main`'in geçmişinde yer almaz.","whyMd":"Squash değişikliği tek commit'e indirger; parent'ı sadece `main`'in önceki ucudur."},{"id":"c","ok":false,"md":"PR'daki her commit ayrı ayrı `main`'e kopyalanır.","whyMd":"Bu rebase merge yöntemidir."},{"id":"d","ok":false,"md":"Yerel `git branch -d feature` her zaman sorunsuz çalışır, çünkü branch merge edilmiştir.","whyMd":"Branch'in commit'leri `main`'den ulaşılabilir olmadığı için Git 'not fully merged' uyarısı verir; `-D` gerekir."}],"explanationMd":"Squash merge doğrusal ve PR başına bir commit verir; bedeli ara commit'lerin ve bisect çözünürlüğünün kaybıdır.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m12","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","bodyMd":"Rebase ettiğin feature branch'ini push etmeden önce IDE arka planda `git fetch` yaptı ve bir takım arkadaşının yeni commit'i `origin/feature`'a geldi. Şimdi `git push --force-with-lease` (beklenen değer vermeden) çalıştırırsan ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"Push reddedilir, çünkü lease her zaman remote'u sunucudan tekrar kontrol eder.","whyMd":"Beklenen değer verilmezse karşılaştırma remote-tracking ref'e göre yapılır; fetch bu ref'i zaten güncellemiştir."},{"id":"b","ok":true,"md":"Push kabul edilir ve arkadaşının görmediğin commit'i ezilir, çünkü lease güncellenmiş remote-tracking ref ile karşılaştırır.","whyMd":"Lease 'remote, benim bildiğim değerde mi' diye bakar; fetch beklentiyi sessizce güncellediği için kontrol geçer."},{"id":"c","ok":false,"md":"Git arkadaşının commit'ini otomatik olarak senin commit'lerinle birleştirir.","whyMd":"Push hiçbir zaman otomatik birleştirme yapmaz."},{"id":"d","ok":false,"md":"`--force-with-lease` sadece `main` branch'inde çalışır.","whyMd":"Her branch için çalışır."}],"explanationMd":"`--force-if-includes` ekle ya da beklenen SHA'yı açıkça ver (`--force-with-lease=feature:`). Paylaşılan branch'lerde force push'u branch protection ile kapat.","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m13","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","bodyMd":"`git reset --hard HEAD~1` yaptın. Silinen commit'in yanında, daha önce `git add` edilmiş ama commit'lenmemiş bir dosya ve hiç `git add` edilmemiş bir değişiklik vardı. Hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Üçü de reflog ile kurtarılabilir.","whyMd":"Reflog sadece ref hareketlerini (commit'leri) tutar; commit'lenmemiş değişiklikler orada yoktur."},{"id":"b","ok":true,"md":"Commit reflog ile, stage edilmiş içerik `git fsck --lost-found` ile dangling blob olarak kurtarılabilir; hiç stage edilmemiş değişiklik Git'te yoktur.","whyMd":"Commit nesnesi reflog'da durur; `git add` içeriği blob olarak yazdığı için `fsck` bulabilir; stage edilmemiş değişiklik hiç nesne olmamıştır."},{"id":"c","ok":false,"md":"Hiçbiri kurtarılamaz; `--hard` her şeyi kalıcı siler.","whyMd":"Commit'lenmiş iş reflog süresi dolup `gc` çalışana kadar kurtarılabilir."},{"id":"d","ok":false,"md":"Sadece hiç stage edilmemiş değişiklik kurtarılabilir, çünkü working tree'de durur.","whyMd":"`--hard` working tree'yi de ezer; stage edilmemiş değişiklik kaybolan tek şeydir."}],"explanationMd":"Kurtarılabilirlik sırası: commit (reflog) > stage edilmiş (dangling blob, dosya adı olmadan) > hiç stage edilmemiş (Git'te yok; IDE local history tek umut).","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/git#m14","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","bodyMd":"Production veritabanı şifresini içeren bir commit'i public olmayan şirket reposuna push ettin. İlk yapman gereken nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Dosyadan şifreyi silip yeni bir commit atmak","whyMd":"Şifre geçmişte durmaya devam eder; herkes `git log -p` ile görebilir."},{"id":"b","ok":false,"md":"`git reset --hard HEAD~1` ve `git push --force` ile commit'i remote'tan kaldırmak","whyMd":"Clone'lardaki, fork'lardaki, CI log'larındaki kopyaları silmez; geçmişi koordinasyonsuz yeniden yazar."},{"id":"c","ok":true,"md":"Şifreyi iptal edip yenilemek (rotate) ve güvenlik ekibine bildirmek; sonra geçmişi temizlemek","whyMd":"Push edilen secret ele geçirilmiş sayılır; onu geçersiz kılmak tek kesin önlemdir. Geçmiş temizliği (`git filter-repo`) ikincildir."},{"id":"d","ok":false,"md":"Dosyayı `.gitignore`'a eklemek","whyMd":"Ignore takip edilen dosyayı etkilemez ve geçmişi temizlemez."}],"explanationMd":"Sıra: rotate → etki analizi ve bildirim → `git filter-repo` ile koordineli geçmiş temizliği → kök neden (vault, pre-commit tarama, push protection).","links":[],"href":"/sorular/git/"},{"kind":"mcq","id":"sorular/guvenlik#m1","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"Kullanıcının JWT'si geçerli ve süresi dolmamış, ancak `ADMIN` yetkisi gerektiren bir endpoint'e `USER` yetkisiyle istek atıyor. API hangi status kodunu dönmelidir?","multi":false,"options":[{"id":"a","ok":false,"md":"401 Unauthorized","whyMd":"401 kimliğin olmadığı ya da geçersiz olduğu durum içindir; burada token geçerli."},{"id":"b","ok":true,"md":"403 Forbidden","whyMd":"Kimlik doğrulanmış ama işlem için yetki yok; yeniden giriş yapmak sonucu değiştirmez."},{"id":"c","ok":false,"md":"400 Bad Request","whyMd":"İstek biçim olarak doğru; sorun içerikte değil yetkide."},{"id":"d","ok":false,"md":"500 Internal Server Error","whyMd":"Bu bir sunucu hatası değil, beklenen bir yetki reddi."}],"explanationMd":"401 'kim olduğunu bilmiyorum', 403 'kim olduğunu biliyorum ama iznin yok' demektir. Spring Security'de 403'ü AccessDeniedHandler üretir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m2","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"Kullanıcı şifrelerini veritabanında saklamak için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"AES-256 ile şifreleyip anahtarı `application.yml` içinde tutmak","whyMd":"Şifreleme geri çözülebilir; anahtar sızarsa tüm şifreler açılır."},{"id":"b","ok":false,"md":"SHA-256 ile hash'leyip saklamak","whyMd":"SHA-256 hızlıdır; sızan hash'ler GPU ile kısa sürede kırılabilir."},{"id":"c","ok":true,"md":"BCrypt ya da Argon2id gibi salt'lı ve kasıtlı olarak yavaş bir algoritmayla hash'lemek","whyMd":"Yavaş ve salt'lı hash, kaba kuvvet ve rainbow table saldırılarını pahalı hale getirir."},{"id":"d","ok":false,"md":"Base64 ile kodlayıp saklamak","whyMd":"Base64 bir encoding'dir; herkes geri çevirebilir."}],"explanationMd":"Şifre saklamada amaç tek yönlü ve pahalı bir dönüşümdür. Spring'de `PasswordEncoderFactories.createDelegatingPasswordEncoder()` varsayılan olarak bcrypt kullanır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m3","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"İmzalı bir JWT'nin (JWS) payload'u hakkında hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Şifrelidir; sadece imza anahtarına sahip olan okuyabilir.","whyMd":"JWS şifrelenmez, imzalanır; şifreli JWT için JWE gerekir."},{"id":"b","ok":true,"md":"Base64URL ile kodlanmıştır; token'ı ele geçiren herkes okuyabilir.","whyMd":"Payload sadece kodlanmıştır; imza gizlilik değil bütünlük sağlar."},{"id":"c","ok":false,"md":"Sunucu dışında hiçbir yerde açılamaz, çünkü imza içeriği gizler.","whyMd":"İmza içeriği gizlemez, sadece değiştirilmediğini kanıtlar."},{"id":"d","ok":false,"md":"İmza doğrulanmadan payload'u okumak mümkün değildir.","whyMd":"Payload doğrulamadan bağımsız olarak çözülebilir; doğrulamadan ona güvenmek ise hatadır."}],"explanationMd":"JWT'ye şifre, TCKN ya da kart numarası gibi hassas veri konmaz; içinde sadece yetkilendirme için gereken minimum claim'ler bulunur.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m4","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"Aşağıdakilerden hangisi bir authorization (yetkilendirme) kontrolüdür?","multi":false,"options":[{"id":"a","ok":false,"md":"Kullanıcının girdiği şifrenin saklanan hash ile eşleşip eşleşmediğine bakmak","whyMd":"Bu kimliğin kanıtlanmasıdır, yani authentication."},{"id":"b","ok":false,"md":"JWT imzasının doğrulanması","whyMd":"İmza doğrulaması token'ın ve dolayısıyla kimliğin geçerliliğini kanıtlar; authentication'ın parçasıdır."},{"id":"c","ok":true,"md":"İstenen hesabın, giriş yapmış müşteriye ait olup olmadığının kontrolü","whyMd":"Kimliği belli birinin belirli bir kaynağa erişim izni olup olmadığına bakmak authorization'dır."},{"id":"d","ok":false,"md":"OTP kodunun doğrulanması","whyMd":"OTP ikinci bir kimlik faktörüdür; authentication'dır."}],"explanationMd":"Nesne düzeyinde yetki kontrolü (sahiplik) en sık unutulan authorization türüdür ve IDOR/BOLA açıklarının kaynağıdır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m5","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"Spring Data JPA kullanan bir projede hangi yaklaşım SQL/JPQL injection'a açıktır?","multi":false,"options":[{"id":"a","ok":false,"md":"`findByEmail(String email)` gibi türetilmiş bir sorgu metodu kullanmak","whyMd":"Türetilmiş sorgular değerleri parametre olarak bağlar."},{"id":"b","ok":false,"md":"`@Query` içinde `where c.email = :email` yazıp değeri `@Param` ile bağlamak","whyMd":"Named parametre değeri sorgu metninden ayrı gönderir."},{"id":"c","ok":true,"md":"JPQL metnini kullanıcı girdisiyle string birleştirerek kurup `em.createQuery` ile çalıştırmak","whyMd":"Girdi sorgu metninin parçası olur; JPA kullanmak bu durumda korumaz."},{"id":"d","ok":false,"md":"Criteria API ile `cb.equal` kullanıp değeri parametre olarak vermek","whyMd":"Criteria API değerleri parametre olarak bağlar."}],"explanationMd":"ORM tek başına koruma değildir; koruma değeri sorgu metninden ayıran parametreli sorgudur. Parametreleştirilemeyen kolon adları için beyaz liste kullanılır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m6","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"CORS hakkında hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"CORS, API'yi yetkisiz istemcilere karşı sunucu tarafında korur.","whyMd":"CORS sunucuyu korumaz; tarayıcı dışındaki istemciler CORS'u hiç uygulamaz."},{"id":"b","ok":false,"md":"CORS'u doğru ayarlamak CSRF korumasını gereksiz kılar.","whyMd":"Basit form istekleri preflight olmadan ve cookie ile gönderilebilir; CSRF ayrı korunmalıdır."},{"id":"c","ok":true,"md":"CORS tarayıcının uyguladığı bir kuraldır; curl gibi istemciler buna tabi değildir.","whyMd":"CORS, tarayıcının farklı origin'den gelen JavaScript'in cevabı okumasına izin verip vermeyeceğini belirler."},{"id":"d","ok":false,"md":"Sunucu `allowedOrigins(\"*\")` ile `allowCredentials(true)` ayarını birlikte güvenle kullanabilir.","whyMd":"Credentials ile joker origin birlikte kullanılamaz; Spring de buna izin vermez."}],"explanationMd":"CORS bir gevşetme mekanizmasıdır, erişim kontrolü değil. Yetki her zaman sunucuda kontrol edilir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m7","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"Production veritabanı şifresi için en uygun yaklaşım hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Repo private olduğu için `application-prod.yml` içinde tutmak","whyMd":"Private repo'lar da sızar; secret git geçmişinde kalıcı olur."},{"id":"b","ok":false,"md":"Kodda bir sabit olarak, Base64 ile kodlanmış şekilde tutmak","whyMd":"Base64 gizleme değildir; herkes geri çevirir."},{"id":"c","ok":true,"md":"Bir secret yöneticisinde (ör. Vault) tutup uygulamanın çalışma anında okuması ve düzenli döndürmek","whyMd":"Erişim kontrolü, denetim kaydı ve rotasyon imkânı sağlar."},{"id":"d","ok":false,"md":"Docker image'ına gömülü bir dosyada tutmak","whyMd":"Image'ı çeken herkes secret'ı katmanlardan okuyabilir."}],"explanationMd":"Secret'lar koddan ve artefaktlardan ayrı tutulur, en az yetkiyle erişilir ve sızıntıda önce iptal edilir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m8","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"HTTPS (TLS) aşağıdakilerden hangilerini sağlar? (Birden fazla doğru var)","multi":true,"options":[{"id":"a","ok":true,"md":"Trafiğin yolda okunamaması (gizlilik)","whyMd":"TLS trafiği şifreler."},{"id":"b","ok":true,"md":"Trafiğin yolda fark edilmeden değiştirilememesi (bütünlük)","whyMd":"TLS kayıtları bütünlük korumalıdır; değişiklik fark edilir."},{"id":"c","ok":true,"md":"Sunucunun kimliğinin sertifika ile doğrulanması","whyMd":"İstemci, sunucu sertifikasını güvenilir bir zincire karşı doğrular."},{"id":"d","ok":false,"md":"SQL injection ve IDOR gibi uygulama açıklarına karşı koruma","whyMd":"TLS sadece taşımayı korur; uygulama mantığındaki açıklara etkisi yoktur."}],"explanationMd":"HTTPS gereklidir ama yeterli değildir. Uygulama açıkları uygulama katmanında kapatılır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m9","category":"Güvenlik","label":"Uygulama güvenliği","level":"Başlangıç","bodyMd":"OWASP Top 10 2021 listesinde birinci sıradaki kategori hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Injection","whyMd":"Injection 2021'de üçüncü sıradadır."},{"id":"b","ok":true,"md":"Broken Access Control","whyMd":"Broken Access Control 2021'de birinci sıradadır ve 2025 sürümünde de birinciliğini korur."},{"id":"c","ok":false,"md":"Cryptographic Failures","whyMd":"Cryptographic Failures 2021'de ikinci sıradadır."},{"id":"d","ok":false,"md":"Server-Side Request Forgery","whyMd":"SSRF 2021'de onuncu sıradadır; 2025'te Broken Access Control altına alındı."}],"explanationMd":"Erişim kontrolü hataları (IDOR, eksik rol ve sahiplik kontrolü) web uygulamalarında en yaygın kritik risk olarak öne çıkıyor.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m10","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"Kullanıcının yetkileri arasında öneksiz `ADMIN` var. `@PreAuthorize(\"hasRole('ADMIN')\")` ile korunan metot çağrıldığında ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"Erişim verilir, çünkü rol adı eşleşiyor.","whyMd":"`hasRole` verilen ada `ROLE_` önekini ekleyerek karşılaştırır."},{"id":"b","ok":true,"md":"Erişim reddedilir, çünkü `hasRole` `ROLE_ADMIN` yetkisini arar.","whyMd":"Yetki listesinde `ROLE_ADMIN` olmadığı için AccessDeniedException fırlar ve 403 döner."},{"id":"c","ok":false,"md":"Uygulama başlarken hata verir.","whyMd":"Bu bir çalışma anı yetki kontrolüdür; başlangıçta hata vermez."},{"id":"d","ok":false,"md":"Spring iki biçimi de otomatik olarak kabul eder.","whyMd":"Spring öneksiz yetkiyi rol olarak kabul etmez; `hasAuthority('ADMIN')` gerekir."}],"explanationMd":"Rol için `hasRole('ADMIN')` ve `ROLE_ADMIN` yetkisi, öneksiz yetki ya da OAuth2 scope'ları için `hasAuthority(...)` kullanılır; resource server scope'ları `SCOPE_` önekiyle üretir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m11","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"`AccountService` içindeki korumasız `closeFromBatch()` metodu, aynı sınıftaki `@PreAuthorize(\"hasRole('ADMIN')\")` ile korunan `close()` metodunu doğrudan (`this` üzerinden) çağırıyor. Ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"Yetki kontrolü her zamanki gibi çalışır.","whyMd":"Method security AOP proxy'siyle çalışır; iç çağrı proxy'yi atlar."},{"id":"b","ok":true,"md":"Yetki kontrolü çalışmaz, çünkü çağrı Spring proxy'sinden geçmez.","whyMd":"Self-invocation proxy'yi atladığı için SpEL ifadesi değerlendirilmez."},{"id":"c","ok":false,"md":"Derleme hatası alınır.","whyMd":"Kod geçerli Java'dır; sorun çalışma anındaki proxy davranışıdır."},{"id":"d","ok":false,"md":"Spring çalışma anında `IllegalStateException` fırlatır.","whyMd":"Spring bu durumu fark etmez; sessizce kontrolsüz çalışır."}],"explanationMd":"Bu `@Transactional`'daki self-invocation tuzağının aynısıdır. Çözüm kontrolü ayrı bir bean'e taşımak ya da çağıran metodu da korumaktır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m12","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"`GET /api/v1/accounts/{id}` endpoint'inde IDOR'u önlemenin en doğru yolu hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Hesap id'lerini UUID yapmak","whyMd":"Tahmini zorlaştırır ama id sızarsa yetki kontrolü yine yoktur."},{"id":"b","ok":false,"md":"Endpoint'i `authenticated()` kuralıyla korumak","whyMd":"Giriş yapmış her kullanıcı geçer; sahiplik kontrol edilmez."},{"id":"c","ok":true,"md":"Hesabı `findByIdAndCustomerId(id, customerIdFromToken)` ile, müşteri kimliğini token'dan alarak sorgulamak","whyMd":"Sahiplik sunucuda, güvenilir kimlik kaynağıyla ve sorgunun içinde kontrol edilir."},{"id":"d","ok":false,"md":"Müşteri id'sini istemcinin gönderdiği bir header'dan alıp sorguya eklemek","whyMd":"İstemcinin gönderdiği değer değiştirilebilir; kimlik token'dan gelmelidir."}],"explanationMd":"BOLA (OWASP API1:2023) her nesne erişiminde sahiplik kontrolüyle önlenir; başkasına ait kaynakta 404 dönmek varlığı da gizler.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m13","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"Hangi durumda bir REST API için Spring Security CSRF korumasını kapatmak güvenlidir?","multi":false,"options":[{"id":"a","ok":false,"md":"API JSON döndüğü sürece her durumda","whyMd":"Cevap formatı belirleyici değildir; belirleyici olan kimlik bilgisinin otomatik gönderilip gönderilmediğidir."},{"id":"b","ok":false,"md":"Kimlik bilgisi tarayıcının otomatik gönderdiği bir cookie'de taşınıyorsa","whyMd":"Otomatik gönderilen cookie tam olarak CSRF'in kullandığı şeydir."},{"id":"c","ok":true,"md":"İstemciler kimliği her istekte `Authorization: Bearer` header'ına kendileri ekliyorsa ve cookie ile kimlik doğrulama yoksa","whyMd":"Kötü site, header'a token ekletemez; CSRF'in dayandığı mekanizma yoktur."},{"id":"d","ok":false,"md":"Session politikası `STATELESS` yapıldıysa, token nerede taşınırsa taşınsın","whyMd":"Token cookie'de taşınıyorsa stateless bir API de CSRF'e açıktır."}],"explanationMd":"Kural 'REST ise kapat' değil, 'kimlik bilgisi otomatik gitmiyorsa kapatılabilir'dir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m14","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"OAuth 2.0 ile JWT arasındaki ilişki için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"OAuth 2.0 eski, JWT ise onun yerini alan yeni kimlik doğrulama yöntemidir.","whyMd":"İkisi farklı katmanlardadır; biri diğerinin alternatifi değildir."},{"id":"b","ok":true,"md":"OAuth 2.0 token alma ve kullanma akışlarını tanımlayan bir protokoldür; JWT bir token formatıdır ve OAuth access token'ı JWT olabilir ama zorunlu değildir.","whyMd":"Protokol ile format ayrımı budur; opaque access token da OAuth'ta geçerlidir."},{"id":"c","ok":false,"md":"OAuth 2.0 access token'ı her zaman JWT'dir.","whyMd":"OAuth 2.0 token formatını belirlemez; opaque token'lar introspection ile doğrulanır."},{"id":"d","ok":false,"md":"JWT yalnızca OAuth 2.0 ile birlikte kullanılabilir.","whyMd":"JWT bağımsız bir formattır; OAuth olmadan da kullanılabilir."}],"explanationMd":"OAuth 2.0 (RFC 6749) rolleri ve akışları, JWT (RFC 7519) token'ın yapısını ve doğrulanmasını tanımlar.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m15","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"Refresh token akışı için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Refresh token her API isteğinde access token'la birlikte gönderilir.","whyMd":"Refresh token API'lere gönderilmez; sızıntı alanı büyür."},{"id":"b","ok":true,"md":"Refresh token sadece authorization server'ın token endpoint'ine `grant_type=refresh_token` ile gönderilir; rotation'da her kullanımda yeni bir refresh token verilir ve eskisi geçersiz olur.","whyMd":"Doğru akış budur; rotation çalınan token'ın tekrar kullanımını tespit etmeyi sağlar."},{"id":"c","ok":false,"md":"Refresh token'ın süresi olmamalıdır, böylece kullanıcı hiç çıkış yapmaz.","whyMd":"Süresiz refresh token, çalındığında sonsuza kadar yeni access token üretir."},{"id":"d","ok":false,"md":"Access token'ın süresi dolunca kullanıcı her zaman şifresini yeniden girmelidir.","whyMd":"Refresh token'ın amacı tam olarak yeniden login olmadan yeni access token almaktır."}],"explanationMd":"RFC 9700, public client'lar için refresh token'ın sender-constrained ya da rotation'lı olmasını şart koşar.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m16","category":"Güvenlik","label":"Uygulama güvenliği","level":"Orta","bodyMd":"OpenID Connect'teki ID token'ın doğru kullanımı hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"API'leri çağırırken bearer token olarak göndermek","whyMd":"API'ler access token kabul etmelidir; ID token client için üretilmiştir."},{"id":"b","ok":true,"md":"Client'ın, giriş yapan kullanıcının kimliğini öğrenmesi; `aud` değeri client id'sidir","whyMd":"ID token client'a kimin giriş yaptığını söyler ve client tarafından doğrulanır."},{"id":"c","ok":false,"md":"Refresh token yerine kullanmak","whyMd":"ID token yeni token almak için kullanılmaz."},{"id":"d","ok":false,"md":"Resource server'da scope kontrolü için kullanmak","whyMd":"Scope kontrolü access token üzerinden yapılır."}],"explanationMd":"ID token kimlik içindir ve client'a aittir; access token yetki içindir ve API'ye aittir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m17","category":"Güvenlik","label":"Uygulama güvenliği","level":"İleri","bodyMd":"RS256 ile imzalanan token'ları doğrulayan bir API'de saldırgan header'ı `alg: HS256` yapıp imzayı sunucunun public key'ini HMAC secret'ı olarak kullanarak üretiyor. En doğru savunma hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Public key'i gizli tutmak","whyMd":"Public key tanımı gereği paylaşılır (JWKS); gizlemek savunma değildir."},{"id":"b","ok":true,"md":"Kabul edilen algoritmayı sunucu yapılandırmasında sabitlemek ve doğrulayıcıyı token'ın `alg` header'ına göre seçmemek","whyMd":"RFC 8725, kabul edilen algoritmaların çağıran tarafından belirlenmesini şart koşar; saldırganın seçimi yok sayılır."},{"id":"c","ok":false,"md":"Token süresini kısaltmak","whyMd":"Kısa süre saldırının penceresini daraltır ama sahte token'ı engellemez."},{"id":"d","ok":false,"md":"Payload'u JWE ile şifrelemek","whyMd":"Şifreleme gizlilik sağlar; imza doğrulamasındaki algoritma karışıklığını çözmez."}],"explanationMd":"Spring'de `NimbusJwtDecoder.withJwkSetUri(...).jwsAlgorithm(SignatureAlgorithm.RS256)` ile algoritma sabitlenir.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m18","category":"Güvenlik","label":"Uygulama güvenliği","level":"İleri","bodyMd":"PKCE (RFC 7636) authorization code akışında hangi saldırıya karşı koruma sağlar?","multi":false,"options":[{"id":"a","ok":true,"md":"Authorization code'un ele geçirilip başka biri tarafından token'a çevrilmesi","whyMd":"Kodu çalan saldırgan, sadece client'ın bildiği code_verifier olmadan token alamaz."},{"id":"b","ok":false,"md":"Access token'ın süresinin dolması","whyMd":"PKCE token ömrüyle ilgili değildir."},{"id":"c","ok":false,"md":"SQL injection","whyMd":"PKCE bir OAuth akış korumasıdır; veritabanı sorgularıyla ilgisi yoktur."},{"id":"d","ok":false,"md":"Resource server'a gelen isteklerin rate limit'i aşması","whyMd":"Rate limiting ayrı bir mekanizmadır."}],"explanationMd":"Client rastgele bir verifier üretir, ilk istekte onun S256 özetini gönderir, token alırken orijinalini gösterir. RFC 9700'e göre public client'lar için zorunludur.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m19","category":"Güvenlik","label":"Uygulama güvenliği","level":"İleri","bodyMd":"Müşterinin hesabı ele geçirildi ve tüm token'larının hemen geçersiz olması gerekiyor. Aşağıdakilerden hangileri buna yardım eder? (Birden fazla doğru var)","multi":true,"options":[{"id":"a","ok":true,"md":"Müşterinin refresh token'larını sunucuda iptal etmek","whyMd":"Yeni access token üretilmesini durdurur."},{"id":"b","ok":true,"md":"Aktif access token'ların `jti` değerlerini kalan ömürleri kadar bir denylist'e eklemek ya da kullanıcı bazlı token sürümünü artırmak","whyMd":"Sunucuda durum tutarak hâlâ geçerli olan access token'ları reddettirir."},{"id":"c","ok":false,"md":"İstemciden token'ı yerel depodan silmesini istemek","whyMd":"Saldırgandaki kopyayı etkilemez; sunucu açısından hiçbir şey değişmez."},{"id":"d","ok":true,"md":"Access token ömrünü kısa tutarak iptal edilemeyen pencereyi daraltmak","whyMd":"İptal edilemeyen bir token'ın en kötü durumda ne kadar kullanılabileceğini sınırlar."}],"explanationMd":"JWT kendiliğinden iptal edilemez; kısa ömür, refresh token kontrolü ve gerektiğinde durum tutan bir kontrol birlikte kullanılır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m20","category":"Güvenlik","label":"Uygulama güvenliği","level":"İleri","bodyMd":"API gateway arkasındaki servisler için hangi tasarım en güvenlidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Gateway token'ı doğrular, servisler istemciden gelen `X-User-Id` header'ına koşulsuz güvenir.","whyMd":"İstemci aynı header'ı kendisi gönderebilir; gateway atlanırsa ya da header temizlenmezse kimlik taklidi olur."},{"id":"b","ok":true,"md":"Gateway token'ı doğrular ve kaba kuralları uygular; servisler token'ı yine doğrular ve nesne düzeyindeki yetkiyi kendileri kontrol eder, gateway dışından erişim ağ politikası ve mTLS ile engellenir.","whyMd":"Savunma katmanlıdır: gateway ortak kontrolleri, servisler iş kuralına bağlı yetkiyi üstlenir."},{"id":"c","ok":false,"md":"Servisler iç ağda olduğu için kimlik doğrulamayı tamamen kaldırmak","whyMd":"İç ağ güvenilir sayılmaz; bir servisin ele geçirilmesi her şeyi açar."},{"id":"d","ok":false,"md":"Token doğrulamasını sadece servislerde yapmak, gateway'de rate limiting'i kapatmak","whyMd":"Geçersiz trafiği kenarda durdurmamak ve kota uygulamamak arka uçları gereksiz yüke ve saldırıya açar."}],"explanationMd":"Gateway ortak güvenlik kontrollerini merkezileştirir ama tek savunma hattı değildir (zero trust).","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/guvenlik#m21","category":"Güvenlik","label":"Uygulama güvenliği","level":"İleri","bodyMd":"Kullanıcının verdiği URL'den resim indiren bir özellikte SSRF'e karşı en etkili önlem hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"URL'nin içinde `localhost` geçmediğini string olarak kontrol etmek","whyMd":"IP'nin farklı yazımları, IPv6, iç adrese çözülen domain'ler ve yönlendirmelerle atlatılır."},{"id":"b","ok":true,"md":"Host'u çözümleyip IP'nin özel, loopback ve link-local aralıklarda olmadığını doğrulamak, yönlendirmeleri kapatmak ve isteği iç ağa erişimi olmayan bir egress üzerinden yapmak","whyMd":"Uygulama ve ağ katmanında birlikte savunma yapar; yönlendirme ve iç adres yollarını kapatır."},{"id":"c","ok":false,"md":"Sadece HTTPS URL'lerine izin vermek","whyMd":"İç servisler de HTTPS konuşabilir; şema kontrolü hedefi sınırlamaz."},{"id":"d","ok":false,"md":"İndirilen içeriği kullanıcıya göstermemek","whyMd":"Kör SSRF'te de istek gönderilir; iç servislerde yan etki ve metadata erişimi yine olur."}],"explanationMd":"SSRF'e karşı allowlist, IP doğrulama, yönlendirmeleri kapatma ve egress kısıtı birlikte kullanılır.","links":[],"href":"/sorular/guvenlik/"},{"kind":"mcq","id":"sorular/ag-temelleri#m1","category":"Altyapı","label":"Ağ temelleri","level":"Başlangıç","bodyMd":"DNS sorguları neden çoğunlukla UDP kullanır?","multi":false,"options":[{"id":"a","ok":false,"md":"UDP şifreli olduğu için daha güvenlidir","whyMd":"UDP şifreleme sağlamaz; şifreli DNS için DoT ya da DoH kullanılır."},{"id":"b","ok":true,"md":"Sorgu ve cevap genelde küçük ve tek seferlik olduğu için bağlantı kurma maliyetine gerek yoktur","whyMd":"Tek bir küçük soru-cevap için TCP el sıkışması gereksiz gecikme olurdu."},{"id":"c","ok":false,"md":"TCP, DNS'in kullandığı 53 numaralı port'u desteklemez","whyMd":"DNS 53 numaralı port'ta TCP de kullanır; büyük cevaplarda ve zone transferinde TCP'ye geçilir."},{"id":"d","ok":false,"md":"UDP paket teslimini garanti eder","whyMd":"UDP teslim garantisi vermez; kayıp sorgu istemci tarafında yeniden gönderilir."}],"explanationMd":"DNS hız için UDP kullanır; cevap sığmazsa ya da zone transferi gerekiyorsa TCP'ye geçer.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m2","category":"Altyapı","label":"Ağ temelleri","level":"Başlangıç","bodyMd":"10.0.0.0/24 aralığında toplam kaç IP adresi vardır?","multi":false,"options":[{"id":"a","ok":false,"md":"24","whyMd":"24 ön ek uzunluğudur, adres sayısı değil."},{"id":"b","ok":false,"md":"254","whyMd":"254, ağ ve broadcast adresleri çıkarıldıktan sonra geleneksel olarak kullanılabilir host sayısıdır; toplam değil."},{"id":"c","ok":true,"md":"256","whyMd":"2^(32-24) = 2^8 = 256 adres."},{"id":"d","ok":false,"md":"65.536","whyMd":"65.536 bir /16 aralığının adres sayısıdır."}],"explanationMd":"Adres sayısı 2^(32 - ön ek) formülüyle bulunur. Bulutta bazı adresler ayrıca rezerve edilir.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m3","category":"Altyapı","label":"Ağ temelleri","level":"Başlangıç","bodyMd":"Aşağıdakilerden hangileri RFC 1918'de tanımlı özel IP aralıklarıdır?","multi":true,"options":[{"id":"a","ok":true,"md":"10.0.0.0/8","whyMd":"RFC 1918 özel aralıklarından biridir."},{"id":"b","ok":true,"md":"172.16.0.0/12","whyMd":"RFC 1918 özel aralıklarından biridir (172.16.0.0 ile 172.31.255.255 arası)."},{"id":"c","ok":false,"md":"8.8.8.0/24","whyMd":"Bu aralık Google'ın genel DNS adreslerini içerir; internette yönlendirilir."},{"id":"d","ok":true,"md":"192.168.0.0/16","whyMd":"RFC 1918 özel aralıklarından biridir; ev ağlarında yaygındır."}],"explanationMd":"Üç özel aralık vardır: 10/8, 172.16/12 ve 192.168/16. İnternette yönlendirilmezler, dışarı çıkış NAT ile olur.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m4","category":"Altyapı","label":"Ağ temelleri","level":"Başlangıç","bodyMd":"HTTPS'te sertifika doğrulamasının asıl amacı nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Trafiği sıkıştırarak hızlandırmak","whyMd":"Sertifikanın sıkıştırmayla ilgisi yoktur."},{"id":"b","ok":true,"md":"Bağlanılan sunucunun gerçekten o alan adının sahibi olduğunu kanıtlamak","whyMd":"Kimlik doğrulaması olmadan şifreli kanalı saldırganla da kurmak mümkündür; sertifika bunu önler."},{"id":"c","ok":false,"md":"Sunucunun yükünü azaltmak","whyMd":"Sertifika doğrulaması sunucunun yükünü azaltmaz."},{"id":"d","ok":false,"md":"İstemcinin IP adresini gizlemek","whyMd":"TLS istemcinin IP adresini gizlemez."}],"explanationMd":"TLS gizlilik, bütünlük ve kimlik doğrulama sağlar; sertifika kimlik doğrulama kısmıdır.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m5","category":"Altyapı","label":"Ağ temelleri","level":"Başlangıç","bodyMd":"Reverse proxy için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"İstemcilerin önünde durur ve onlar adına internete çıkar","whyMd":"Bu forward proxy'nin tanımıdır."},{"id":"b","ok":true,"md":"Sunucuların önünde durur; istemci arkadaki sunucuları görmeden onunla konuşur","whyMd":"Reverse proxy sunucu tarafının temsilcisidir; TLS sonlandırma, yönlendirme ve cache gibi işler yapar."},{"id":"c","ok":false,"md":"Sadece statik dosya sunmak için kullanılır","whyMd":"Statik dosya sunabilir ama işlevi bununla sınırlı değildir."},{"id":"d","ok":false,"md":"TLS trafiğini hiçbir zaman sonlandıramaz","whyMd":"Reverse proxy'ler TLS'i sık sık sonlandırır."}],"explanationMd":"Forward proxy istemcinin, reverse proxy sunucunun adına çalışır.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m6","category":"Altyapı","label":"Ağ temelleri","level":"Orta","bodyMd":"HTTP/2'de tek bir TCP paketinin kaybolması ne sonuç doğurur?","multi":false,"options":[{"id":"a","ok":false,"md":"Sadece o paketin ait olduğu akış bekler","whyMd":"Bu HTTP/3 (QUIC) davranışıdır; HTTP/2 tek TCP akışı üzerindedir."},{"id":"b","ok":true,"md":"Paket yeniden gelene kadar o bağlantıdaki tüm akışlar bekler","whyMd":"TCP sıralı teslim garantisi verdiği için kayıp paket gelene kadar arkasındaki tüm veri bekletilir."},{"id":"c","ok":false,"md":"Bağlantı otomatik olarak HTTP/3'e geçer","whyMd":"Böyle otomatik bir geçiş yoktur; HTTP/3 ayrıca keşfedilir ve kullanılır."},{"id":"d","ok":false,"md":"Hiçbir etkisi olmaz çünkü HTTP/2 kaybı tolere eder","whyMd":"TCP kaybı yeniden gönderimle çözer ama bu bekleme yaratır."}],"explanationMd":"HTTP/2 uygulama katmanındaki head-of-line blocking'i çözdü ama TCP seviyesindekini çözemedi; HTTP/3 bunu QUIC ile çözer.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m7","category":"Altyapı","label":"Ağ temelleri","level":"Orta","bodyMd":"Kubernetes'te gRPC istemcisi, L4 load balancer arkasındaki üç pod'dan sadece birine trafik gönderiyor. En olası sebep nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Diğer iki pod'un readiness probe'u başarısız","whyMd":"Mümkündür ama pod'lar sağlıklıysa ve sorun sürüyorsa asıl sebep bağlantı bazında dağıtımdır."},{"id":"b","ok":true,"md":"gRPC tek uzun ömürlü HTTP/2 bağlantısı kullandığı için L4 dağıtım bağlantı bazında yapılıyor","whyMd":"L4 bağlantıyı bir pod'a bağlar; tüm istekler o bağlantıdan geçtiği için yük tek pod'da toplanır."},{"id":"c","ok":false,"md":"gRPC UDP kullandığı için load balancer trafiği dağıtamıyor","whyMd":"gRPC HTTP/2 üzerinde, yani TCP üzerinde çalışır."},{"id":"d","ok":false,"md":"Pod'ların CPU limitleri farklı","whyMd":"CPU limitleri trafik dağıtımını belirlemez."}],"explanationMd":"Çözüm L7 (istek bazında) dengeleme, service mesh ya da istemci tarafı dengelemedir.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m8","category":"Altyapı","label":"Ağ temelleri","level":"Orta","bodyMd":"Bir HTTP istemcisinde hangi süre sınırları ayrı ayrı ayarlanmalıdır?","multi":true,"options":[{"id":"a","ok":true,"md":"Bağlantı kurma (connect) timeout'u","whyMd":"Erişilemeyen hedefte hızlı vazgeçmeyi sağlar."},{"id":"b","ok":true,"md":"Cevap bekleme (read) timeout'u","whyMd":"Yavaş cevap veren hedefte thread'in sonsuza kadar beklemesini engeller."},{"id":"c","ok":true,"md":"Havuzdan bağlantı alma timeout'u","whyMd":"Havuz doluyken isteklerin sınırsız sırada beklemesini engeller."},{"id":"d","ok":false,"md":"Hiçbiri; varsayılan değerler production için uygundur","whyMd":"Birçok kütüphanede varsayılanlar sonsuz ya da çok uzundur; açıkça ayarlanmalıdır."}],"explanationMd":"Üç süre de ayrı arızalara karşı korur; toplam süre ayrıca çağıranın verdiği süreden kısa olmalıdır.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m9","category":"Altyapı","label":"Ağ temelleri","level":"Orta","bodyMd":"Bir servis birkaç dakika boşta kaldıktan sonraki ilk istekte 'connection reset' alıyor. En olası sebep nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Sunucunun belleği dolmuş","whyMd":"Bellek sorunu sadece boşta kalma sonrası ilk istekte görülen bir örüntü üretmez."},{"id":"b","ok":true,"md":"Aradaki load balancer ya da sunucu boşta kalan bağlantıyı kapatmış, istemci havuzu ise onu yeniden kullanmaya çalışmış","whyMd":"Idle timeout uyumsuzluğunun klasik belirtisidir; havuzdaki bağlantı ömrü aradaki cihazlarınkinden kısa olmalıdır."},{"id":"c","ok":false,"md":"DNS kaydı değişmiş","whyMd":"DNS değişikliği yeni bağlantılarda farklı hata üretir, reset değil."},{"id":"d","ok":false,"md":"Sertifikanın süresi dolmuş","whyMd":"Süresi dolan sertifika TLS el sıkışma hatası verir, her istekte görülür."}],"explanationMd":"Havuzun boşta kalma ve maksimum ömür ayarları, aradaki her cihazın idle timeout'undan kısa tutulmalıdır.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m10","category":"Altyapı","label":"Ağ temelleri","level":"İleri","bodyMd":"TLS 1.3 hakkında hangileri doğrudur?","multi":true,"options":[{"id":"a","ok":true,"md":"Tam el sıkışma bir turda (1-RTT) tamamlanır","whyMd":"İstemci anahtar paylaşımını ilk mesajda gönderdiği için el sıkışma tek turda biter."},{"id":"b","ok":true,"md":"Anahtar değişimi her zaman geçici Diffie-Hellman ile yapılır, bu yüzden forward secrecy vardır","whyMd":"Geçici anahtarlar sayesinde sunucunun özel anahtarı sonradan çalınsa bile geçmiş trafik çözülemez."},{"id":"c","ok":false,"md":"RSA ile anahtar taşıma (key transport) hâlâ desteklenir","whyMd":"RSA anahtar taşıma TLS 1.3'te kaldırılmıştır."},{"id":"d","ok":true,"md":"0-RTT verisi tekrar oynatılabildiği için yalnızca idempotent istekler için uygundur","whyMd":"0-RTT verisi replay'e açıktır; para hareketi gibi işlemlerde kullanılmamalıdır."}],"explanationMd":"TLS 1.3 el sıkışmayı kısalttı, forward secrecy'yi zorunlu yaptı ve 0-RTT'yi replay riskiyle birlikte getirdi.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m11","category":"Altyapı","label":"Ağ temelleri","level":"İleri","bodyMd":"Bir istemcide çok sayıda TIME_WAIT bağlantısı ve 'cannot assign requested address' hatası görülüyor. İlk yapılması gereken nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Kernel'de tcp_tw_reuse ayarını açmak","whyMd":"Kernel ayarları son çaredir; kök sebebi çözmez."},{"id":"b","ok":false,"md":"Sunucuyu yeniden başlatmak","whyMd":"Geçici rahatlama sağlar, sorun yük gelince geri döner."},{"id":"c","ok":true,"md":"Bağlantıların yeniden kullanılmasını sağlamak: keep-alive ve doğru yapılandırılmış bir bağlantı havuzu","whyMd":"Kök sebep her istekte yeni bağlantı açılmasıdır; yeniden kullanım TIME_WAIT üretimini büyük ölçüde azaltır."},{"id":"d","ok":false,"md":"Read timeout'u artırmak","whyMd":"Timeout süresi port tükenmesini etkilemez."}],"explanationMd":"TIME_WAIT TCP'nin doğruluk mekanizmasıdır; sorun onun gereğinden fazla üretilmesidir.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/ag-temelleri#m12","category":"Altyapı","label":"Ağ temelleri","level":"İleri","bodyMd":"Kimlik doğrulamalı bir API cevabının CDN üzerinden başka kullanıcılara sızmasını önlemek için hangileri doğru önlemlerdir?","multi":true,"options":[{"id":"a","ok":true,"md":"Kişiye özel cevaplarda Cache-Control: private, no-store göndermek","whyMd":"Paylaşılan cache'lerin bu cevabı saklamamasını söyler."},{"id":"b","ok":true,"md":"CDN'i Authorization başlığı içeren istekleri cache'lemeyecek şekilde yapılandırmak","whyMd":"Kimlik bilgisi taşıyan istekleri cache dışında tutar."},{"id":"c","ok":false,"md":"Cache süresini 5 saniyeye düşürmek yeterlidir","whyMd":"5 saniye de sızıntı için yeterlidir; süre kısaltmak sorunu çözmez."},{"id":"d","ok":true,"md":"Cache anahtarına hangi başlık ve parametrelerin girdiğini bilinçli belirlemek","whyMd":"Yanlış cache anahtarı farklı kullanıcıların isteklerini aynı kayda düşürür."}],"explanationMd":"Kişiye özel veri paylaşılan cache'e hiç girmemelidir; süreyi kısaltmak bir önlem değildir.","links":[],"href":"/sorular/ag-temelleri/"},{"kind":"mcq","id":"sorular/aws-giris#m1","category":"Altyapı","label":"AWS'ye giriş","level":"Başlangıç","bodyMd":"Bir ECS servisinin S3'e erişmesi için en doğru yöntem hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Bir IAM user oluşturup access key'i ortam değişkenine koymak","whyMd":"Uzun ömürlü anahtarlar sızma riski taşır ve elle döndürülmesi gerekir."},{"id":"b","ok":true,"md":"Task'a gerekli izinleri olan bir IAM role (task role) atamak","whyMd":"Task role kısa ömürlü kimlik bilgisi verir ve SDK bunu otomatik alır."},{"id":"c","ok":false,"md":"Access key'i application.yml içine yazıp dosyayı Git'e eklememek","whyMd":"Anahtar yine kalıcıdır; image ya da log yoluyla sızabilir."},{"id":"d","ok":false,"md":"Bucket'ı public yapmak","whyMd":"Bucket'ı public yapmak veri sızıntısına yol açar."}],"explanationMd":"AWS içinde çalışan uygulamalar kalıcı anahtar yerine role ile erişir.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m2","category":"Altyapı","label":"AWS'ye giriş","level":"Başlangıç","bodyMd":"Security group için hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"Durumsuzdur; dönüş trafiği için ayrıca kural yazmak gerekir","whyMd":"Bu Network ACL'nin özelliğidir."},{"id":"b","ok":false,"md":"Hem izin hem ret kuralı içerebilir","whyMd":"Security group'ta sadece izin kuralı vardır; ret kuralı NACL'de yazılır."},{"id":"c","ok":true,"md":"Durumludur; izin verilen bağlantının dönüş trafiği otomatik geçer","whyMd":"Security group durumludur ve kaynak seviyesinde çalışır."},{"id":"d","ok":false,"md":"Subnet seviyesinde uygulanır","whyMd":"Security group ağ arayüzüne bağlanır; subnet seviyesindeki NACL'dir."}],"explanationMd":"Security group durumlu ve sadece izin kuralı içerir; NACL durumsuz ve subnet seviyesindedir.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m3","category":"Altyapı","label":"AWS'ye giriş","level":"Başlangıç","bodyMd":"Private subnet'teki bir uygulama sunucusu internetteki bir API'yi nasıl çağırır?","multi":false,"options":[{"id":"a","ok":false,"md":"Doğrudan Internet Gateway üzerinden, genel IP olmadan","whyMd":"Internet Gateway genel IP'si olmayan kaynakların trafiğini iletmez; private subnet'in route'u da IGW'ye gitmez."},{"id":"b","ok":true,"md":"Public subnet'teki bir NAT gateway üzerinden","whyMd":"NAT gateway kaynak adresi kendi genel IP'siyle değiştirerek dışarı çıkışı sağlar."},{"id":"c","ok":false,"md":"VPC peering ile","whyMd":"VPC peering iki VPC'yi birbirine bağlar, internete çıkış sağlamaz."},{"id":"d","ok":false,"md":"Private subnet'ten internete çıkmak mümkün değildir","whyMd":"NAT gateway ile dışarı çıkış mümkündür; sadece dışarıdan içeri doğrudan erişim yoktur."}],"explanationMd":"Private subnet'in varsayılan route'u NAT gateway'e gider; NAT public subnet'te durur.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m4","category":"Altyapı","label":"AWS'ye giriş","level":"Başlangıç","bodyMd":"Sürekli trafik alan, gecikmeye hassas bir Spring Boot REST API'si için en uygun başlangıç seçeneği genelde hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Her endpoint için ayrı bir Lambda fonksiyonu","whyMd":"Mümkündür ama Java cold start'ı ve istek başına ücret sürekli trafikte genelde avantajlı değildir."},{"id":"b","ok":true,"md":"ECS Fargate ya da EKS üzerinde birden çok AZ'de çalışan container'lar","whyMd":"Uzun yaşayan süreç modeline uygundur, çok AZ'li ve ölçeklenebilirdir."},{"id":"c","ok":false,"md":"Tek bir büyük EC2 instance","whyMd":"Tek instance tek arıza noktasıdır."},{"id":"d","ok":false,"md":"S3 static website hosting","whyMd":"S3 static hosting sunucu tarafı kod çalıştıramaz."}],"explanationMd":"Spring Boot uzun yaşayan bir süreç olarak tasarlanır; container tabanlı çok AZ'li dağıtım doğal seçimdir.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m5","category":"Altyapı","label":"AWS'ye giriş","level":"Orta","bodyMd":"RDS Multi-AZ (klasik instance dağıtımı) için hangileri doğrudur?","multi":true,"options":[{"id":"a","ok":true,"md":"Başka bir AZ'de senkron güncellenen bir yedek tutar","whyMd":"Multi-AZ'de yedek senkron güncellenir; failover'da veri kaybı olmaz."},{"id":"b","ok":false,"md":"Yedek instance okuma trafiği almak için kullanılabilir","whyMd":"Klasik Multi-AZ instance dağıtımında yedek okunamaz; okuma için read replica ya da Multi-AZ DB cluster gerekir."},{"id":"c","ok":true,"md":"Primary arızalandığında otomatik failover yapılır ve endpoint yeni primary'yi gösterir","whyMd":"Failover otomatiktir ve DNS kaydı yeni primary'ye döner."},{"id":"d","ok":false,"md":"Yanlışlıkla silinen veriyi geri getirmek için yeterlidir","whyMd":"Silme işlemi de yedeğe senkron gider; geri getirmek için yedek ya da point-in-time recovery gerekir."}],"explanationMd":"Multi-AZ erişilebilirlik içindir; okuma ölçeği ve veri kurtarma ayrı çözümler ister.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m6","category":"Altyapı","label":"AWS'ye giriş","level":"Orta","bodyMd":"SQS standard kuyruk için hangileri doğrudur?","multi":true,"options":[{"id":"a","ok":true,"md":"Bir mesaj birden fazla kez teslim edilebilir","whyMd":"Standard kuyruk en az bir kez teslim eder; tüketici idempotent olmalıdır."},{"id":"b","ok":false,"md":"Mesajların gönderildiği sırayla işlenmesini garanti eder","whyMd":"Standard kuyruk sıra garantisi vermez; sıra için FIFO kuyruk gerekir."},{"id":"c","ok":true,"md":"Visibility timeout dolmadan silinmeyen mesaj tekrar görünür olur","whyMd":"Silme işlemi yapılmazsa mesaj süre sonunda başka bir tüketiciye açılır."},{"id":"d","ok":true,"md":"maxReceiveCount aşıldığında mesaj yapılandırılmış DLQ'ya taşınabilir","whyMd":"Redrive policy ile başarısız mesajlar DLQ'ya taşınır."}],"explanationMd":"Standard kuyrukta tekrar ve sırasızlık normaldir; tasarım bunlara göre yapılır.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m7","category":"Altyapı","label":"AWS'ye giriş","level":"Orta","bodyMd":"Bir olayı bildirim, fraud ve raporlama servislerinin bağımsız olarak işlemesi gerekiyor. Hangi desen en uygundur?","multi":false,"options":[{"id":"a","ok":false,"md":"Tek bir SQS kuyruğu ve üç servisin aynı kuyruktan okuması","whyMd":"Aynı kuyruktan okuyan tüketiciler mesajları paylaşır; her mesajı sadece biri işler."},{"id":"b","ok":true,"md":"SNS topic'i ve her servis için ayrı bir SQS kuyruğu (fan-out)","whyMd":"Her servis kendi kuyruğundan kendi hızında tüketir; biri yavaşlarsa diğerleri etkilenmez."},{"id":"c","ok":false,"md":"Olayı veritabanına yazıp servislerin tabloyu sürekli sorgulaması","whyMd":"Polling gecikme ve veritabanı yükü yaratır."},{"id":"d","ok":false,"md":"Üretici servisin üç servisi sırayla senkron çağırması","whyMd":"Senkron zincir bağımlılığı artırır; bir servisin hatası üreticiyi etkiler."}],"explanationMd":"SNS'ten SQS'e fan-out, bir olayı birden çok bağımsız tüketiciye dağıtmanın standart yoludur.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m8","category":"Altyapı","label":"AWS'ye giriş","level":"Orta","bodyMd":"Java ile yazılmış bir Lambda fonksiyonunda cold start süresini azaltmak için hangileri işe yarar?","multi":true,"options":[{"id":"a","ok":true,"md":"SnapStart'ı etkinleştirmek","whyMd":"Başlatılmış ortamın anlık görüntüsünden devam ederek başlatma süresini kısaltır."},{"id":"b","ok":true,"md":"Provisioned concurrency kullanmak","whyMd":"Ortamları önceden hazır tutar; boşta da ücretlenir."},{"id":"c","ok":false,"md":"SDK client'larını ve bağlantıları her çağrıda handler içinde yeniden oluşturmak","whyMd":"Bu her çağrıyı yavaşlatır; client'lar handler dışında bir kez oluşturulup yeniden kullanılmalıdır."},{"id":"d","ok":true,"md":"Bağımlılıkları ve başlangıçta yapılan işi azaltmak","whyMd":"Daha az sınıf yükleme ve daha hafif başlangıç cold start'ı kısaltır."}],"explanationMd":"Cold start'ı azaltmanın yolları başlangıç işini küçültmek, anlık görüntü ve önceden ısıtılmış ortamlardır.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m9","category":"Altyapı","label":"AWS'ye giriş","level":"Orta","bodyMd":"Private subnet'teki servislerin S3'e yaptığı yoğun trafik NAT gateway maliyetini artırıyor. En doğrudan çözüm hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Servisleri public subnet'e taşımak","whyMd":"Saldırı yüzeyini gereksiz yere büyütür."},{"id":"b","ok":true,"md":"S3 için bir gateway VPC endpoint eklemek","whyMd":"S3 gateway endpoint ücretsizdir ve trafiği NAT'tan geçirmeden AWS ağı içinde tutar."},{"id":"c","ok":false,"md":"NAT gateway sayısını artırmak","whyMd":"Daha fazla NAT daha fazla saatlik ücret demektir; işlenen veri ücreti de sürer."},{"id":"d","ok":false,"md":"S3 yerine EBS kullanmak","whyMd":"EBS tek bir instance'a bağlı blok depolamadır, S3'ün yerini tutmaz."}],"explanationMd":"S3 ve DynamoDB için gateway endpoint'ler ücretsizdir; diğer servisler için interface endpoint maliyeti NAT ile karşılaştırılır.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m10","category":"Altyapı","label":"AWS'ye giriş","level":"İleri","bodyMd":"GitHub Actions'tan OIDC ile üstlenilen bir prod deploy role'ünün trust policy'si için hangileri doğru uygulamalardır?","multi":true,"options":[{"id":"a","ok":true,"md":"sub koşulunu belirli repo ve prod environment ile sınırlamak","whyMd":"Sadece onaylı prod environment'ından gelen çalıştırmalar role'ü üstlenebilir."},{"id":"b","ok":false,"md":"sub koşulunu repo:org/* olarak bırakmak, yönetimi kolaylaştırır","whyMd":"Organizasyondaki herhangi bir repo prod role'ünü üstlenebilir hâle gelir."},{"id":"c","ok":true,"md":"aud koşulunu sts.amazonaws.com olarak doğrulamak","whyMd":"Belirtecin AWS için üretildiğini doğrular."},{"id":"d","ok":true,"md":"Role'e IAM politikalarını değiştirme yetkisi vermemek","whyMd":"IAM değiştirebilen bir pipeline kendine her yetkiyi verebilir."}],"explanationMd":"OIDC'nin güvenliği trust policy'deki koşulların darlığına bağlıdır.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m11","category":"Altyapı","label":"AWS'ye giriş","level":"İleri","bodyMd":"DynamoDB'de aynı transferId ile gelen tekrarlı isteklerin ikinci kez kayıt oluşturmasını önlemenin doğru yolu hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Yazmadan önce GetItem ile kontrol edip yoksa PutItem yapmak","whyMd":"Kontrol ve yazma arasında yarış durumu vardır; iki istek aynı anda kontrolü geçebilir."},{"id":"b","ok":true,"md":"PutItem'ı attribute_not_exists(pk) koşuluyla yapmak ve ConditionalCheckFailedException'ı tekrar olarak ele almak","whyMd":"Koşullu yazma atomiktir; ilk yazma kabul edilir, tekrarı reddedilir."},{"id":"c","ok":false,"md":"Scan ile tüm tabloda transferId'yi aramak","whyMd":"Scan pahalıdır ve yarış durumunu çözmez."},{"id":"d","ok":false,"md":"GSI üzerinden kontrol edip sonra yazmak","whyMd":"GSI asenkron güncellenir; yeni yazılan kayıt hemen görünmeyebilir."}],"explanationMd":"Idempotency kontrolü ve yazma tek bir atomik işlemde yapılmalıdır.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/aws-giris#m12","category":"Altyapı","label":"AWS'ye giriş","level":"İleri","bodyMd":"Bir geliştirici yanlışlıkla production tablosundan kayıt sildi. Aşağıdakilerden hangisi veriyi geri getirmeye yardımcı OLMAZ?","multi":false,"options":[{"id":"a","ok":false,"md":"RDS point-in-time recovery","whyMd":"Silmeden önceki bir ana geri dönülebilir."},{"id":"b","ok":false,"md":"Otomatik ya da manuel veritabanı snapshot'ı","whyMd":"Snapshot alındığı andaki veriyi içerir."},{"id":"c","ok":true,"md":"Multi-AZ senkron yedek","whyMd":"Silme işlemi senkron olarak yedeğe de uygulanır; yedek de aynı veriyi kaybetmiştir."},{"id":"d","ok":false,"md":"Başka bir hesaba kopyalanmış değiştirilemez yedek","whyMd":"Değiştirilemez ve ayrı hesaptaki yedek insan hatasına ve saldırıya karşı en güçlü korumadır."}],"explanationMd":"Replikasyon erişilebilirlik sağlar, yedekleme değildir; insan hatasına karşı zaman içinde geri dönülebilen yedekler gerekir.","links":[],"href":"/sorular/aws-giris/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m1","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Başlangıç","bodyMd":"`Integer a = 128; Integer b = 128;` için `a == b` ve `a.equals(b)` varsayılan JVM ayarlarıyla ne döndürür?","multi":false,"options":[{"id":"a","ok":false,"md":"true, true","whyMd":"Autoboxing `Integer.valueOf` kullanır ve varsayılan olarak yalnızca -128 ile 127 arası önbelleklenir; 128 için iki ayrı nesne oluşur."},{"id":"b","ok":true,"md":"false, true","whyMd":"İki ayrı `Integer` nesnesi olduğu için `==` false, değerleri eşit olduğu için `equals` true döner."},{"id":"c","ok":false,"md":"false, false","whyMd":"`Integer.equals` değeri karşılaştırır; değerler eşit olduğu için true döner."},{"id":"d","ok":false,"md":"Derleme hatası verir","whyMd":"Kod geçerlidir; `Integer` nesneleri `==` ile karşılaştırılabilir."}],"explanationMd":"Wrapper nesnelerini `==` ile karşılaştırmak referans karşılaştırmasıdır; 127'ye kadar çalışması Integer cache'in bir yan etkisidir, sözleşme değildir.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m2","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"Java 21'de `HashMap`'in bir bucket'ı hangi koşulda bağlı listeden kırmızı-siyah ağaca dönüşür?","multi":false,"options":[{"id":"a","ok":false,"md":"Bucket'taki düğüm sayısı 8 eşiğini aştığında, tablo kapasitesinden bağımsız olarak","whyMd":"Tablo 64'ten küçükse ağaç yerine tablo büyütülür (`MIN_TREEIFY_CAPACITY`)."},{"id":"b","ok":true,"md":"Bucket'taki düğüm sayısı 8 eşiğini aştığında ve tablo kapasitesi en az 64 olduğunda","whyMd":"`TREEIFY_THRESHOLD` 8 ve `MIN_TREEIFY_CAPACITY` 64; ikisi birlikte sağlanınca bucket ağaca döner."},{"id":"c","ok":false,"md":"Tablo doluluğu load factor'ı (0,75) aştığında tüm bucket'lar ağaca dönüşür","whyMd":"Load factor aşılınca resize olur; ağaç dönüşümü bucket bazında ve ayrı bir eşiktir."},{"id":"d","ok":false,"md":"Key sınıfı `Comparable` olduğunda her bucket baştan ağaç olarak oluşturulur","whyMd":"`Comparable` sadece ağaç içindeki sıralamaya yardım eder; bucket'lar liste olarak başlar."}],"explanationMd":"Treeify, kötü dağılan hash'lere karşı en kötü durumu O(log n)'e sınırlar; tablo küçükse sorun büyük ihtimalle tablonun küçüklüğüdür ve önce büyütülür.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m3","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"`HashMap`'in varsayılan load factor'ının 0,75 olmasının en doğru gerekçesi hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"0,75 ile her bucket'ta en fazla bir eleman olması garanti edilir","whyMd":"Hiçbir load factor çakışmasızlık garanti etmez; sadece olasılığı düşürür."},{"id":"b","ok":true,"md":"Bellek kullanımı ile çakışma (arama maliyeti) arasında iyi bir denge sağlar; rastgele hash'lerde bucket doluluğu ortalaması yaklaşık 0,5 olan Poisson dağılımına uyar ve zincirlerin çoğu 0 ya da 1 uzunluktadır","whyMd":"Javadoc'taki zaman/alan dengesi ve kaynak koddaki Poisson analizi bu gerekçeyi verir."},{"id":"c","ok":false,"md":"0,75 değeri kırmızı-siyah ağacın dengesi için matematiksel olarak gereklidir","whyMd":"Load factor tablo büyütme eşiğidir; ağacın dengesiyle ilgisi yoktur."},{"id":"d","ok":false,"md":"Daha yüksek değerler `HashMap` tarafından desteklenmez","whyMd":"`HashMap` 1'den büyük load factor'ı da kabul eder; zincirler uzar ama çalışır."}],"explanationMd":"0,75'te ortalama doluluk büyütmelerle birlikte yaklaşık 0,5 civarında kalır; bu da çoğu `get`'in bir iki karşılaştırmayla bittiği anlamına gelir.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m4","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"İleri","bodyMd":"Aşağıdakilerden hangileri Java Memory Model'e göre happens-before ilişkisi kurar? (Birden fazla doğru var.)","multi":true,"options":[{"id":"a","ok":true,"md":"Bir `volatile` alana yazma ile aynı alanın sonraki okuması","whyMd":"Volatile yazma, aynı değişkenin sonraki okumasından happens-before'dur."},{"id":"b","ok":true,"md":"Bir monitörün `unlock`'u ile aynı monitörün sonraki `lock`'u","whyMd":"Monitör kuralı: unlock, aynı monitörü sonradan alan lock'tan önce olur."},{"id":"c","ok":false,"md":"İki thread'in aynı volatile olmayan alana sırayla yazması","whyMd":"Volatile olmayan alana senkronizasyonsuz yazmalar data race'tir; aralarında happens-before yoktur."},{"id":"d","ok":true,"md":"`Thread.start()` çağrısı ile başlatılan thread'in ilk işlemi","whyMd":"`start()` çağrısından önceki işlemler başlatılan thread tarafından görünür."}],"explanationMd":"JMM garantileri sezgiye değil bu kurallara dayanır; kural yoksa görünürlük ve sıralama garantisi de yoktur.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m5","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Başlangıç","bodyMd":"`@Repository`'yi `@Component`'ten davranış olarak ayıran şey nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Hiçbir fark yoktur, ikisi tamamen aynıdır","whyMd":"`PersistenceExceptionTranslationPostProcessor` yalnızca `@Repository` bean'lerine exception translation ekler."},{"id":"b","ok":false,"md":"`@Repository` bean'leri otomatik olarak transactional olur","whyMd":"Transaction davranışı `@Transactional` ile gelir; stereotype transaction açmaz."},{"id":"c","ok":true,"md":"`@Repository` bean'lerinde persistence exception'ları Spring'in `DataAccessException` hiyerarşisine çevrilir","whyMd":"Exception translation, `@Repository`'nin somut davranış farkıdır."},{"id":"d","ok":false,"md":"`@Repository` bean'leri prototype scope ile oluşturulur","whyMd":"Stereotype anotasyonları scope belirlemez; varsayılan singleton'dır."}],"explanationMd":"`@Service` anlamsal bir etikettir; `@Repository` ise bir `BeanPostProcessor` aracılığıyla exception translation alır.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m6","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"Bir singleton servise field injection ile prototype scope'lu bir bean enjekte edildi. Servisin metotları çağrıldıkça ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"Her metot çağrısında yeni bir prototype nesnesi oluşturulur","whyMd":"Yeni nesne için `ObjectProvider`, `@Lookup` ya da scoped proxy gerekir."},{"id":"b","ok":true,"md":"Singleton bir kez oluşturulduğu için injection bir kez yapılır ve hep aynı prototype nesnesi kullanılır","whyMd":"Injection, singleton oluşturulurken bir kez yapılır; prototype fiilen singleton gibi davranır."},{"id":"c","ok":false,"md":"Spring açılışta hata verir, prototype singleton'a enjekte edilemez","whyMd":"Bu enjeksiyon geçerlidir, sadece beklenen sonucu vermez."},{"id":"d","ok":false,"md":"Her thread için ayrı bir prototype nesnesi oluşturulur","whyMd":"Thread başına nesne prototype'ın değil, thread scope'un ya da `ThreadLocal`'ın davranışıdır."}],"explanationMd":"Kısa ömürlü bir bean'i uzun ömürlü bir bean'e enjekte ederken her erişimde yeniden çözümleme yapan bir mekanizma gerekir.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m7","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"Aynı sınıftaki `@Transactional` olmayan `process()` metodu, aynı sınıftaki `@Transactional` `save()` metodunu `this.save()` ile çağırıyor. Ne olur?","multi":false,"options":[{"id":"a","ok":false,"md":"`save()` kendi transaction'ını açar","whyMd":"Transaction'ı proxy açar; `this` üzerinden çağrı doğrudan hedef nesneye gider."},{"id":"b","ok":true,"md":"Çağrı proxy'den geçmediği için `save()` için transaction açılmaz","whyMd":"Self-invocation proxy'yi atlar, interceptor çalışmaz."},{"id":"c","ok":false,"md":"Spring bu durumu açılışta tespit edip hata verir","whyMd":"Spring bunu tespit etmez; hata sessizdir ve genelde production'da fark edilir."},{"id":"d","ok":false,"md":"Transaction açılır ama checked exception'larda rollback olmaz","whyMd":"Transaction hiç açılmadığı için rollback kuralı da devreye girmez."}],"explanationMd":"Çözüm metodu ayrı bir bean'e taşımak ya da `TransactionTemplate` ile programatik transaction kullanmaktır.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m8","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"`@Transactional` (varsayılan ayarlarla) bir metot `java.io.IOException` (checked) fırlatıyor. Varsayılan davranış nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Transaction rollback edilir","whyMd":"Varsayılan kural yalnızca `RuntimeException` ve `Error` için rollback yapar."},{"id":"b","ok":true,"md":"Transaction commit edilir","whyMd":"Checked exception'lar varsayılan olarak commit'e yol açar; `rollbackFor` ile değiştirilir."},{"id":"c","ok":false,"md":"Transaction rollback-only işaretlenir ve açık kalır","whyMd":"Rollback-only işareti, katılınan bir transaction'da rollback kuralı tetiklendiğinde konur; burada kural tetiklenmez."},{"id":"d","ok":false,"md":"Spring exception'ı yutar ve metot normal döner","whyMd":"Exception çağırana iletilir; Spring yutmaz."}],"explanationMd":"Bu varsayılan EJB geleneğinden gelir; Spring Framework 6.2 ile global olarak değiştirmek de mümkündür.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m9","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"Bir JWT hakkında aşağıdakilerden hangisi doğrudur?","multi":false,"options":[{"id":"a","ok":false,"md":"JWT şifrelenmiştir, payload'ı sadece sunucu okuyabilir","whyMd":"Yaygın kullanılan JWT'ler JWS'tir (imzalı); şifreleme için ayrıca JWE gerekir."},{"id":"b","ok":true,"md":"İmzalı bir JWT'nin payload'ı base64url ile kodlanmıştır ve herkes tarafından okunabilir; imza sadece değiştirilmediğini kanıtlar","whyMd":"Kodlama gizlilik sağlamaz; imza bütünlük ve kaynak doğrulaması sağlar."},{"id":"c","ok":false,"md":"JWT, OAuth 2.0'ın yerine geçen bir yetkilendirme protokolüdür","whyMd":"JWT bir token formatıdır; OAuth bir yetkilendirme çerçevesidir ve token'ı JWT olabilir."},{"id":"d","ok":false,"md":"JWT, istemci tarafında silindiğinde sunucu tarafında da geçersiz olur","whyMd":"Sunucu token'ı yerel doğrular; istemcide silmek kopyalanmış bir token'ı geçersiz kılmaz."}],"explanationMd":"JWT'ye hassas veri koyulmaz; iptal için kısa süre, refresh token iptali ya da denylist gerekir.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m10","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"İleri","bodyMd":"Refresh token rotation ve reuse detection kullanan bir sistemde, daha önce kullanılmış (rotate edilmiş) bir refresh token tekrar gelirse önerilen davranış nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Yeni bir access token verilir, çünkü token imzası hâlâ geçerlidir","whyMd":"Eski token'ın tekrar kullanılması çalınma işaretidir; yeni token vermek saldırgana oturum açar."},{"id":"b","ok":true,"md":"İstek reddedilir ve o token ailesindeki tüm refresh token'lar iptal edilir","whyMd":"Hangi tarafın saldırgan olduğu bilinemediği için tüm aile iptal edilir ve kullanıcı yeniden giriş yapar."},{"id":"c","ok":false,"md":"Sadece bu istek reddedilir, en son verilen refresh token geçerli kalır","whyMd":"Saldırgan en son token'a sahip olabilir; sadece isteği reddetmek onu korur."},{"id":"d","ok":false,"md":"Access token'ın süresi uzatılır","whyMd":"Süre uzatmak sorunu büyütür ve akışın bir parçası değildir."}],"explanationMd":"Reuse detection, çalınan refresh token'ın etkisini en fazla bir yenileme turuyla sınırlar.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m11","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"Kullanıcı başına 'dakikada en fazla 5 istek' için fixed window sayacının temel sorunu nedir?","multi":false,"options":[{"id":"a","ok":false,"md":"Kullanıcı başına çok fazla bellek kullanır","whyMd":"Fixed window kullanıcı başına tek sayaç ve pencere başlangıcı tutar; en az bellek kullanan yöntemdir."},{"id":"b","ok":true,"md":"Pencere sınırında kısa sürede limitin iki katına kadar isteğe izin verebilir","whyMd":"Örneğin 00:59'da 5 ve 01:00'da 5 istek, iki saniyede 10 istek demektir."},{"id":"c","ok":false,"md":"Thread-safe yapılması imkânsızdır","whyMd":"Atomik sayaçlarla kolayca thread-safe yapılır."},{"id":"d","ok":false,"md":"Redis ile uygulanamaz","whyMd":"`INCR` ve `EXPIRE` ile Redis'te en kolay uygulanan yöntemdir."}],"explanationMd":"Kesin pencere gerekiyorsa sliding window log, patlamaya izinli ortalama hız için token bucket daha uygundur.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"mcq","id":"sorular/goldman-sachs-java-backend#m12","category":"Şirket setleri","label":"Goldman Sachs Java Backend mülakatı","level":"Orta","bodyMd":"PostgreSQL'de `SELECT id, amount FROM payments WHERE customer_id = ? AND status = 'PENDING' ORDER BY created_at DESC LIMIT 20` sorgusu için en uygun index hangisidir?","multi":false,"options":[{"id":"a","ok":false,"md":"Üç ayrı tek kolonlu index: `customer_id`, `status`, `created_at`","whyMd":"Ayrı index'ler bitmap ile birleştirilebilir ama sıralamayı karşılamaz ve LIMIT'ten erken çıkış sağlamaz."},{"id":"b","ok":false,"md":"`(created_at, customer_id, status)`","whyMd":"Eşitlik kolonları başta olmadığı için index aralığı daraltılamaz."},{"id":"c","ok":true,"md":"`(customer_id, status, created_at DESC) INCLUDE (amount)`","whyMd":"Eşitlik kolonları önce, sıralama kolonu sonra; `INCLUDE` ile tabloya gitmeden index-only scan mümkün olur."},{"id":"d","ok":false,"md":"`(status)` çünkü az sayıda farklı değeri var","whyMd":"Düşük seçicilikli tek kolonlu index bu sorguda az fayda sağlar."}],"explanationMd":"Composite index'te eşitlik koşulları önce, aralık ya da sıralama kolonu sonra gelir; gereken kolonlar index'te olursa `SELECT *` kaldırmanın faydası da buradan gelir.","links":[],"href":"/sorular/goldman-sachs-java-backend/"},{"kind":"open","id":"kitap/00-bu-kitap-nasil-okunur#1","category":"Giriş","label":"Bu kitap nasıl okunur","level":"Başlangıç","short":"$undefined","questionMd":"Kendini teknik olarak nasıl tanımlarsın?","answers":{"junior":"Java ve Spring Boot ile backend geliştiriyorum. REST API yazıyorum, veritabanı olarak PostgreSQL kullanıyorum, Kafka ile de çalıştım.","mid":"Beş yıldır Java ve Spring Boot ile backend geliştiriyorum. Son dönemde bankacılık tarafında müşteri ve hesap verisinin sahibi olan bir ekipteyim; REST API'ler, PostgreSQL ve Kafka ile event tabanlı entegrasyonlar yazıyorum. Test yazmaya ve kod review'a önem veriyorum.","senior":"Beş yıldır Java ve Spring ile backend geliştiriyorum; son bir buçuk yıldır bir bankada müşteri ve hesap verisinin sahibi olan bir ekipte çalışıyorum. Orada beni en çok geliştiren şey, hatanın pahalı olduğu bir alanda tutarlılık ve geriye uyumluluk üzerine düşünmek oldu: idempotent API'ler, event'lerle veri senkronizasyonu, sözleşmeyi bozmadan değişiklik yapmak. Bir feature'ın sahibi olarak tasarımdan production'a kadar sürecin tamamını yürüttüm. Yeni rolde beni çeken şey ölçek: aynı tasarım kararlarını çok daha yüksek trafik altında vermek.","interviewer":"Junior cevap teknoloji listesi. Mid cevap bağlam ekliyor. Senior cevap bir tema (tutarlılık ve sahiplik), somut sorumluluk ve pozisyonla bağlantı kuruyor. Kendi cümlelerinle yaz ve 60-90 saniyede bitecek kadar kısa tut.\n\n**Takip sorusu:** \"Feature owner olarak verdiğin ve sonradan yanlış çıkan bir teknik karar var mı?\""},"href":"/kitap/00-bu-kitap-nasil-okunur/"},{"kind":"open","id":"kitap/01-oop-ve-nesne-tasarimi#1","category":"Java","label":"OOP ve nesne tasarımı","level":"Başlangıç","short":"$undefined","questionMd":"Overloading ile overriding arasındaki fark nedir?","answers":{"junior":"Overloading aynı isimde farklı parametreli metotlar yazmak, overriding ise alt sınıfta üst sınıfın metodunu yeniden yazmak. Overloading compile-time polymorphism, overriding runtime polymorphism. Override ederken `@Override` annotation'ı kullanırım.","mid":"Overload seçimi derleme anında, argümanların statik tiplerine göre yapılır. Derleyici en spesifik imzayı seçer, boxing ve varargs'a sadece gerekirse bakar. Override ise çalışma anında, nesnenin gerçek sınıfına göre seçilir. Override'da imza aynı olmalı, dönüş tipi covariant olabilir, erişim daraltılamaz ve daha geniş checked exception fırlatılamaz. Static, private ve final metotlar override edilmez. Static'te aynı imza method hiding olur ve referansın derleme tipine göre çağrılır. Field'lar da polymorphic değildir.","senior":"$21","interviewer":"Junior cevap tanımı doğru veriyor ama \"compile-time polymorphism\" etiketini ezberden söylüyor. \"Hangi bilgiye göre seçilir?\" sorusuna geçmiyor. `Object arg = \"x\"; p.pay(arg)` sorulduğunda büyük olasılıkla yanılır. Mid cevap kuralları ve static hiding'i biliyor, kod okuma sorularını çözer. Senior cevap mekanizmayı (imza derleme anında sabitlenir, gövde runtime'da seçilir, single dispatch) bir kez anlatıp oradan production sonuçlarına geçiyor: Spring proxy'lerinin sınırları, overload'un API tasarımındaki riski ve alternatif olarak pattern matching. Performans konusunda yaygın bir mit'i doğru şekilde düzeltiyor.\n\n**Takip sorusu:** \"`find(null)` çağrısı `find(String)` ve `find(Integer)` overload'ları varken ne yapar? Peki `find(String)` ve `find(Object)` varken?\""},"href":"/kitap/01-oop-ve-nesne-tasarimi/"},{"kind":"open","id":"kitap/01-oop-ve-nesne-tasarimi#2","category":"Java","label":"OOP ve nesne tasarımı","level":"Başlangıç","short":"$undefined","questionMd":"Abstract class ile interface arasında nasıl seçim yaparsın?","answers":{"junior":"Interface'te sadece abstract metotlar olur, abstract class'ta normal metotlar da olabilir. Bir sınıf birden fazla interface implemente edebilir ama tek bir sınıfı extend edebilir. Çoklu kalıtım gerekiyorsa interface kullanırım.","mid":"Java 8'den beri interface'lerde default ve static, Java 9'dan beri private metot var. Yani fark artık \"gövde var mı\" değil. Asıl fark state ve constructor: interface state tutamaz, abstract class tutar. Sözleşmeyi interface ile tanımlarım, çünkü DI, mock'lama ve birden fazla implementasyon için esnektir. Implementasyonlar arasında ortak state veya ortak akış varsa abstract class ile Template Method kurarım. İki interface aynı default metodu getirirse override edip `X.super.m()` ile çözerim.","senior":"$22","interviewer":"Junior cevap Java 8 öncesinin cevabı ve \"interface'te sadece abstract metot olur\" ifadesi artık yanlış. Mid cevap güncel ve doğru, pratik kuralı da veriyor. Senior cevabı ayıran üç şey var: kararı çağıranın bağımlılığı üzerinden vermesi, Template Method'u `final` ile korurken bunun Spring proxy'leriyle çeliştiğini bilmesi ve üçüncü seçenek olarak sealed hiyerarşiyi getirip ne zaman strategy, ne zaman sealed + switch kullanılacağını ayırması.\n\n**Takip sorusu:** \"Interface'e bir default metot eklemek mevcut implementasyonları hangi durumda yine de bozabilir?\""},"href":"/kitap/01-oop-ve-nesne-tasarimi/"},{"kind":"open","id":"kitap/01-oop-ve-nesne-tasarimi#3","category":"Java","label":"OOP ve nesne tasarımı","level":"Orta","short":"$undefined","questionMd":"Composition'ı neden inheritance'a tercih ederiz? Somut bir örnek ver.","answers":{"junior":"Composition daha esnek olduğu için tercih edilir. Inheritance'da sınıflar birbirine sıkı bağlanır. \"Has-a\" ilişkisi varsa composition, \"is-a\" ilişkisi varsa inheritance kullanırım.","mid":"Inheritance alt sınıfı üst sınıfın implementasyonuna bağlar. Klasik örnek `HashSet`'ten türeyip `add` ve `addAll`'u sayan sınıf: `addAll` içeride `add`'i çağırdığı için her eleman iki kez sayılır. Çözüm, Set'i içeride tutup arayüzü implemente eden bir forwarding wrapper yazmak, yani decorator. Spring'de de servisler birbirini constructor'dan alır. Bu composition'dır.","senior":"$23","interviewer":"Junior cevap sloganı tekrarlıyor ama \"neden daha esnek\" sorusuna mekanizma veremiyor. Mid cevap klasik örneği ve çözümü biliyor. Senior cevap problemi \"self-use bir implementasyon detayıdır, sözleşme değildir\" diye doğru yerden tanımlıyor, zaman boyutunu (sürüm değişince bozulma) ekliyor, kalıtımın kabul edilebilir olduğu şartları net sayıyor ve composition'ın da sınırını (SELF problemi) biliyor. Ezber bir \"composition iyidir\" yerine dengeli bir karar çerçevesi var.\n\n**Takip sorusu:** \"`Stack extends Vector` neden kötü bir tasarım? LSP açısından değerlendir.\""},"href":"/kitap/01-oop-ve-nesne-tasarimi/"},{"kind":"open","id":"kitap/01-oop-ve-nesne-tasarimi#4","category":"Java","label":"OOP ve nesne tasarımı","level":"Orta","short":"$undefined","questionMd":"equals ve hashCode'u neden birlikte override ederiz? Mutable bir nesneyi HashMap key'i yaparsak ne olur?","answers":{"junior":"equals'ı override edersem hashCode'u da override etmeliyim, çünkü eşit nesnelerin hashCode'u eşit olmalı. IDE ile ikisini birlikte üretirim. Mutable nesneyi key yapmak iyi değildir.","mid":"HashMap önce hashCode ile bucket'ı bulur, sonra equals ile karşılaştırır. hashCode override edilmezse eşit iki nesne farklı bucket'lara düşer ve map onları farklı key sayar. Mutable key'in değeri değişip hashCode değişirse, nesne eski bucket'ta kalır ve `get`/`contains`/`remove` onu bulamaz. Key'leri immutable yaparım ya da equals/hashCode'u sadece değişmeyen alanlara dayandırırım. Record kullanırsam ikisi otomatik üretilir.","senior":"$24","interviewer":"Junior cevap kuralı biliyor ama nedenini (HashMap'in arama algoritması) anlatmıyor ve \"mutable key iyi değildir\" diyip ne olacağını açıklamıyor. Mid cevap mekanizmayı ve çözümü doğru veriyor. Senior cevap saklanan hash ayrıntısıyla \"neden bulunamıyor ama size'a sayılıyor\" sorusunu tam cevaplıyor, sızıntı boyutunu ekliyor ve sözleşmeyi gerçek hayattaki en sık iki bağlama (JPA entity'leri ve BigDecimal) taşıyor. Fintech geçmişi olan bir adaydan BigDecimal scale tuzağını duymak güçlü bir sinyal.\n\n**Takip sorusu:** \"Bir alt sınıf equals'a yeni bir alan eklerse simetri neden bozulur? `getClass()` ile `instanceof` arasındaki seçim neyi değiştirir?\""},"href":"/kitap/01-oop-ve-nesne-tasarimi/"},{"kind":"open","id":"kitap/02-dilin-ince-noktalari#1","category":"Java","label":"Dilin ince noktaları","level":"Başlangıç","short":"$undefined","questionMd":"Checked ve unchecked exception arasındaki fark nedir? Kendi kodunda hangisini kullanırsın?","answers":{"junior":"Checked exception'ları yakalamak ya da `throws` ile bildirmek zorundayız, unchecked'leri değil. Checked exception'lar `Exception`'dan, unchecked'ler `RuntimeException`'dan türer. IOException checked, NullPointerException unchecked. Kendi exception'larımı genelde `Exception`'dan türetirim.","mid":"Checked exception'lar kurtarılabilir dış durumlar için, unchecked'ler programlama hataları ve iş kuralı ihlalleri için tasarlandı. Modern Spring kodunda unchecked tercih ediyorum: lambda'larla uyumlu, katman imzalarını kirletmiyor ve Spring `@Transactional` varsayılan olarak sadece RuntimeException'da rollback yapıyor. Checked bir exception fırlatırsam transaction commit olur. Domain exception'larımı RuntimeException'dan türetiyorum ve `@RestControllerAdvice` ile HTTP status'a çeviriyorum. Kaynakları try-with-resources ile kapatıyorum, cause'u her zaman koruyorum.","senior":"$25","interviewer":"Junior cevap tanımı doğru veriyor ama \"kendi exception'larımı Exception'dan türetirim\" ifadesi Spring bağlamında sessiz commit hatası üretecek bir alışkanlık. Bunu fark etmiyor. Mid cevap modern pratiği ve Spring rollback kuralını biliyor, yani production'da bu hatayı yapmaz. Senior cevap soruyu bir tasarım kararına çeviriyor (beklenen dal mı, istisna mı), exception'a alternatif olarak sonuç tipini öneriyor ve gerçek operasyonel tuzakları (rollback kuralı, interrupt bayrağı, stack trace'siz NPE, maliyet) somut olarak sayıyor.\n\n**Takip sorusu:** \"try-with-resources'ta hem gövde hem `close()` exception fırlatırsa hangisini görürsün? Eski try/finally ile yazılsaydı ne görürdün?\""},"href":"/kitap/02-dilin-ince-noktalari/"},{"kind":"open","id":"kitap/02-dilin-ince-noktalari#2","category":"Java","label":"Dilin ince noktaları","level":"Orta","short":"$undefined","questionMd":"PECS nedir? ? extends T ile ? super T arasındaki fark ne?","answers":{"junior":"PECS, Producer Extends Consumer Super demek. `? extends` ile okuyabilirim ama ekleyemem, `? super` ile ekleyebilirim ama okurken Object alırım.","mid":"Generic tipler invariant: `List`, `List`'ın alt tipi değil. Wildcard'lar bu esnekliği yön kısıtıyla geri veriyor. `? extends Number` ile liste `List` da `List` da olabilir. Bu yüzden derleyici eklemeye izin vermez ama her eleman bir Number olarak okunabilir. `? super Integer` listesi Integer'ın herhangi bir üst tipinin listesi olabilir. Integer eklemek güvenli ama okunan değer sadece Object. JDK'da `Collections.copy(List dest, List src)` ve `sort(List, Comparator)` bunun örnekleri.","senior":"Kural invariance'ın sonucu. Diziler kovaryant olduğu için aynı hata runtime'da ArrayStoreException olarak çıkıyor. Generic'ler bunu derleme anına taşıyor, ama esnekliği de kaldırıyor. Wildcard'lar esnekliği \"sadece okuma\" ya da \"sadece yazma\" yönünde geri veriyor. Pratikte kuralım şu: wildcard'ları sadece parametrelerde kullanırım, dönüş tiplerinde asla. Çağıran wildcard'ı düşünmek zorunda kalıyorsa API yanlış tasarlanmıştır. Hem okuyup hem yazıyorsam düz `T` kullanırım.\n\nBunun bir de erasure tarafı var. Generic bilgi nesnelerden silinir, bildirimlerde kalır. Jackson'da `List` deserialize ederken `TypeReference`, Spring RestClient'ta `ParameterizedTypeReference` kullanmamın sebebi bu. `List.class` verirsem elemanlar LinkedHashMap olur ve hata ancak elemana eriştiğimde ClassCastException olarak çıkar. Bunu bir entegrasyon testinde yakalamak, production'da yakalamaktan çok daha ucuz.","interviewer":"Junior cevap kısaltmayı ve sonucu ezberlemiş, \"neden ekleyemem?\" sorusunda takılır. Mid cevap nedeni (liste Double listesi olabilir) ve JDK örneklerini veriyor. Senior cevap kuralın kökenini (invariance, dizilerin kovaryansı) açıklıyor, API tasarımı için uygulanabilir bir kural koyuyor ve konuyu erasure üzerinden günlük bir probleme (Jackson/RestClient'ta generic tip kaybı) bağlıyor.\n\n**Takip sorusu:** \"`List` listesine hiçbir şey ekleyemiyorsak `null` neden eklenebiliyor? `List` ile raw `List` arasındaki fark ne?\""},"href":"/kitap/02-dilin-ince-noktalari/"},{"kind":"open","id":"kitap/02-dilin-ince-noktalari#3","category":"Java","label":"Dilin ince noktaları","level":"Başlangıç","short":"$undefined","questionMd":"String neden immutable? String pool nasıl çalışır?","answers":{"junior":"String immutable çünkü güvenli ve thread-safe. String pool'da aynı literal'ler tek bir kez tutulur, bu yüzden bellek tasarrufu sağlar. String'leri `equals` ile karşılaştırmak gerekir, `==` referansı karşılaştırır.","mid":"Immutability dört şeyi mümkün kılıyor: hashCode bir kez hesaplanıp cache'lenebiliyor, String'ler senkronizasyonsuz paylaşılabiliyor, pool güvenli şekilde var olabiliyor ve doğrulanmış bir dosya yolu ya da sınıf adı sonradan değiştirilemiyor. Pool Java 7'den beri heap'te. Literal'ler ve `intern()` edilen String'ler orada kanonik olarak tutulur. Derleme anı sabit ifadeleri (iki literal'in birleşimi, final sabit değişkenler) katlanır ve pool'daki nesneyi gösterir. Çalışma anında birleştirilen String yeni nesnedir. Döngüde `+=` her turda tüm içeriği kopyaladığı için O(n²)'dir, StringBuilder kullanırım.","senior":"Immutability'nin en önemli nedeni güvenlik: String'ler sınıf adları, yollar ve yetki kontrollerinde kullanılıyor ve kontrol ile kullanım arasında değişebilseydi TOCTOU açığı olurdu. Hash cache, pool ve thread-safety bunun yan kazançları. Hash alanı volatile bile değil, hesaplama deterministik olduğu için yarış zararsız.\n\nPool'u production'da iki yerde düşünüyorum. Birincisi `==` hataları: literal'lerle test geçer, DB'den gelen değerle production'da patlar. Statik analizi CI'da zorunlu tutarım. İkincisi bellek: heap dump'ta milyonlarca tekrarlı String görürsem `intern()`'e değil önce enum'a, sonra `-XX:+UseStringDeduplication`'a bakarım. Dedup dizileri birleştirir, nesneleri değil, ve JDK 18'den beri G1 dışındaki GC'lerde de var. Compact Strings Türkçe için ilginç: tek bir ş veya ğ bütün String'i 2 byte/karaktere çeviriyor. Bir de locale tuzağı var: Türk locale'li bir sunucuda `toUpperCase()` \"id\"yi \"İD\" yapar ve `Enum.valueOf`'u bozar. Makine karşılaştırmalarında her zaman `Locale.ROOT` kullanırım.","interviewer":"Junior cevap doğru kelimeleri sıralıyor ama hiçbirinin mekanizmasını vermiyor. \"Neden thread-safe?\" ya da \"pool neden immutability gerektirir?\" sorularında takılır. Mid cevap nedenleri bağlantılı anlatıyor, constant folding'i ve döngü maliyetini biliyor. Kod okuma sorularını çözer. Senior cevap nedenler arasında öncelik kuruyor (güvenlik birincil), hash'in benign data race ayrıntısını biliyor ve konuyu üç somut production durumuna (== hataları, bellek optimizasyonu seçenekleri, Türk locale tuzağı) taşıyor. Türkiye'de çalışmış bir backend geliştiricisinden locale tuzağını duymak deneyim sinyalidir.\n\n**Takip sorusu:** \"`final String c = \"back\"; String d = c + \"end\";` olsaydı `\"backend\" == d` ne dönerdi? `c` bir metottan dönen değerle ilklendirilseydi?\""},"href":"/kitap/02-dilin-ince-noktalari/"},{"kind":"open","id":"kitap/02-dilin-ince-noktalari#4","category":"Java","label":"Dilin ince noktaları","level":"Başlangıç","short":"$undefined","questionMd":"Java pass-by-value mı, pass-by-reference mı?","answers":{"junior":"Primitive'ler için pass-by-value, nesneler için pass-by-reference. Bu yüzden metoda verdiğim nesneyi değiştirirsem çağıran da değişikliği görür.","mid":"Java her zaman pass-by-value. Nesnelerde geçirilen değer referansın kopyası. Kopya referans üzerinden nesneyi değiştirirsem çağıran görür çünkü aynı nesne. Ama kopyayı başka nesneye yönlendirirsem (`o = new Order()`) çağıranın değişkeni etkilenmez. Pass-by-reference olsaydı Java'da `swap(a, b)` yazılabilirdi, yazılamıyor.","senior":"Pass-by-value. Çağrıda argüman değerleri çağrılan metodun frame'indeki yerel slotlara kopyalanır, nesneler için o değer bir referans. Turnusol testi `swap`: Java'da iki değişkenin değerini metotla değiştiremezsin.\n\nBunun pratikteki önemi yan etkiler. İmzaya bakarak bir metodun parametresini değiştirip değiştirmediğini anlayamazsın. Bu yüzden domain'de immutable nesneler ve dönüş değeri tercih ederim. JPA'da bunun pahalı bir versiyonu var: managed bir entity'yi yardımcı bir metoda verirsin, metot hesaplama için bir setter çağırır ve save hiç çağrılmadığı halde dirty checking commit'te UPDATE atar. Kod review'da entity alan \"hesaplama\" metotlarını özellikle kontrol ederim. Ayrıca finally'deki return değeri de aynı mantıkla çalışır: dönen şey referansın kopyası, finally nesneyi değiştirirse çağıran değişmiş nesneyi görür.","interviewer":"Junior cevap çok yaygın bir yanlış inancı tekrarlıyor: \"nesneler pass-by-reference\". Gözlemi doğru (çağıran değişikliği görür) ama modeli yanlış ve `o = new Order()` satırının etkisini yanlış tahmin eder. Mid cevap modeli düzeltiyor ve `swap` testini biliyor. Senior cevap bunu JVM frame seviyesine bağlıyor ve asıl önemli kısma geçiyor: yan etkili metotların riski ve JPA dirty checking ile ortaya çıkan beklenmeyen UPDATE'ler.\n\n**Takip sorusu:** \"Bir metoda `List` verip içinde `list = new ArrayList<>()` ve sonra `list.add(...)` yazarsan çağıranın listesi değişir mi? Peki `list.clear()` yazarsan?\""},"href":"/kitap/02-dilin-ince-noktalari/"},{"kind":"open","id":"kitap/03-jvm-bellek-ve-gc#1","category":"Java","label":"JVM, bellek ve garbage collection","level":"Başlangıç","short":"$undefined","questionMd":"Heap ile stack arasındaki fark nedir?","answers":{"junior":"Stack'te primitive'ler ve referanslar, heap'te nesneler tutulur. Stack her thread için ayrı, heap ortak. Stack hızlıdır ve metot bitince temizlenir, heap'i GC temizler. Stack dolarsa StackOverflowError, heap dolarsa OutOfMemoryError alırız.","mid":"Stack thread başına ve metot çağrısı başına bir frame tutar: yerel değişkenler, parametreler ve operand stack. Frame metot bitince atılır, yani stack'te GC yok. Nesneler ve diziler heap'te. Bir nesnenin primitive alanları da nesneyle birlikte heap'te, static alan değerleri de heap'te, sınıf metadata'sı Metaspace'te. Yerel değişkenler thread-safe çünkü stack thread'e özel, ama gösterdikleri nesneler paylaşılabilir. Stack'teki referanslar GC root'tur. Bir nesne static bir alandan erişilebiliyorsa metot bitse bile yaşar.","senior":"Ayrımı \"bellek nerede bildirildi\" üzerinden kurarım: yerel olan frame'de, alan olan nesneyle birlikte heap'te, static olan heap'teki Class nesnesinde. \"Primitive'ler stack'te\" ifadesi bu yüzden eksik. Stack'in önemli olduğu iki nokta var: GC root olması ve thread başına rezerve edilen bellek. 200 Tomcat thread'i, Kafka ve executor thread'leri container bellek bütçesinde ayrı bir kalem. Virtual thread'lerde ise stack frame'leri park edildiğinde heap'te chunk olarak tutuluyor, bu yüzden milyonlarca virtual thread mümkün.\n\nJIT tarafında escape analysis var, ama HotSpot nesneyi stack'e koymaz, kaçmıyorsa scalar replacement ile tamamen ortadan kaldırır. Bu sadece C2'nin derlediği sıcak kodda olur, tasarımı buna göre yapmam. Production'da bu ayrımı en çok \"bu nesne neden toplanmıyor?\" sorusunda kullanırım: cevap her zaman bir root'tan, genelde bir static koleksiyondan ya da havuzlanmış bir thread'in ThreadLocal'ından gelen referans zinciridir ve heap dump'ta path to GC roots ile görünür.","interviewer":"Junior cevap ezber cümleyi kuruyor ve \"primitive'ler stack'te\" gibi yaygın bir yanlışı içeriyor: bir nesnenin int alanının heap'te olduğunu bilmiyor. Mid cevap bu yanlışı düzeltiyor, GC root kavramını ve static alanın etkisini biliyor. Senior cevap konuyu bir kurala bağlıyor (bildirildiği yer), stack'in container bellek bütçesindeki yerini, virtual thread'lerin farkını ve escape analysis hakkındaki yaygın yanlışı (\"stack'e koyar\") doğru şekilde anlatıyor, sonra bilgiyi bir teşhis aracına (path to GC roots) bağlıyor.\n\n**Takip sorusu:** \"Bir metodun içinde oluşturduğun ve hiçbir yere vermediğin bir nesne her zaman heap'te mi oluşur?\""},"href":"/kitap/03-jvm-bellek-ve-gc/"},{"kind":"open","id":"kitap/03-jvm-bellek-ve-gc#2","category":"Java","label":"JVM, bellek ve garbage collection","level":"İleri","short":"$undefined","questionMd":"Production'da memory leak olduğundan şüpheleniyorsun. Adım adım ne yaparsın?","answers":{"junior":"Heap'i artırırım, sorun devam ederse heap dump alıp VisualVM ile bakarım. Bir de kodda kapatılmayan connection ya da stream var mı diye bakarım.","mid":"Önce metriklerde GC sonrası heap kullanımının sürekli arttığını doğrularım. Sonra `-XX:+HeapDumpOnOutOfMemoryError` ile çalıştırır, gerekirse `jcmd GC.heap_dump` ile canlı dump alırım. Eclipse MAT'te Leak Suspects ve dominator tree'ye, en büyük retained size'a sahip nesneye ve onun path to GC roots'una bakarım. Tipik nedenler static map'ler, sınırsız cache'ler, temizlenmeyen ThreadLocal'lar ve kaydı silinmeyen listener'lar. Düzeltmede cache'e boyut ve TTL veririm, ThreadLocal'ı finally'de remove ederim.","senior":"$26","interviewer":"Junior cevap \"heap'i artırırım\" ile başlıyor, bu belirtiyi gizler ve teşhisi geciktirir. Araç adı veriyor ama yöntem yok. Mid cevap doğru araç zincirini ve tipik nedenleri biliyor, bir sızıntıyı bulup düzeltebilir. Senior cevap önce hipotezi doğruluyor (sızıntı mı, yük mü, heap mi native mi), production'da dump almanın risklerini (STW, liveness, veri gizliliği) yönetiyor, düzeltmenin doğrulanmasını ve önleme adımlarını ekliyor. Fark, aracı bilmekte değil, operasyonel riski ve kanıt zincirini yönetmekte.\n\n**Takip sorusu:** \"Heap kullanımı sabit ama pod her gün biraz daha fazla RSS kullanıyor ve sonunda OOMKilled oluyor. Nerelere bakarsın?\""},"href":"/kitap/03-jvm-bellek-ve-gc/"},{"kind":"open","id":"kitap/03-jvm-bellek-ve-gc#3","category":"Java","label":"JVM, bellek ve garbage collection","level":"İleri","short":"$undefined","questionMd":"G1 ile ZGC arasında nasıl seçim yaparsın?","answers":{"junior":"G1 varsayılan GC, ZGC ise düşük gecikmeli GC. Latency önemliyse ZGC, değilse G1 kullanırım.","mid":"G1 heap'i bölgelere ayırır, young toplamaları ve eşzamanlı işaretleme sonrası mixed toplamalar yapar, `MaxGCPauseMillis` (varsayılan 200 ms) hedefine göre çalışır. ZGC işaretleme ve sıkıştırmayı eşzamanlı yapar, colored pointer ve load barrier kullanır, duraklamaları heap boyutundan bağımsız olarak milisaniye altında tutar. Bedeli biraz daha fazla CPU ve bellek payı. Java 21'de generational ZGC `-XX:+ZGenerational` ile açılıyor, Java 23'ten beri varsayılan. Büyük heap ve sıkı latency hedefi varsa ZGC, genel API'ler için G1.","senior":"$27","interviewer":"Junior cevap tek boyutlu: \"latency için ZGC\". Bedelini ve ne zaman gereksiz olduğunu bilmiyor. Mid cevap iki GC'nin mekanizmasını ve sürüm bilgisini doğru veriyor. Senior cevap kararı ölçüme bağlıyor (GC gerçekten sorun mu?), ZGC'nin metriklerde görünmeyen riskini (allocation stall) biliyor, container'da GC'nin sessizce Serial'e düşmesi gibi bir production tuzağını ekliyor ve değişikliği canary ile güvenli yapmayı öneriyor.\n\n**Takip sorusu:** \"GC log'larında sık 'humongous allocation' görüyorsun. Bu ne demek ve ne yaparsın?\""},"href":"/kitap/03-jvm-bellek-ve-gc/"},{"kind":"open","id":"kitap/03-jvm-bellek-ve-gc#4","category":"Java","label":"JVM, bellek ve garbage collection","level":"Orta","short":"$undefined","questionMd":"Spring Boot servisini Kubernetes'te çalıştırırken JVM'in bellek ve CPU ayarlarını nasıl yaparsın?","answers":{"junior":"`-Xmx`'i container'ın memory limitine göre veririm. Resource request ve limit tanımlarım. Bellek yetmezse limiti artırırım.","mid":"`-Xmx`'i limite eşitlemem, çünkü JVM heap dışında da bellek kullanır: metaspace, thread stack'leri, code cache, direct buffer'lar. Bu yüzden `-XX:MaxRAMPercentage=70` gibi bir yüzde veririm. JDK 10+ container limitlerini görüyor. Memory request ve limit'i eşit tutarım. CPU limiti çok düşükse throttling olur ve JVM 1 CPU görüp SerialGC seçebilir, bu yüzden gerçekçi bir CPU veririm. `-XX:+ExitOnOutOfMemoryError` ve heap dump ayarlarını eklerim.","senior":"$28","interviewer":"Junior cevap tam olarak q16'daki hatayı tarif ediyor: limite göre `-Xmx` vermek pod'u OOMKilled yapar. Mid cevap bu hatayı ve temel düzeltmeleri biliyor, bir servisi güvenle çalıştırır. Senior cevap belleği ölçülebilir bir bütçe olarak ele alıyor, CPU tarafında hem throttling'i hem de limit kaldırılınca ortaya çıkan ters etkiyi (JDK 19+ davranışı) biliyor, GC ergonomisinin sürüme bağlı tuzağını söylüyor ve hepsini bir doğrulama adımıyla (`VM.flags`) bağlıyor.\n\n**Takip sorusu:** \"Pod `OOMKilled` oldu ama heap dump yok ve log'da hiçbir hata yok. Neden? Bir sonraki sefere neyi hazırlarsın?\""},"href":"/kitap/03-jvm-bellek-ve-gc/"},{"kind":"open","id":"kitap/04-lambda-ve-stream#1","category":"Java","label":"Lambda ve Stream","level":"Orta","short":"$undefined","questionMd":"Stream'ler lazy'dir ne demek? Bir pipeline nasıl çalışır?","answers":{"junior":"Stream'ler lazy'dir, yani terminal işlem çağrılmadan hiçbir şey çalışmaz. `filter`, `map` gibi metotlar intermediate, `collect`, `forEach` gibi metotlar terminal işlemlerdir. Terminal işlem çağrılınca önce filter tüm elemanlara uygulanır, sonra map uygulanır ve sonuç toplanır.","mid":"Intermediate işlemler sadece pipeline'ı tarif eder; terminal işlem gelince çalışır. İşleme eleman eleman olur: bir eleman filter'dan geçerse hemen map'e, sonra bir sonraki aşamaya iner. Bu yüzden `limit`, `findFirst`, `anyMatch` gibi short-circuit işlemler kaynaktan gereğinden fazla eleman çekmez ve sonsuz stream'lerle çalışabilir. Pratikte ucuz filtreleri başa, pahalı map'leri sona koyarım. `sorted` ve `distinct` stateful olduğu için bu akışı keser; `sorted` tüm elemanları toplamadan ilkini veremez. Stream tek kullanımlıktır, ikinci terminal işlem `IllegalStateException` verir.","senior":"Terminal işlem çağrıldığında stage'ler bir Sink zincirine sarılır ve Spliterator elemanları tek tek bu zincire iter; laziness'ın değeri buradan gelir: yapılmayan iş. Short-circuit, sink'in `cancellationRequested` sinyaliyle kaynağı durdurmasıdır. `sorted` bir bariyerdir: tamponlar, `end()`'de sıralar ve akıtır; `sorted().limit(k)` bu yüzden O(n log n) zaman ve O(n) bellek harcar, top-k için heap daha iyidir.\n\nLaziness'ın bir yan sonucu da Stream API'nin lambda'ları çalıştırmama hakkıdır: Java 9+ `count()`, boyut kaynaktan biliniyorsa pipeline'ı atlar, bu yüzden `peek` ve `map` içine yan etki koymam. Çok büyük ya da sonsuz kaynaklarda (`Files.lines`) erken çıkışı bilinçli kullanırım ve I/O kaynaklı stream'leri try-with-resources ile kapatırım. Performans kritikse JMH ile ölçerim; boxing (`Stream` yerine `LongStream`) ve gereksiz ara koleksiyonlar genelde stream'in kendisinden daha pahalıdır.","interviewer":"Junior cevap tanımı biliyor ama yaygın bir yanlış inanç içeriyor: \"önce filter tüm elemanlara, sonra map\" yatay işlemedir ve yanlıştır. Bu inançla j13'teki gibi bir kod okuma sorusunda hatalı cevap verir. Mid cevap dikey işlemeyi, short-circuit'i ve stateful işlemlerin akışı nasıl kestiğini biliyor ve bundan pratik bir kural (filtre önce) çıkarıyor. Senior cevap mekanizmayı (Sink zinciri, cancellation sinyali, `sorted`'ın tamponlaması) ve bunun maliyet sonuçlarını (O(n) bellek, top-k) söylüyor, ayrıca laziness'ın \"lambda'n hiç çalışmayabilir\" anlamına geldiğini ve bunun yan etkiler için ne demek olduğunu biliyor.\n\n**Takip sorusu:** \"`Stream.of(...).sorted().peek(...).findFirst()` ne yazdırır, `sorted`'ı kaldırırsak ne değişir?\""},"href":"/kitap/04-lambda-ve-stream/"},{"kind":"open","id":"kitap/04-lambda-ve-stream#2","category":"Java","label":"Lambda ve Stream","level":"Başlangıç","short":"$undefined","questionMd":"orElse ile orElseGet arasındaki fark nedir? Optional'ı nerede kullanırsın?","answers":{"junior":"`orElse` değer yoksa verilen değeri döner, `orElseGet` de bir Supplier alıp ondan değer döner. İkisi de aynı işi yapar, `orElseGet` lambda ile yazılır. Optional'ı null pointer hatalarından kaçınmak için her yerde kullanırım, entity alanlarında da kullanılabilir.","mid":"`orElse`'nin argümanı, Optional dolu olsa bile, metot çağrılmadan önce hesaplanır; `orElseGet` ise sadece boşsa Supplier'ı çağırır. Varsayılan pahalıysa ya da yan etkisi varsa, mesela DB'ye gidiyorsa, `orElseGet` kullanırım. Optional'ı sadece dönüş tipinde kullanırım; alan ya da parametre olarak kullanmam çünkü Serializable değil, JPA desteklemez ve parametrede çağıranı zorlar. `isPresent` + `get` yerine `map`, `flatMap`, `orElseThrow` ile zincir kurarım.","senior":"$29","interviewer":"Junior cevap iki metodu eşdeğer sanıyor; bu yaygın ve production'da gerçek maliyet üreten bir yanlış inanç. \"Her yerde, entity alanında da\" demesi Optional'ın tasarım amacını bilmediğini gösteriyor. Mid cevap mekanizmayı (eager evaluation) ve doğru kullanım yerlerini biliyor. Senior cevap aynı bilgiyi production etkisiyle (testte görünmeyen, metriklerde görünen hata), code review alışkanlığıyla ve \"nerede kullanmam, yerine ne kullanırım\" alternatifleriyle veriyor; ayrıca `orElse`'nin doğru olduğu durumu da söyleyerek dogmatik olmadığını gösteriyor.\n\n**Takip sorusu:** \"Spring Data'da `findById` Optional dönüyor. Servis katmanında bulunamazsa 404 dönmek için bunu nasıl ele alırsın?\""},"href":"/kitap/04-lambda-ve-stream/"},{"kind":"open","id":"kitap/04-lambda-ve-stream#3","category":"Java","label":"Lambda ve Stream","level":"Orta","short":"$undefined","questionMd":"Parallel stream ne zaman kullanırsın?","answers":{"junior":"Büyük listelerde işlemi hızlandırmak için `parallelStream()` kullanırım. Çok çekirdekli makinede işi bölerek daha hızlı çalışır. Mesela 10.000 siparişi işlerken parallel stream ile daha hızlı biter.","mid":"Parallel stream `ForkJoinPool.commonPool()`'u kullanır. Veri büyükse, işlem CPU-yoğunsa, yan etki yoksa ve kaynak iyi bölünüyorsa (ArrayList, dizi) fayda sağlar. I/O içeren işlerde kullanmam, çünkü common pool küçük ve paylaşımlı; bloklayan çağrılar tüm uygulamadaki paralel işleri ve executor verilmemiş CompletableFuture'ları yavaşlatır. `forEach` ile dışarıdaki listeye yazmak parallel'de bozulur, `collect` kullanırım.","senior":"$2a","interviewer":"Junior cevap \"parallel = hızlı\" varsayımını yapıyor ve örneği (10.000 sipariş) maliyetten bağımsız veriyor; paylaşımlı havuzdan ve I/O tuzağından haberi yok. Mid cevap common pool'u, uygun koşulları ve yan etki tuzağını biliyor. Senior cevap bağlamı soruyor (web servisi mi, batch mi), istek seviyesindeki paralellikle çakışmayı açıklıyor, ölçüm yöntemini ve I/O için doğru alternatifleri (mapConcurrent, virtual thread, bulkhead) veriyor. \"Ne zaman kullanmam\" cevabın merkezinde.\n\n**Takip sorusu:** \"Bir parallel stream içinde `reduce(BigDecimal.ONE, BigDecimal::add)` yazılmış. Ne olur?\""},"href":"/kitap/04-lambda-ve-stream/"},{"kind":"open","id":"kitap/04-lambda-ve-stream#4","category":"Java","label":"Lambda ve Stream","level":"Orta","short":"$undefined","questionMd":"Lambda neden sadece effectively final değişkenleri yakalayabilir? Lambda ile anonim sınıf arasındaki fark nedir?","answers":{"junior":"Java öyle tasarlandığı için lambda içinde dışarıdaki değişkeni değiştiremeyiz, derleyici hata verir. Lambda, anonim sınıfın kısa yazılmış halidir; ikisi aynı şeydir ama lambda daha okunur.","mid":"Lambda yakaladığı local değişkenin değerini kopyalar. Local değişken stack'te yaşar ve metot bitince yok olur, lambda ise daha uzun yaşayabilir ya da başka thread'de çalışabilir. Değişebilseydi kopyayla orijinal tutarsız olur ve race condition çıkardı. Anonim sınıftan farkı: lambda'da `this` çevreleyen sınıfı gösterir, anonim sınıfta anonim sınıfın kendisini. Lambda sadece functional interface'e atanabilir, kendi state'i olamaz.","senior":"$2b","interviewer":"Junior cevap \"öyle tasarlanmış\" diyerek nedeni bilmediğini ve \"aynı şey\" diyerek yaygın bir yanlış inancı gösteriyor. Mid cevap kopyalama mekanizmasını ve `this` farkını doğru anlatıyor. Senior cevap kuralın tasarım gerekçesini, instance alanı istisnasının bellek sonucunu, kuralı atlatma ihtiyacının bir kod kokusu olduğunu ve derleme mekanizmasını (invokedynamic, sentetik metot) söylüyor; method reference'taki değerlendirme zamanı farkı gibi ince bir davranışı da biliyor.\n\n**Takip sorusu:** \"`Supplier s = name::length;` ile `Supplier s = () -> name.length();` arasında davranış farkı var mı?\""},"href":"/kitap/04-lambda-ve-stream/"},{"kind":"open","id":"kitap/05-concurrency#1","category":"Java","label":"Concurrency","level":"Orta","short":"$undefined","questionMd":"volatile ne işe yarar? volatile bir sayaç thread-safe midir?","answers":{"junior":"volatile, değişkenin ana bellekten okunmasını sağlar, cache'lenmez. Böylece tüm thread'ler aynı değeri görür. Sayaç volatile olursa thread-safe olur, çünkü her thread güncel değeri okur.","mid":"volatile görünürlük garantisi verir: bir thread'in yazdığı değer diğer thread'lere hemen görünür ve volatile yazma/okuma etrafında yeniden sıralama sınırlanır. Ama atomiklik vermez. `count++` oku, artır, yaz olmak üzere üç adımdır; iki thread aynı değeri okuyup aynı sonucu yazabilir ve artış kaybolur. Sayaç için `AtomicLong` ya da yüksek çekişmede `LongAdder` kullanırım. volatile'ı durdurma bayrağı gibi tek yazarlı durumlarda kullanırım.","senior":"$2c","interviewer":"Junior cevap görünürlüğü yaklaşık doğru anlatıyor ama \"volatile sayaç thread-safe'tir\" yanlış inancını taşıyor; bu tam olarak q1'in a seçeneğidir ve production'da sessiz veri kaybı demektir. Mid cevap görünürlük ile atomikliği ayırıyor, doğru alternatifleri ve kullanım alanını veriyor. Senior cevap mekanizmayı JMM terimleriyle (happens-before, yayınlama, yeniden sıralama, word tearing) anlatıyor, aracı okuma desenine göre seçiyor, çok alanlı invariant'larda volatile ve tek atomic'in de yetmediğini söylüyor ve doğrulama yöntemini (happens-before argümanı, jcstress, mimari farkı) ekliyor.\n\n**Takip sorusu:** \"Double-checked locking'de instance alanını neden volatile yapmak gerekir? volatile olmazsa ne görülebilir?\""},"href":"/kitap/05-concurrency/"},{"kind":"open","id":"kitap/05-concurrency#2","category":"Java","label":"Concurrency","level":"Orta","short":"$undefined","questionMd":"ConcurrentHashMap nasıl çalışır? HashMap ve Collections.synchronizedMap'ten farkı nedir?","answers":{"junior":"HashMap thread-safe değil, ConcurrentHashMap thread-safe. synchronizedMap de thread-safe ama daha yavaş. ConcurrentHashMap map'i segmentlere bölüp her segmenti ayrı kilitler, bu yüzden daha hızlıdır. ConcurrentHashMap kullanınca race condition olmaz.","mid":"Java 8'den beri segment yok: boş bin'e CAS ile, dolu bin'e o bin'in ilk node'u üzerinde synchronized ile yazılır; okumalar kilitsizdir. Farklı bin'lere yazan thread'ler birbirini beklemez. Çakışan bin 8 elemanda ağaca döner. Null kabul etmez, iterator'ları weakly consistent'tir, size yaklaşıktır. synchronizedMap tek kilit kullanır, okumalar dahil her şey sıraya girer. CHM kullanmak tek başına yetmez; `containsKey` + `put` hâlâ race'tir, bileşik işlemler için `merge`, `computeIfAbsent` kullanırım.","senior":"$2d","interviewer":"Junior cevap Java 7 bilgisini (segment) güncel sanıyor ve \"CHM kullanınca race olmaz\" diyor; bu, check-then-act hatalarının kaynağı olan yaygın bir yanlış inanç. Mid cevap Java 8+ yapısını, null/iterator/size davranışını ve bileşik işlem gereksinimini doğru anlatıyor. Senior cevap iç yapıyı (resize yardımı, sayaç, treeify koşulu) tasarım gerekçeleriyle veriyor, `compute` içinde uzun iş yapmanın somut sonuçlarını söylüyor, alternatif olarak Caffeine'i ve future desenini öneriyor ve CHM'nin dağıtık tutarlılık sağlamadığını belirterek kapsamı doğru çiziyor.\n\n**Takip sorusu:** \"`computeIfAbsent` içinde 80 ms'lik bir HTTP çağrısı yapan bir cache gördün. Neyi, neden değiştirirsin?\""},"href":"/kitap/05-concurrency/"},{"kind":"open","id":"kitap/05-concurrency#3","category":"Java","label":"Concurrency","level":"İleri","short":"$undefined","questionMd":"Bir thread pool'un boyutunu nasıl belirlersin?","answers":{"junior":"Genelde çekirdek sayısının iki katı kadar thread veririm. Ya da `Executors.newFixedThreadPool(100)` gibi yeterince büyük bir sayı veririm, daha çok thread daha çok iş demek.","mid":"İşin türüne bakarım. CPU-yoğun işte çekirdek sayısı kadar thread yeter, fazlası context switch üretir. I/O-yoğun işte thread'ler çoğu zaman beklediği için daha fazla thread gerekir; Goetz'in formülüyle çekirdek × (1 + bekleme/hesaplama). `newFixedThreadPool` sınırsız kuyruk kullandığı için `ThreadPoolExecutor`'ı sınırlı kuyruk ve reddetme politikasıyla kendim kurarım. ThreadPoolExecutor'ın max thread'e ancak kuyruk dolunca çıktığını bilirim.","senior":"$2e","interviewer":"Junior cevap ezber bir oran ve \"daha çok thread daha çok iş\" yanlış inancıyla geliyor; sınırsız kuyruk ve downstream etkisinden habersiz. Mid cevap iş tipine göre ayrım yapıyor, formülü ve ThreadPoolExecutor'ın kuyruk-önce davranışını biliyor. Senior cevap netleştirme sorusuyla başlıyor, Little Yasası ile somut hesap yapıyor, darboğazın downstream'de olduğunu, bulkhead'i, reddetme politikasının yan etkisini ve izlenecek metrikleri söylüyor; virtual thread dünyasında sorunun nasıl değiştiğini de biliyor.\n\n**Takip sorusu:** \"Kuyruğun sürekli dolu olduğunu ve CPU'nun %20'de olduğunu görüyorsun. Ne yaparsın?\""},"href":"/kitap/05-concurrency/"},{"kind":"open","id":"kitap/05-concurrency#4","category":"Java","label":"Concurrency","level":"İleri","short":"$undefined","questionMd":"Servisimizi virtual thread'lere geçirmeli miyiz?","answers":{"junior":"Evet, virtual thread'ler çok hafif ve hızlı. Milyonlarca thread açabiliriz, bu yüzden performans artar. Spring Boot'ta tek bir property ile açılıyor, hemen geçmeliyiz.","mid":"Servis I/O-bound ise, yani zamanının çoğunu DB ve HTTP beklerken geçiriyorsa, virtual thread'ler eşzamanlılık kapasitesini artırır, çünkü bloklama sırasında carrier thread'i bırakırlar. CPU-bound işi hızlandırmazlar. Havuzlanmazlar; eşzamanlılığı Semaphore ile sınırlarım. Java 21'de synchronized içinde bloklama pinning yaratır, bu yüzden kütüphanelerin ve kodun buna uygun olduğunu kontrol ederim. DB havuzu darboğazı devam eder.","senior":"$2f","interviewer":"Junior cevap \"hafif = hızlı\" yanılgısıyla ve ölçmeden geçiş öneriyor; darboğazın kaymasından ve pinning'den habersiz. Mid cevap I/O-bound/CPU-bound ayrımını, havuzlamamayı, pinning'i ve DB darboğazını biliyor. Senior cevap kararı ölçüme bağlıyor, geçişin yan etkisini (doğal rate limiter'ın kalkması) ve önlemlerini sayıyor, sürüm farkını (JEP 491, Java 25 hedefi) ve gözlemlenebilirliği (JFR event'i, Hikari metrikleri, canary) ekliyor, reactive ile karşılaştırmada da dogmatik değil.\n\n**Takip sorusu:** \"Geçişten sonra p99 latency arttı ve DB'de aktif bağlantı sayısı sürekli tavanda. Ne olmuş olabilir, ne yaparsın?\""},"href":"/kitap/05-concurrency/"},{"kind":"open","id":"kitap/05-concurrency#5","category":"Java","label":"Concurrency","level":"Orta","short":"$undefined","questionMd":"Deadlock nedir, nasıl tespit eder ve önlersin?","answers":{"junior":"Deadlock, iki thread'in birbirini sonsuza kadar beklemesidir. Önlemek için synchronized'ı az kullanırım ya da timeout koyarım. Olursa uygulamayı yeniden başlatırım.","mid":"İki thread kilitleri ters sırada alırsa oluşur: biri A'yı tutup B'yi, diğeri B'yi tutup A'yı bekler. Dört Coffman koşulu gerekir: karşılıklı dışlama, tut ve bekle, zorla alınamama, döngüsel bekleme. Thread dump'ta `Found one Java-level deadlock` olarak görünür; jstack ya da `jcmd Thread.print` ile alırım. Kilitleri her zaman aynı sırayla alarak (ör. id'ye göre) ya da `ReentrantLock.tryLock(timeout)` ile önlerim.","senior":"$30","interviewer":"Junior cevap tanımı biliyor ama çözümü belirsiz (\"az kullanırım\") ve restart'ı çözüm sanıyor; tespit yöntemi yok. Mid cevap mekanizmayı, Coffman koşullarını, tespit aracını ve iki standart çözümü veriyor. Senior cevap çözümleri trade-off'larıyla sıralıyor (livelock riski), kilidi kaldırmayı birinci seçenek olarak görüyor, tespitte deadlock ile çekişmeyi ayırıyor, alarm üretmeyi ve health check yanılgısını söylüyor, deadlock'un havuz ve DB seviyesindeki karşılıklarını da kapsıyor.\n\n**Takip sorusu:** \"Transfer servisinin DB'de satırları id sırasıyla kilitlediğinden emin olmak için ne yaparsın, 40P01 gelirse retry'ı nasıl güvenli hale getirirsin?\""},"href":"/kitap/05-concurrency/"},{"kind":"open","id":"kitap/06-spring-ioc-di-ve-bean-yasam-dongusu#1","category":"Spring","label":"Spring IoC, DI ve bean yaşam döngüsü","level":"Başlangıç","short":"$undefined","questionMd":"Neden constructor injection kullanıyorsun? Field injection'ın nesi kötü?","answers":{"junior":"Constructor injection best practice olduğu için kullanıyorum. Field injection'da `@Autowired` yazınca Spring alanı dolduruyor, ama test yazmak zorlaşıyor. Constructor injection'da bağımlılıkları constructor'dan veriyorum, IntelliJ de field injection için uyarı veriyor.","mid":"Constructor injection ile alanlar `final` olur, nesne eksik bağımlılıkla oluşamaz ve testte Spring context'i kaldırmadan `new OrderService(mockRepo, fixedClock)` diye kurabilirim. Field injection'da Spring önce boş nesneyi oluşturur, sonra reflection ile alanları doldurur; Spring dışında `new` dersem alanlar `null` kalır. Ayrıca constructor döngüleri açılışta hata verir, field injection'da Spring bunları erken referansla çözebiliyordu. Opsiyonel bağımlılıklar için `ObjectProvider` kullanırım.","senior":"$31","interviewer":"Junior \"best practice\" ve \"IDE uyarıyor\" diyor; nedeni yok. Mid mekanizmayı biliyor (boş nesne + reflection, final, test) ama gerekçeleri liste olarak sayıyor. Senior bir adım öteye gidiyor: final alanın eşzamanlılık garantisi, constructor boyutunun bir tasarım metriği olması, döngüyü teknik olarak değil tasarımla kırmak ve kuralın ekip ölçeğinde nasıl uygulatılacağı (ArchUnit). Ayrıca \"ne zaman kullanmam\" istisnasını da veriyor.\n\n**Takip sorusu:** \"Constructor'ında 9 bağımlılık olan bir servisi devraldın. Ne yaparsın?\""},"href":"/kitap/06-spring-ioc-di-ve-bean-yasam-dongusu/"},{"kind":"open","id":"kitap/06-spring-ioc-di-ve-bean-yasam-dongusu#2","category":"Spring","label":"Spring IoC, DI ve bean yaşam döngüsü","level":"Orta","short":"$undefined","questionMd":"Spring bean'leri thread-safe mi?","answers":{"junior":"Evet, Spring bean'leri singleton olduğu için thread-safe'tir. Spring her şeyi kendisi yönettiği için eşzamanlılık sorunu olmaz.","mid":"Hayır, Spring thread-safety garantisi vermez. Singleton bean tüm istek thread'leri tarafından paylaşılır, bu yüzden mutable alan tutarsa race condition oluşur. Servisleri stateless tutarım: istek verisi parametre ve local değişkenlerde, alanlar sadece final bağımlılıklar. Prototype veya request scope kullanabilirim ama genelde gerek olmaz.","senior":"$32","interviewer":"Junior'ın cevabı yaygın ve tehlikeli bir yanlış inanç: \"singleton = thread-safe\". Aslında tam tersi: singleton paylaşıldığı için risklidir. Mid doğru kuralı biliyor. Senior kuralın sınırlarını çiziyor: JVM içi state ile dağıtık state farkı, `ThreadLocal` sızıntısı, `synchronized`'ın throughput ve virtual thread maliyeti, tespit stratejisi.\n\n**Takip sorusu:** \"Bir servisin içinde ürün kategorilerini bellekte cache'lemek istiyorsun. Nasıl yaparsın, güncellemeyi nasıl yönetirsin?\""},"href":"/kitap/06-spring-ioc-di-ve-bean-yasam-dongusu/"},{"kind":"open","id":"kitap/06-spring-ioc-di-ve-bean-yasam-dongusu#3","category":"Spring","label":"Spring IoC, DI ve bean yaşam döngüsü","level":"Orta","short":"$undefined","questionMd":"Aynı sınıftaki @Transactional metodu çağırınca neden transaction açılmıyor?","answers":{"junior":"Spring'de aynı sınıftan çağrılan metotlarda `@Transactional` çalışmıyor. Bu yüzden metodu başka bir servise taşımak gerekiyor.","mid":"`@Transactional` proxy ile çalışır. Spring bean'in CGLIB alt sınıfını üretip dışarıya onu verir; proxy çağrıyı yakalayıp transaction açar. Ama sınıfın içinden `this.save()` dediğimde çağrı proxy'ye değil gerçek nesneye gider, interceptor çalışmaz. Aynı sebeple private metotlarda da çalışmaz. Çözüm metodu ayrı bir bean'e taşımak veya anotasyonu dışarıdan çağrılan metoda koymak.","senior":"$33","interviewer":"Junior kuralı ezberlemiş ama nedenini bilmiyor; benzer bir tuzakla (`@Async`, `final` metot) karşılaşınca tanıyamaz. Mid proxy'yi biliyor. Senior proxy'nin hangi aşamada ve hangi bileşen tarafından oluşturulduğunu, aynı mekanizmadan doğan diğer tuzakları, çözümler arasındaki tercihi ve hatanın nasıl test edileceğini söylüyor; somut bir deneyimle bitiriyor.\n\n**Takip sorusu:** \"Bu servis bir interface implemente etseydi ve Boot kullanmasaydık hangi proxy oluşurdu? Somut sınıfı enjekte eden kod ne olurdu?\""},"href":"/kitap/06-spring-ioc-di-ve-bean-yasam-dongusu/"},{"kind":"open","id":"kitap/06-spring-ioc-di-ve-bean-yasam-dongusu#4","category":"Spring","label":"Spring IoC, DI ve bean yaşam döngüsü","level":"İleri","short":"$undefined","questionMd":"Bean yaşam döngüsünü anlat. Açılışta cache ısıtma işini nereye koyarsın?","answers":{"junior":"Bean önce oluşturulur, sonra `@PostConstruct` çalışır, uygulama kapanırken `@PreDestroy` çalışır. Cache ısıtmayı `@PostConstruct` içinde yaparım çünkü bean hazır olduğunda çalışıyor.","mid":"Sıra: tanımlar toplanır, BeanFactoryPostProcessor'lar çalışır, constructor, alan enjeksiyonu, Aware arayüzleri, BeanPostProcessor before, `@PostConstruct`, `afterPropertiesSet`, init-method, BeanPostProcessor after. AOP proxy son adımda oluşur. Bu yüzden `@PostConstruct` içinde `@Transactional` metot çağırırsam transaction açılmaz. Cache ısıtmayı `ApplicationReadyEvent` dinleyen bir bean'den yaparım.","senior":"$34","interviewer":"Junior'ın cevabı en yaygın production hatasını içeriyor: ağır ve transactional işi `@PostConstruct`'a koymak. Mid sırayı ve proxy sonucunu biliyor, doğru yere yakın bir öneri veriyor. Senior tanım ve örnek aşamalarını ayırıyor, hangi callback'in hangi bileşen tarafından çağrıldığını biliyor, kararı Kubernetes readiness ile bağlıyor ve başarısızlık senaryosunu düşünüyor.\n\n**Takip sorusu:** \"Isıtma 3 dakika sürüyor ve liveness probe 60 saniyede pod'u öldürüyor. Ne yaparsın?\""},"href":"/kitap/06-spring-ioc-di-ve-bean-yasam-dongusu/"},{"kind":"open","id":"kitap/07-spring-boot-ve-konfigurasyon#1","category":"Spring","label":"Spring Boot","level":"Orta","short":"$undefined","questionMd":"Spring Boot auto-configuration nasıl çalışır?","answers":{"junior":"Spring Boot classpath'e bakıp gerekli bean'leri otomatik oluşturuyor. Örneğin `spring-boot-starter-data-jpa` eklediğimde DataSource ve repository'ler kendiliğinden geliyor. `@SpringBootApplication` anotasyonu bunu sağlıyor.","mid":"`@SpringBootApplication` içindeki `@EnableAutoConfiguration`, jar'lardaki `AutoConfiguration.imports` dosyalarından auto-config sınıflarını yükler. Bu sınıflar `@ConditionalOnClass`, `@ConditionalOnMissingBean`, `@ConditionalOnProperty` gibi koşullarla korunur. Örneğin Hikari classpath'teyse ve ben `DataSource` tanımlamadıysam Boot kendi `DataSource`'unu kurar; tanımladıysam geri çekilir. Değerleri `spring.datasource.*` gibi `@ConfigurationProperties` sınıflarından alır. Neyin neden yüklendiğini `--debug` ile görürüm.","senior":"$35","interviewer":"Junior \"otomatik\" kelimesinde kalıyor; mekanizma yok. Mid parçaları doğru sayıyor. Senior sıralamanın (deferred import) neden önemli olduğunu, koşulların ayrıntısının nasıl sürpriz yaratabileceğini, ezme stratejilerinin maliyet sırasını ve starter yazarken test yöntemini anlatıyor. \"Varsayılanlara körü körüne güvenmem\" vurgusu da senior işareti.\n\n**Takip sorusu:** \"Şirket içi starter'ın bir servisin kendi `DefaultErrorHandler`'ı ile çakışıyor. Nasıl tasarlardın ki ikisi de mutlu olsun?\""},"href":"/kitap/07-spring-boot-ve-konfigurasyon/"},{"kind":"open","id":"kitap/07-spring-boot-ve-konfigurasyon#2","category":"Spring","label":"Spring Boot","level":"Orta","short":"$undefined","questionMd":"Aynı property birden çok yerde tanımlıysa hangisi kazanır? Prod'da secret'ları nasıl yönetirsin?","answers":{"junior":"`application-prod.yml` varsa o kullanılır, yoksa `application.yml`. Şifreleri de `application-prod.yml`'a yazıyoruz, prod dosyasına sadece yetkililer erişiyor.","mid":"Öncelik sırası kabaca: komut satırı, Java system property, ortam değişkeni, sonra dosyalar; dosyalarda profile özel olan genel olanı, jar dışındaki jar içindekini ezer. Kubernetes'te ortam değişkenleri yml'ı ezer; `SPRING_DATASOURCE_URL` relaxed binding ile bağlanır. Secret'ları git'e koymam; Kubernetes Secret'tan env olarak veririm.","senior":"$36","interviewer":"Junior iki ciddi hata yapıyor: sırayı yalnızca profil üzerinden düşünüyor ve secret'ı dosyaya yazıyor. Mid sırayı ve doğru secret kaynağını biliyor. Senior sırayı resmi listeyle ve \"konum > profil\" inceliğiyle veriyor, belirsizlikte nasıl doğrulayacağını söylüyor, konfigürasyonu deploy güvenliğine (açılışta doğrulama, rollout'un durması) bağlıyor, secret yöntemlerini maliyet ve denetim açısından karşılaştırıyor ve rotasyonu düşünüyor.\n\n**Takip sorusu:** \"Prod'da `checkout.payment-timeout`'u deploy etmeden değiştirmen gerekiyor. Seçeneklerin neler?\""},"href":"/kitap/07-spring-boot-ve-konfigurasyon/"},{"kind":"open","id":"kitap/07-spring-boot-ve-konfigurasyon#3","category":"Spring","label":"Spring Boot","level":"Orta","short":"$undefined","questionMd":"Liveness ve readiness probe farkı nedir? Liveness'a veritabanı kontrolü koyar mısın?","answers":{"junior":"Liveness uygulamanın ayakta olup olmadığını, readiness hazır olup olmadığını kontrol eder. Liveness'a veritabanını koyarım, çünkü veritabanı yoksa uygulama zaten çalışamaz.","mid":"Liveness başarısız olursa Kubernetes container'ı yeniden başlatır, readiness başarısız olursa pod'u trafikten çıkarır. Liveness'a dış bağımlılık koymam; DB gidince tüm pod'lar yeniden başlar ve bir şey düzelmez. DB'yi readiness grubuna eklerim. Spring Boot'ta `/actuator/health/liveness` ve `/readiness` endpoint'leri var.","senior":"$37","interviewer":"Junior'ın cevabı doğrudan production kesintisi üretir: liveness'a DB koymak. Mid doğru ayrımı yapıyor. Senior bunu bir failure mode olarak anlatıyor (failover → toplu restart → thundering herd), readiness kararını bağımlılığın kritikliğine bağlıyor, \"tüm pod'lar not-ready\" yan etkisini biliyor ve startup probe, warm-up, management portu gibi operasyonel detayları ekliyor.\n\n**Takip sorusu:** \"Deploy sırasında her seferinde birkaç yüz 502 görüyorsun. Nereden başlarsın?\""},"href":"/kitap/07-spring-boot-ve-konfigurasyon/"},{"kind":"open","id":"kitap/07-spring-boot-ve-konfigurasyon#4","category":"Spring","label":"Spring Boot","level":"İleri","short":"$undefined","questionMd":"Spring Boot 2'den 3'e geçişte neler değişti, nelerle uğraştınız?","answers":{"junior":"Boot 3'te Java 17 zorunlu oldu ve `javax` paketleri `jakarta` oldu. IntelliJ ile import'ları değiştirdik.","mid":"Java 17 minimum, Jakarta EE geçişi (`javax.persistence` → `jakarta.persistence`), Spring Framework 6, Sleuth yerine Micrometer Tracing, `ProblemDetail` desteği ve native image desteği geldi. Bazı property'ler değişti, `spring-boot-properties-migrator` ile bulduk. Auto-config için artık `AutoConfiguration.imports` kullanılıyor.","senior":"$38","interviewer":"Junior değişikliği \"import'ları değiştirdik\"e indiriyor. Mid değişiklik listesini doğru biliyor. Senior geçişi bir risk yönetimi süreci olarak anlatıyor: transitif bağımlılık taraması, ara sürüm stratejisi, starter kayıt değişikliğinin sessiz başarısızlığı, tracing uyumluluğu, yeni özellikleri ölçerek benimseme.\n\n**Takip sorusu:** \"Virtual thread'leri açtınız ve p99 latency kötüleşti. Ne bakarsın?\""},"href":"/kitap/07-spring-boot-ve-konfigurasyon/"},{"kind":"open","id":"kitap/08-transaction-ve-jpa#1","category":"Spring","label":"Transaction yönetimi ve JPA","level":"Orta","short":"$undefined","questionMd":"@Transactional nasıl çalışır? Hangi durumlarda çalışmaz?","answers":{"junior":"`@Transactional` koyduğum metotta işlem başlar, metot bitince commit olur, hata olursa rollback olur. Private metotlarda ve aynı sınıftan çağırınca çalışmadığını biliyorum.","mid":"Spring bean'in proxy'sini oluşturur; proxy'deki `TransactionInterceptor` metot öncesinde `PlatformTransactionManager` ile transaction açar, sonra commit veya rollback eder. Varsayılan olarak `RuntimeException` ve `Error`'da rollback, checked exception'da commit yapar; `rollbackFor` ile değiştirilir. Çağrı proxy'den geçmezse çalışmaz: self-invocation, private metot, `@PostConstruct`. Başka thread'de de transaction taşınmaz, çünkü thread-local'a bağlı.","senior":"$39","interviewer":"Junior iki tuzağı ezberlemiş ama rollback kuralını \"hata olursa rollback\" diye genelliyor; checked exception'da commit olduğunu bilmiyor. Mid mekanizmayı ve ana tuzakları biliyor. Senior zinciri halkalara ayırıp her halkanın hangi hata sınıfını ürettiğini gösteriyor, rollback-only gibi ince bir davranışı biliyor, önlemleri tasarım seviyesinde anlatıyor ve doğrulama stratejisi veriyor.\n\n**Takip sorusu:** \"Bir Kafka listener'ından bu servisi çağırıyorsun ve listener'ın kendisi de `@Transactional`. Kafka offset commit'i ile DB commit'i arasındaki ilişki nedir?\""},"href":"/kitap/08-transaction-ve-jpa/"},{"kind":"open","id":"kitap/08-transaction-ve-jpa#2","category":"Spring","label":"Transaction yönetimi ve JPA","level":"Orta","short":"$undefined","questionMd":"REQUIRED ile REQUIRES_NEW farkı nedir? REQUIRES_NEW'i ne zaman kullanırsın?","answers":{"junior":"REQUIRED varsa mevcut transaction'ı kullanır, yoksa yeni açar. REQUIRES_NEW her zaman yeni transaction açar. Loglama gibi şeyler için REQUIRES_NEW kullanırım ki ana işlem hata alsa da log kalsın.","mid":"REQUIRED mevcut fiziksel transaction'a katılır; iç metot hata verirse tüm transaction rollback-only olur. REQUIRES_NEW dıştakini askıya alıp ayrı bir fiziksel transaction açar, bağımsız commit veya rollback olur. Audit kaydı için kullanırım. Dikkat: REQUIRES_NEW ikinci bir bağlantı ister, yük altında havuz tükenebilir. Ayrıca iç metodun ayrı bir bean'de olması gerekir, yoksa self-invocation yüzünden yeni transaction açılmaz.","senior":"$3a","interviewer":"Junior tanımı ve doğru bir kullanım örneğini biliyor ama bedelini bilmiyor. Mid havuz riskini ve self-invocation şartını ekliyor. Senior iki ayrı bedel kategorisi (kaynak ve tutarlılık) çıkarıyor, iki bağlantının birbirini kilitlemesi gibi daha ince bir failure mode'u biliyor, alternatif tasarım öneriyor ve gözlemlenebilirlikle bitiriyor.\n\n**Takip sorusu:** \"Havuz tükenmesini production'da nasıl teşhis edersin? Hangi log ve metriklere bakarsın?\""},"href":"/kitap/08-transaction-ve-jpa/"},{"kind":"open","id":"kitap/08-transaction-ve-jpa#3","category":"Spring","label":"Transaction yönetimi ve JPA","level":"Orta","short":"$undefined","questionMd":"N+1 problemini nasıl tespit eder ve çözersin?","answers":{"junior":"N+1, bir listeyi çekip sonra her eleman için ayrı sorgu atılmasıdır. EAGER yaparak çözerim, böylece ilişkiler hep birlikte gelir.","mid":"Liste sorgusundan sonra her elemanın lazy ilişkisine erişince ek sorgu atılıyor. SQL log'larını açarak tespit ederim. Çözüm olarak `JOIN FETCH` veya `@EntityGraph` kullanırım, ya da `default_batch_fetch_size` ile lazy yüklemeleri gruplarım. Okuma ekranlarında DTO projection daha verimli. EAGER kullanmam çünkü her sorguda gereksiz veri getirir.","senior":"$3b","interviewer":"Junior'ın cevabı yaygın bir yanlış inanç içeriyor: EAGER N+1'i çözmez, çoğu zaman kötüleştirir. Mid doğru araçları biliyor. Senior tespit, koruma ve çözümü kullanım şekline (sayfalama, koleksiyon sayısı, okuma/yazma) göre ayırıyor; fetch join'in sınırlarını mekanizmasıyla anlatıyor ve global ayarlarla bir savunma hattı kuruyor.\n\n**Takip sorusu:** \"Bir endpoint'in sorgu sayısını testte nasıl doğrularsın? Bu test neden bazen kırılgan olur?\""},"href":"/kitap/08-transaction-ve-jpa/"},{"kind":"open","id":"kitap/08-transaction-ve-jpa#4","category":"Spring","label":"Transaction yönetimi ve JPA","level":"İleri","short":"$undefined","questionMd":"Optimistic ve pessimistic locking arasında nasıl seçim yaparsın? Flash sale stoğu için hangisi?","answers":{"junior":"Optimistic locking `@Version` ile yapılır, pessimistic locking satırı kilitler. Stok için pessimistic kullanırım çünkü daha güvenli.","mid":"Optimistic'te kilit yok; `@Version` kolonu UPDATE'te `WHERE version = ?` koşulu olur, başkası değiştirdiyse `OptimisticLockException` alırım ve yeniden denerim. Çatışma nadirse iyidir. Pessimistic'te `SELECT FOR UPDATE` ile satırı kilitlerim, diğerleri bekler; çatışma sıksa uygundur ama deadlock ve bekleme riski var. Flash sale'de çatışma çok fazla olduğu için optimistic'te çoğu istek fail olur; pessimistic veya atomik bir UPDATE daha iyi.","senior":"$3c","interviewer":"Junior \"daha güvenli\" diyerek gerekçesiz bir seçim yapıyor. Mid iki yaklaşımı ve çatışma sıklığı kriterini doğru anlatıyor. Senior üçüncü bir yolu (atomik koşullu UPDATE) neden en uygun olduğunu mekanizmasıyla açıklıyor, onun da sınırını (hot row) biliyor ve ölçek büyüyünce mimariyi nasıl değiştireceğini, doğruluğu nasıl test edeceğini söylüyor.\n\n**Takip sorusu:** \"Redis'te stok düştün, sonra DB'ye sipariş yazarken uygulama çöktü. Stok tutarsızlığını nasıl yakalarsın ve düzeltirsin?\""},"href":"/kitap/08-transaction-ve-jpa/"},{"kind":"open","id":"kitap/09-sql-sorgulari#1","category":"Veri","label":"SQL sorguları","level":"Başlangıç","short":"$undefined","questionMd":"Hiç siparişi olmayan müşterileri bul. NOT IN ile NOT EXISTS arasında fark var mı?","answers":{"junior":"`SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders)` yazarım. NOT EXISTS de olur, ikisi aynı sonucu verir, NOT IN daha okunur.","mid":"NOT EXISTS yazarım. NOT IN'in bir tuzağı var: alt sorgu tek bir NULL döndürürse `id NOT IN (..., NULL)` hiçbir satır için TRUE olmaz ve sorgu boş döner. LEFT JOIN orders ... WHERE o.id IS NULL da eşdeğer. Performans olarak NOT EXISTS genelde iyi, PostgreSQL onu anti-join'e çeviriyor.","senior":"NOT EXISTS yazarım, iki nedenle. Doğruluk: NOT IN üç değerli mantıkta `x <> a AND x <> NULL` demek; tek NULL tüm ifadeyi UNKNOWN yapar ve sorgu hata vermeden boş döner. Bugün `customer_id` NOT NULL olsa da alt sorgu yarın nullable bir kolona ya da LEFT JOIN'li bir view'a dönerse rapor sessizce sıfırlanır; bu tür bug'lar ancak bir iş birimi \"rapor neden boş\" dediğinde fark edilir. Performans: NULL semantiği yüzünden PostgreSQL NOT IN'i anti-join'e çeviremiyor; planda `hashed SubPlan` görürsün ve sonuç `work_mem`'e sığmazsa satır başına tarama yapan karesel bir plana düşer. NOT EXISTS ise Hash/Merge Anti Join olur. `orders(customer_id)` index'inin olduğundan emin olurum; PostgreSQL foreign key kolonlarına otomatik index açmaz. Büyük tabloda bu raporu canlı primary'de değil replica'da çalıştırırım.","interviewer":"Junior'ın cevabı \"aynı sonucu verir\" dediği için yanlış: NULL varlığında farklı sonuç verir, bu sorunun asıl ölçtüğü şey de budur. Mid tuzağı biliyor ve doğru aracı seçiyor. Senior mekanizmayı (üç değerli mantık), sessiz arıza modunu (hata yok, boş sonuç), planner'ın neden farklı plan ürettiğini ve operasyonel tarafı (FK index'i, replica) birlikte veriyor.\n\n**Takip sorusu:** \"Pozitif yönde `IN (SELECT ...)` için de aynı NULL tuzağı geçerli mi?\" (Hayır: `1 IN (1, NULL)` TRUE'dur; NULL sadece eşleşme üretmez.)"},"href":"/kitap/09-sql-sorgulari/"},{"kind":"open","id":"kitap/09-sql-sorgulari#2","category":"Veri","label":"SQL sorguları","level":"Orta","short":"$undefined","questionMd":"Her kategoride en çok satan 3 ürünü getiren sorguyu yaz.","answers":{"junior":"`ORDER BY sum(quantity) DESC LIMIT 3` yazarım, kategoriye göre de GROUP BY yaparım.","mid":"Önce ürün bazında toplam satışları bir CTE'de hesaplarım, sonra `row_number() OVER (PARTITION BY category_id ORDER BY total DESC)` ile kategori içinde numaralandırırım, dış sorguda `rn <= 3` ile filtrelerim. Window function WHERE'de kullanılamadığı için CTE gerekiyor. Eşitlik varsa rank veya dense_rank düşünülebilir.","senior":"Önce iki şeyi netleştiririm: \"en çok satan\" adet mi ciro mu, ve 3. sırada eşitlik olursa ne olacak. Tam 3 satır isteniyorsa `row_number()` ile `ORDER BY total DESC, product_id` (tie-breaker olmazsa sonuç deterministik değil, testler arada kırılır); eşitler dahil isteniyorsa `rank()`. Yapı üç adım: ürün bazında topla, partition içinde sırala, dışta filtrele. Ölçek tarafında iki alternatif bilirim. Kategori sayısı az ve önceden toplanmış satış tablosu varsa `categories CROSS JOIN LATERAL (... ORDER BY total DESC LIMIT 3)` her kategori için index'e bir kez iner, tüm ürünleri sıralamaz. Bu bir \"çok satanlar\" rozetiyse her istekte hesaplanmaz; event'lerden beslenen ürün/gün satış tablosundan periyodik hesaplanıp cache'lenir, birkaç dakikalık gecikme kabul edilir. Doğrulamak için eşitlik ve tek ürünlü kategori içeren küçük bir test verisiyle çalıştırırım.","interviewer":"Junior'ın `LIMIT 3`'ü tüm sonucun ilk 3'ünü alır, kategori başına değil: problemi gruplu düşünemediğini gösterir. Mid doğru kalıbı ve WHERE kısıtının nedenini biliyor. Senior gereksinimi netleştiriyor (adet/ciro, eşitlik politikası), deterministik sonuç için tie-breaker ekliyor, LATERAL alternatifiyle index kullanımını düşünüyor ve hesaplamanın nerede yapılması gerektiğini (canlı sorgu mu, önceden toplama mı) tartışıyor.\n\n**Takip sorusu:** \"Bu sorguda PARTITION BY'ı unutsaydın ne olurdu?\" (Tüm ürünler tek pencerede numaralanır; sadece genel ilk 3 gelir.)"},"href":"/kitap/09-sql-sorgulari/"},{"kind":"open","id":"kitap/09-sql-sorgulari#3","category":"Veri","label":"SQL sorguları","level":"Orta","short":"$undefined","questionMd":"Satıcı bazında satış toplamını ve iade toplamını tek sorguda getirdim ama sayılar çok büyük çıkıyor. Neden?","answers":{"junior":"Muhtemelen JOIN yanlış, DISTINCT eklerim, `sum(DISTINCT ...)` ile düzelir.","mid":"Fan-out. order_items ve returns ikisi de ürüne göre birden çok satır içeriyor; aynı join'de birleşince satırlar çarpılıyor ve her toplam diğer tablonun satır sayısı kadar tekrarlanıyor. Her ölçüyü ayrı CTE'de satıcıya göre toplayıp sonra satıcı üzerinden join yaparım.","senior":"Fan-out: iki bağımsız bire-çok ilişkiyi aynı join'e koyunca sonuç kümesinin tanecikliği \"sipariş satırı × iade\" olur ve her `sum` diğer tarafın kardinalitesiyle çarpılır. Teşhis için toplamadan önce `count(*)` ile satır sayısına bakarım; beklenen grain'den fazlaysa sebep budur. Düzeltme aggregate-then-join: her ölçüyü kendi CTE'sinde join anahtarına indirip 1:1 birleştiririm. `sum(DISTINCT)` bir düzeltme değil, ikinci bir bug'dır: aynı tutarlı iki farklı siparişi tek sayar. `count(DISTINCT id)` sayımlarda maskeleyebilir ama toplamlarda işe yaramaz. Bu tür raporlar için bir regresyon testi tutarım: bilinen küçük bir veri setinde beklenen toplamlar sabit; join eklenince test kırılır. Bu hata canlıda genelde \"finans raporu ile satıcı paneli tutmuyor\" diye fark edilir, yani maliyeti yüksektir.","interviewer":"Junior'ın `sum(DISTINCT)` önerisi yaygın bir yanlış inanç ve sonucu farklı bir şekilde yanlış yapar. Mid kavramı ve doğru düzeltmeyi biliyor. Senior grain kavramıyla teşhis yöntemini (satır sayısına bakmak), neden `DISTINCT`'in çözüm olmadığını ve bu hatayı önleyecek test stratejisini ekliyor.\n\n**Takip sorusu:** \"Satış ve iadeyi ürün bazında değil sipariş satırı bazında eşleştirmek isteseydin join koşulu ne olurdu?\" (`r.order_id = oi.order_id AND r.product_id = oi.product_id`; o zaman da bir satırın birden çok iadesi varsa iadeler önce o anahtara göre toplanmalı.)"},"href":"/kitap/09-sql-sorgulari/"},{"kind":"open","id":"kitap/09-sql-sorgulari#4","category":"Veri","label":"SQL sorguları","level":"İleri","short":"$undefined","questionMd":"Flash sale'de stok düşüren SQL'i yaz. Aynı anda 1000 istek gelirse ne olur?","answers":{"junior":"Önce `SELECT quantity FROM stock WHERE product_id = ?` ile stoğa bakarım, yeterliyse `UPDATE stock SET quantity = ?` yaparım. Metodun üstüne @Transactional koyarım, transaction olduğu için güvenli olur.","mid":"Tek bir koşullu UPDATE yazarım: `UPDATE stock SET quantity = quantity - :qty WHERE product_id = :id AND quantity >= :qty`. Etkilenen satır sayısı 0 ise stok yetersizdir. Select-then-update yarış koşulu yaratır, @Transactional bunu çözmez çünkü READ COMMITTED'da SELECT kilit almaz. Ayrıca tabloya `CHECK (quantity >= 0)` koyarım.","senior":"Koşullu, atomik UPDATE yazarım ve dönüşteki satır sayısıyla karar veririm; `RETURNING quantity` ile kalan stoğu da alırım. Mekanizması: UPDATE satır kilidi alır, eşzamanlı ikinci UPDATE bekler, ilki commit olunca READ COMMITTED'da WHERE'i satırın yeni sürümünde yeniden değerlendirir; stok bittiyse 0 satır döner. Böylece overselling imkansız, CHECK constraint de bug'lara karşı son savunma. 1000 istekte doğruluk sorunu yok, throughput sorunu var: hepsi tek satırın kilidinde sıraya girer, transaction'lar ne kadar uzunsa kuyruk o kadar uzar. Bu yüzden transaction'ı kısa tutarım: stok düşümü, sipariş ve outbox kaydı aynı transaction'da, ödeme gibi dış çağrılar dışında. Ölçmek için `pg_stat_activity`'de `wait_event_type = 'Lock'` sayısına ve p99 latency'ye bakarım. Bu yetmezse hot SKU için Redis'te Lua ile atomik ön eleme yaparım (stok bitince istekler DB'ye hiç gelmez), DB yine nihai kaynak olur ve bir reconciliation job iki tarafı karşılaştırır. Ödeme süresi uzunsa düşüm yerine TTL'li rezervasyon modeli kurarım.","interviewer":"Junior'ın cevabı klasik lost update hatası ve \"@Transactional her şeyi çözer\" yanılgısı içeriyor. Mid doğru SQL'i ve nedenini biliyor. Senior kilit/yeniden değerlendirme mekanizmasını, hot row throughput sınırını, transaction süresinin etkisini, ölçüm yöntemini ve bir sonraki ölçek adımını (Redis ön eleme, rezervasyon) trade-off'larıyla anlatıyor.\n\n**Takip sorusu:** \"REPEATABLE READ'de aynı UPDATE çalışsaydı ikinci istek ne alırdı?\" (`could not serialize access due to concurrent update` hatası; uygulama retry etmeli.)"},"href":"/kitap/09-sql-sorgulari/"},{"kind":"open","id":"kitap/09-sql-sorgulari#5","category":"Veri","label":"SQL sorguları","level":"Orta","short":"$undefined","questionMd":"Sipariş listesini sayfalıyoruz, 1000. sayfadan sonra API yavaşlıyor. Ne yaparsın?","answers":{"junior":"OFFSET'i küçültürüm ya da sayfa boyutunu artırırım. Index eklerim.","mid":"OFFSET N satırı okuyup atar, maliyet sayfa numarasıyla artar. Keyset sayfalamaya geçerim: son görülen `(created_at, id)` değerini cursor olarak alırım ve `WHERE (created_at, id) < (:c, :i) ORDER BY created_at DESC, id DESC LIMIT 20` yazarım. `(customer_id, created_at DESC, id DESC)` index'i ile her sayfa sabit sürede gelir.","senior":"Önce EXPLAIN ANALYZE ile doğrularım: OFFSET'te planda okunan satır sayısı `offset + limit` kadardır; 1 milyon satırlık bir tabloda 900.000 offset 200 ms sürerken keyset 0,06 ms sürdü. Keyset'e geçerim, cursor'ı istemciye opak bir token olarak veririm ki iç yapıya bağımlı olmasın. Bedelini de söylerim: sayfaya atlama yok, sıralama kriteri değişirse cursor geçersiz. Ürün ekibi \"sayfa 47\" istiyorsa bu bir UX kararıdır; çoğu zaman sonsuz kaydırma yeterlidir. Toplam sayıyı her istekte `count(*)` ile hesaplamam, MVCC yüzünden tarama gerektirir; tahmini sayı ya da \"1000+\" gösteririm. Ayrıca derin sayfaları kimin istediğine bakarım: çoğu zaman bir scraper ya da \"tümünü dışa aktar\" ihtiyacıdır ve onun doğru çözümü asenkron bir export job'ıdır.","interviewer":"Junior semptomu tedavi ediyor, mekanizmayı bilmiyor. Mid doğru çözümü ve gereken index'i biliyor. Senior ölçüyle doğruluyor, API tasarımını (opak cursor), keyset'in sınırlarını ve asıl ihtiyacın ne olduğunu (export) sorguluyor.\n\n**Takip sorusu:** \"Keyset'te sıralama kolonu benzersiz değilse ne olur?\" (Aynı değerli satırlar sayfa sınırında atlanır veya tekrarlanır; benzersiz tie-breaker eklenir.)"},"href":"/kitap/09-sql-sorgulari/"},{"kind":"open","id":"kitap/10-postgresql-index-izolasyon-ve-kilitleme#1","category":"Veri","label":"PostgreSQL","level":"Orta","short":"$undefined","questionMd":"Tabloya index ekledik ama sorgu hâlâ yavaş ve EXPLAIN Seq Scan gösteriyor. Ne yaparsın?","answers":{"junior":"Index'in doğru kolonda olduğundan emin olurum. Gerekirse index'i silip yeniden oluştururum ya da hint ile index'i kullanmaya zorlarım.","mid":"Önce koşulun sargable olup olmadığına bakarım: kolon fonksiyonla sarılmış mı (`lower`, `date`), tip uyuşmazlığı var mı, `LIKE '%x'` mi. Composite index'se sol-öncelik kuralına uyuyor mu. Sonra seçiciliğe bakarım: sorgu satırların çoğunu döndürüyorsa Seq Scan doğrudur. İstatistikler eskiyse `ANALYZE` çalıştırırım. EXPLAIN ANALYZE ile tahmini ve gerçek satır sayısını karşılaştırırım.","senior":"EXPLAIN (ANALYZE, BUFFERS) ile başlarım ve iki soruyu ayırırım: index bu koşula kullanılabilir mi, kullanılabiliyorsa planner neden daha pahalı buluyor. Kullanılamıyorsa sebep genelde sorgudadır: fonksiyon sarmalama, tip uyuşmazlığı (Java'dan yanlış tipte bind edilen parametre dahil), collation, composite index'te eksik baş kolon; sorguyu index'e uydururum ya da expression/partial index eklerim. Kullanılabiliyor ama seçilmiyorsa tahmin ile gerçek satırı karşılaştırırım; büyük sapma istatistik sorunudur (ANALYZE, korele kolonlar için CREATE STATISTICS), tahmin doğruysa planner muhtemelen haklıdır ve asıl iş sorguyu daraltmaktır. Prepared statement ise generic plan ihtimaline bakarım; SSD'de `random_page_cost` 4'te kaldıysa onu da. PostgreSQL'de planner hint'i yok ve olmaması bilinçli bir tercih; `enable_seqscan=off`'u sadece teşhis için oturumda kullanırım. Değişikliği CONCURRENTLY ile yapıp `pg_stat_statements`'ta sorgunun ortalama süresi ve buffer sayısıyla önce/sonra ölçerim.","interviewer":"Junior'ın \"index'i zorlarım\" cevabı PostgreSQL'de bir hint mekanizması olduğunu varsayıyor ve Seq Scan'in doğru tercih olabileceğini görmüyor. Mid kontrol listesini biliyor. Senior \"kullanılamaz\" ile \"kullanılabilir ama pahalı\" ayrımını yapıyor, her birinin teşhis yolunu, generic plan ve maliyet parametresi gibi daha derin sebepleri ve ölçümle doğrulamayı ekliyor.\n\n**Takip sorusu:** \"EXPLAIN'de rows=1 tahmin edip actual rows=500000 görüyorsun. Bu hangi plan hatasına yol açar?\" (Planner Nested Loop seçer ve iç taraf yüz binlerce kez çalışır; Hash Join olmalıydı.)"},"href":"/kitap/10-postgresql-index-izolasyon-ve-kilitleme/"},{"kind":"open","id":"kitap/10-postgresql-index-izolasyon-ve-kilitleme#2","category":"Veri","label":"PostgreSQL","level":"Orta","short":"$undefined","questionMd":"PostgreSQL'in varsayılan izolasyon seviyesi nedir ve neyi garanti etmez?","answers":{"junior":"Varsayılan SERIALIZABLE, transaction'lar birbirini hiç etkilemez. Bu yüzden @Transactional koyduğumuzda veri tutarlı olur.","mid":"Varsayılan READ COMMITTED. Dirty read olmaz ama non-repeatable read ve phantom olabilir; her ifade kendi snapshot'ını alır. Lost update da olabilir, o yüzden atomik UPDATE ya da kilit kullanırım. REPEATABLE READ PostgreSQL'de snapshot isolation'dır, phantom'ı da önler. SERIALIZABLE her şeyi önler ama retry gerekir.","senior":"READ COMMITTED: her ifade yeni snapshot alır; satır yazarken kilitli satırı bekler ve WHERE'i en güncel sürümde yeniden değerlendirir. Bu yüzden koşullu tek ifadeli UPDATE'ler güvenlidir ama okuma-hesaplama-yazma desenleri lost update üretir, kural kontrolü yapıp farklı satırlara yazan akışlar da write skew üretir. REPEATABLE READ tek snapshot ve eşzamanlı güncellemede `40001` hatası verir; lost update'i engeller ama write skew'i engellemez. SERIALIZABLE (SSI) write skew'i de yakalar; bedeli predicate lock maliyeti ve yanlış pozitif iptaller. Pratikte varsayılanı korurum ve korumayı noktasal yaparım: atomik UPDATE'ler, gerekiyorsa `FOR UPDATE` ile tutarlı sırada kilit, para gibi invariant'larda constraint ve ledger. Bir akışı SERIALIZABLE'a alırsam transaction'ı kısa ve idempotent yazarım, retry'ı transaction'ın dışından kurarım ve 40001 oranını metrik olarak izlerim.","interviewer":"Junior'ın cevabı yaygın bir yanılgı: hem varsayılanı yanlış biliyor hem de @Transactional'ın izolasyon garantisi verdiğini sanıyor. Mid seviyeleri ve PostgreSQL'e özgü davranışı doğru biliyor. Senior her seviyenin yazma kuralını (bekle-yeniden değerlendir ya da hata), hangi anomalinin hangi seviyede kaldığını (write skew) ve operasyonel sonucu (retry, metrik) anlatıyor.\n\n**Takip sorusu:** \"REPEATABLE READ'de snapshot BEGIN'de mi alınır?\" (Hayır, ilk SELECT/DML ifadesinde.)"},"href":"/kitap/10-postgresql-index-izolasyon-ve-kilitleme/"},{"kind":"open","id":"kitap/10-postgresql-index-izolasyon-ve-kilitleme#3","category":"Veri","label":"PostgreSQL","level":"İleri","short":"$undefined","questionMd":"Optimistic mi pessimistic lock mu? Nasıl karar verirsin?","answers":{"junior":"Optimistic daha performanslı çünkü kilit yok, her zaman @Version kullanırım.","mid":"Çekişmeye göre karar veririm. Çakışma nadirse @Version ile optimistic ve retry; sık çakışma varsa retry'lar boşa iş yapar, FOR UPDATE ile pessimistic daha iyi. Kullanıcının bir formu dakikalarca düzenlediği akışta veritabanı kilidi tutulamaz, orada optimistic şart.","senior":"Önce kilide ihtiyaç olup olmadığına bakarım: hesap tek SQL ifadesine sığıyorsa atomik UPDATE ikisinden de iyidir. Sığmıyorsa üç ölçüte bakarım. Çekişme: aynı satıra eşzamanlı yazma olasılığı düşükse optimistic, yüksekse (popüler ürün stoğu, ortak bir sayaç) pessimistic; yüksek çekişmede optimistic retry fırtınası üretir ve p99'u patlatır. Okuma-yazma arası süre: kullanıcı düşünme süresi veya istekler arası akış varsa DB kilidi tutulamaz, optimistic (HTTP'de ETag/If-Match ile) tek seçenektir. Kilitlenen satır sayısı ve sırası: pessimistic'te birden fazla satır kilitleniyorsa sırayı sabitlerim, `lock_timeout` koyarım, transaction'da dış çağrı yapmam. İki yaklaşımı da ölçerim: optimistic'te `ObjectOptimisticLockingFailureException` oranı, pessimistic'te lock wait süresi ve `pg_stat_activity`'deki Lock beklemeleri. Retry'ı her iki durumda transaction dışından, sınırlı sayıda ve jitter'lı backoff ile yaparım.","interviewer":"Junior \"kilit yok, o halde hızlı\" diyerek çekişme altında optimistic'in maliyetini görmüyor. Mid doğru ölçütü (çekişme) ve uzun düşünme süresi örneğini biliyor. Senior önce kilitsiz çözümü sorguluyor, kararı üç ölçüte bağlıyor, failure mode'ları (retry fırtınası, deadlock) ve gözlemlenebilirliği ekliyor.\n\n**Takip sorusu:** \"@Version alanı olan bir entity'de bulk JPQL UPDATE yaparsan version artar mı?\" (Hayır, bulk update persistence context'i ve version'ı atlar; elle `version = version + 1` yazılmalı.)"},"href":"/kitap/10-postgresql-index-izolasyon-ve-kilitleme/"},{"kind":"open","id":"kitap/11-nosql-arama-ve-cap#1","category":"Veri","label":"NoSQL, arama ve CAP","level":"Orta","short":"$undefined","questionMd":"Bizim sistemimiz CP mi AP mi?","answers":{"junior":"CAP'e göre üçünden ikisini seçebiliriz. Bizde PostgreSQL var, o CA'dır; Elasticsearch ve Redis AP'dir. Yani sistem genel olarak AP.","mid":"Dağıtık sistemde partition kaçınılmaz, o yüzden asıl seçim partition sırasında C ile A arasında. PostgreSQL primary'ye yazdığımız sürece tutarlıyız ama primary düşerse yazamayız, o kısım CP. ES ve Redis eventual consistent, AP tarafında. Async replica'dan okuma da bayat olabilir.","senior":"Tek etiket vermem, çünkü CAP'in C'si linearizability, A'sı da \"her çalışan node her isteğe cevap verir\" gibi katı bir tanım; çoğu gerçek sistem ikisine de tam uymaz. İşlem bazında anlatırım: stok ve ödeme primary PostgreSQL'de, bölünmede hata dönmeyi seçiyoruz; arama ES'de, bölünmede bile cevap veriyor ama Kafka lag'i ve refresh kadar geride; sepet Redis'te, failover'da onaylanmış yazma kaybolabileceği için sipariş anında kaynakta yeniden doğruluyoruz. PACELC ile normal çalışmayı da söylerim: async replica ile gecikme için tutarlılıktan vazgeçtik, bu yüzden \"siparişlerim\" gibi read-your-writes gereken okumalar primary'ye gidiyor. Bunu ölçülebilir kılarım: replication lag, consumer lag ve ES refresh gecikmesi için SLO ve alarm. Netleştirme sorusu da sorarım: \"Hangi işlem için soruyorsunuz, hangi hata senaryosunda?\"","interviewer":"Junior iki yaygın yanılgıyı birden yapıyor: \"üçünden ikisi\" ve PostgreSQL'i \"CA\" sınıflandırmak. Mid teoremin doğru ifadesini biliyor ve bileşen bazında düşünüyor. Senior terimlerin katı tanımlarını, işlem bazında kararları, PACELC'i, her kararın kullanıcıya etkisini ve ölçümünü veriyor; soruyu netleştiriyor.\n\n**Takip sorusu:** \"Sipariş verdikten hemen sonra kullanıcı 'siparişlerim' sayfasında siparişini göremiyor. Neden olabilir, nasıl çözersin?\" (Replica lag ya da ES lag; read-your-writes için primary'ye yönlendirme, yazma sonrası kısa süre yapışkan okuma ya da istemciye dönen veriyle ekranı güncelleme.)"},"href":"/kitap/11-nosql-arama-ve-cap/"},{"kind":"open","id":"kitap/11-nosql-arama-ve-cap#2","category":"Veri","label":"NoSQL, arama ve CAP","level":"İleri","short":"$undefined","questionMd":"Ürün güncellemelerini Couchbase'den Elasticsearch'e nasıl senkron tutarsın?","answers":{"junior":"Ürünü kaydeden servis önce Couchbase'e, sonra Elasticsearch'e yazar. Hata olursa try-catch ile tekrar deneriz.","mid":"Dual write yapmam, çünkü ikinci yazma başarısız olursa iki sistem tutarsız kalır. Couchbase'in DCP akışını okuyan bir connector ile değişiklikleri ES'ye aktarırım, ya da değişiklikleri Kafka'ya event olarak yayınlayıp bir consumer ile ES'yi güncellerim. Sistem eventually consistent olur, arama birkaç saniye geride kalabilir.","senior":"Uygulama sadece doğruluk kaynağına yazar; ES değişiklik akışından türetilir: DCP connector ya da DCP'den Kafka'ya, oradan bir consumer. Dual write'ı reddetme sebebim sadece kısmi hata değil, sıra yarışı da: iki eşzamanlı güncelleme ES'ye ters sırayla ulaşırsa arama kalıcı olarak eski kalır. Akış tarafında üç garanti kurarım: aynı ürünün değişiklikleri aynı partition'da (key = productId), ES'ye kaynak versiyonuyla `version_type=external` yazma (eski versiyon yeniyi ezemez), idempotent işleme (at-least-once). Silmeler tombstone olarak akar. Index'e alias üzerinden erişirim; mapping değişince yeni index'i kaynaktan doldurup akışı yetiştirir, alias'ı atomik çeviririm. Lag'i SLO olarak ölçerim ve periyodik bir mutabakat job'ı ile sapmaları yeniden index'lerim. Ürün detayı ve sepet ES'den değil, kaynaktan okunur.","interviewer":"Junior'ın try-catch'i kısmi hatayı sadece kısmen çözüyor; ikinci yazma kalıcı başarısız olursa ya da sıra bozulursa tutarsızlık kalıyor. Mid doğru mimariyi biliyor. Senior sıra yarışını, versiyonlu yazmayı, silme ve reindex'i, ölçüm ve mutabakatı ekleyerek gerçek bir production tasarımı anlatıyor.\n\n**Takip sorusu:** \"Connector bir saat boyunca durdu. Geri geldiğinde ne olur, ne yaparsın?\" (DCP/Kafka offset'inden kaldığı yerden devam eder; akış o kadar geriye saklanmadıysa tam reindex. O süre boyunca lag alarmı çalmalıydı.)"},"href":"/kitap/11-nosql-arama-ve-cap/"},{"kind":"open","id":"kitap/11-nosql-arama-ve-cap#3","category":"Veri","label":"NoSQL, arama ve CAP","level":"Orta","short":"$undefined","questionMd":"Ürün detayını Redis'te cache'liyoruz. Fiyat değişince kullanıcılar eski fiyatı görüyor. Ne yaparsın?","answers":{"junior":"TTL'i kısaltırım, 1 dakika yaparım. Ya da fiyat değişince cache'i yeni fiyatla güncellerim.","mid":"Fiyat güncellendiğinde cache'teki anahtarı silerim; bir sonraki okuma DB'den güncel değeri yükler. Silmeyi DB commit'inden sonra yaparım, önce silersem araya giren bir okuma eski değeri cache'e geri yazabilir. TTL'i de sigorta olarak tutarım.","senior":"Güncellemek yerine silerim, çünkü iki eşzamanlı yazma cache'e ters sırayla ulaşırsa güncelleme yaklaşımı cache'i kalıcı olarak eski bırakır. Silmeyi commit sonrasına bağlarım (`@TransactionalEventListener(AFTER_COMMIT)`) ya da daha iyisi CDC'den türetirim, böylece fiyatı değiştiren her kod yolu (admin paneli, toplu import, kampanya job'ı) otomatik kapsanır. Okuma ile cache yazma arasındaki küçük yarış penceresi için TTL sigortası ve gerekirse gecikmeli ikinci silme. Asıl kararı ise iş tarafıyla netleştiririm: listelemede birkaç saniyelik eski fiyat kabul edilebilir mi? Ödeme ve sepet adımında fiyat zaten cache'ten değil, kaynaktan okunmalı; aksi halde bu bir tutarlılık değil, para hatasıdır. Gözlemlemek için cache hit oranını ve \"cache'teki versiyon ile kaynak versiyonu\" farkını örnekleyen bir metrik eklerim.","interviewer":"Junior iki çözüm önerisinde de yanılıyor: kısa TTL sorunu küçültür ama çözmez, cache'i güncellemek ise sıra yarışı yaratır. Mid doğru kalıbı ve sıralamayı biliyor. Senior yarışın mekanizmasını, tüm yazma yollarını kapsayan CDC'yi, iş gereksinimini netleştirmeyi ve kararın kritik akıştaki sonucunu (ödeme kaynaktan) anlatıyor.\n\n**Takip sorusu:** \"Kampanya başladığı an en popüler ürünün cache'i boşalırsa ne olur?\" (Cache stampede; tek yükleyici, refresh-ahead, TTL jitter.)"},"href":"/kitap/11-nosql-arama-ve-cap/"},{"kind":"open","id":"kitap/11-nosql-arama-ve-cap#4","category":"Veri","label":"NoSQL, arama ve CAP","level":"İleri","short":"$undefined","questionMd":"Elasticsearch zaten verimizi tutuyor. Couchbase'i kaldırıp ES'yi tek veritabanı yapalım mı?","answers":{"junior":"Olabilir, ES hem arama yapıyor hem de veriyi saklıyor, iki sistemi yönetmekten kurtuluruz.","mid":"Önermem. ES'de transaction yok, near real-time olduğu için yazılan hemen okunmayabilir, mapping değişikliği reindex gerektirir. Birincil kaynak ayrı kalmalı, ES türetilmiş bir read model olmalı.","senior":"Önermem ve nedenini maliyet üzerinden anlatırım. Doğruluk tarafı: çok dokümanlı atomik işlem yok, read-your-writes için refresh beklemek gerekiyor, aggregation'lar shard bazında yaklaşık. Operasyon tarafı: ES'nin bozulduğu ya da mapping'in değişmesi gereken gün veriyi yeniden kuracak bir kaynağımız olmaz; reindex'i ES'nin kendi `_source`'undan yapmak zorunda kalırız, bozuk veriyi bozuk veriden kurarız. Yazma tarafı: her güncelleme sil-ekle ve segment merge maliyeti, yoğun güncellenen alanlar (stok) için pahalı. Yine de iki sistemin maliyeti gerçekse alternatifleri tartarım: belki Couchbase'in Search servisi küçük bir ihtiyaç için yeter, belki PostgreSQL full-text ve trigram ile arama ihtiyacı karşılanır. Kural şu: doğruluk kaynağı transaction'lı ve yeniden kurulabilir olmalı, arama motoru her an kaynaktan yeniden üretilebilen bir projeksiyon. ES'nin tek kaynak olduğu meşru durum log ve metrik gibi kaybı kabul edilebilir, append-only veridir.","interviewer":"Junior operasyonel basitliği görüyor ama doğruluk ve kurtarma maliyetini görmüyor. Mid temel teknik engelleri sayıyor. Senior bunları failure mode ve kurtarma senaryosu üzerinden anlatıyor, ihtiyacı karşılayabilecek daha basit alternatifleri tartıyor ve meşru istisnayı belirtiyor.\n\n**Takip sorusu:** \"Mapping'de bir alanın tipini keyword'den text'e çevirmemiz gerekti. Kesintisiz nasıl yaparsın?\" (Yeni index, kaynaktan doldur + akışı yeni index'e de uygula, alias'ı atomik çevir, eski index'i sonra sil.)"},"href":"/kitap/11-nosql-arama-ve-cap/"},{"kind":"open","id":"kitap/12-kafka#1","category":"Dağıtık Sistemler","label":"Kafka","level":"Orta","short":"$undefined","questionMd":"Kafka'da mesaj sırası nasıl garanti edilir?","answers":{"junior":"Kafka mesajları sıralı tutar, consumer da sırayla okur. Sıranın bozulmaması için tek partition kullanırım ya da consumer'ı tek thread yaparım.","mid":"Kafka sıra garantisini sadece partition içinde verir. Sıranın önemli olduğu event'leri aynı key ile gönderirim; ör. key olarak `orderId` kullanırsam bir siparişin bütün event'leri aynı partition'a gider ve o partition'ı tek bir consumer sırayla işler. Producer'da idempotence açık olmalı, yoksa retry ile birlikte `max.in.flight` 1'den büyükken sıra bozulabilir. Tek partition kullanmak global sıra verir ama paralelliği öldürür.","senior":"$3d","interviewer":"Junior \"Kafka sıralıdır\" diyerek yaygın bir yanlışı tekrar ediyor; sıranın sadece partition içinde olduğunu bilmiyor. Mid doğru mekanizmayı (key → partition) ve producer tarafındaki idempotence/in-flight ilişkisini biliyor. Senior sıra garantisini bir zincir olarak görüyor: outbox relay, partition artırma, async işleme ve retry topic'in sırayı nasıl bozduğunu sayıyor ve iş seviyesinde versiyon kontrolü ile savunma ekliyor.\n\n**Takip sorusu:** Partition sayısını 6'dan 12'ye çıkarman gerekiyor ve sipariş bazında sıra kritik. Geçişi nasıl yaparsın?"},"href":"/kitap/12-kafka/"},{"kind":"open","id":"kitap/12-kafka#2","category":"Dağıtık Sistemler","label":"Kafka","level":"İleri","short":"$undefined","questionMd":"Kafka'da bir mesajın iki kez işlenmesini nasıl önlersin? Kafka exactly-once değil mi?","answers":{"junior":"Kafka'da `enable.idempotence=true` ve exactly-once ayarı var, onu açarsam mesaj bir kez işlenir.","mid":"Idempotent producer sadece producer retry'larından doğan duplicate'i engeller. Consumer tarafında rebalance veya commit'ten önce çökme yüzünden aynı mesaj tekrar gelebilir. Kafka transaction'ları Kafka'dan okuyup Kafka'ya yazarken exactly-once sağlar, ama DB'ye yazıyorsam kapsamaz. O yüzden at-least-once kullanırım ve consumer'ı idempotent yaparım: mesaj id'sini `processed_event` tablosuna yazarım, unique constraint ile tekrarı yakalarım.","senior":"$3e","interviewer":"Junior iki ayrı kavramı (idempotent producer ve EOS) \"bir ayar\" olarak görüyor; en yaygın yanlış inanç bu. Mid kapsamı doğru ayırıyor ve standart çözümü veriyor. Senior \"teslimat bir kez\" ile \"etki bir kez\" arasındaki farkı kuruyor, check-then-act yarışını, harici API'leri, tablonun büyümesini ve test stratejisini ekliyor.\n\n**Takip sorusu:** `processed_event` kaydı ile iş kaydını aynı transaction'a koyamadığın bir durum (ör. iş, bir HTTP çağrısı) varsa ne yaparsın?"},"href":"/kitap/12-kafka/"},{"kind":"open","id":"kitap/12-kafka#3","category":"Dağıtık Sistemler","label":"Kafka","level":"Orta","short":"$undefined","questionMd":"Consumer'da bir mesaj sürekli hata veriyor. Ne olur, ne yaparsın?","answers":{"junior":"Hata olursa try/catch ile yakalayıp loglarım, böylece consumer durmaz ve diğer mesajlara geçer.","mid":"Exception'ı yutarsam offset commit edilir ve mesaj kaybolur. Bunun yerine Spring Kafka'da `DefaultErrorHandler` kullanırım: birkaç kez backoff ile dener, olmazsa `DeadLetterPublishingRecoverer` ile mesajı DLT'ye atar ve sonraki mesaja geçer. Parse hatası gibi retry ile düzelmeyecek hataları `addNotRetryableExceptions` ile doğrudan DLT'ye yönlendiririm. Deserialization hataları için `ErrorHandlingDeserializer` kullanırım.","senior":"Önce hatanın sınıfına bakarım, çünkü doğru tepki ona göre değişir:\n\n- **Kalıcı, mesaja özgü** (bozuk JSON, iş kuralı ihlali): Retry anlamsız. Doğrudan DLT, alarm, sahip ekip inceler, düzeltip replay eder.\n- **Geçici, mesaja özgü değil** (DB anlık yok, downstream 503): Kısa backoff ile birkaç deneme. Sıra kritikse blocking retry; değilse `@RetryableTopic`.\n- **Downstream tamamen çökmüş:** Her mesajı DLT'ye atmak yanlış olur; o dakikalardaki tüm trafik DLT'ye dolar. Circuit breaker açıldığında container'ı pause ederim, lag birikir, downstream dönünce kaldığım yerden devam ederim.\n\nDikkat ettiğim tuzaklar: backoff aralığı `max.poll.interval.ms`'e yaklaşırsa rebalance tetiklenir; DLT'nin partition sayısı kaynak topic'ten az olmamalı; DLT adı Spring Kafka 3.3 ile `.DLT`'den `-dlt`'ye döndü, bu yüzden adı resolver ile açıkça veririm. DLT'ye düşen mesaj sayısını, partition bazında lag'i ve rebalance sayısını izlerim. DLT'nin bir sahibi ve replay aracı yoksa DLT sadece mesajların gittiği bir mezarlıktır.","interviewer":"Junior'ın cevabı production'da sessiz veri kaybıdır; mülakatta kırmızı bayraktır. Mid standart Spring Kafka kurulumunu biliyor. Senior hataları sınıflandırıyor, \"downstream çöktüğünde DLT'ye atma, tüketimi durdur\" diyerek back-pressure düşünüyor, sürüm farkı ve DLT'nin operasyonel sahipliği gibi gerçek hayat detaylarını ekliyor.\n\n**Takip sorusu:** DLT'deki 5.000 mesajı düzelttikten sonra tekrar işletirken sıra ve duplicate açısından nelere dikkat edersin?"},"href":"/kitap/12-kafka/"},{"kind":"open","id":"kitap/12-kafka#4","category":"Dağıtık Sistemler","label":"Kafka","level":"Orta","short":"$undefined","questionMd":"Kafka'da mesaj kaybını nasıl önlersin?","answers":{"junior":"`acks=all` yaparım, böylece mesaj tüm replikalara yazılmadan onay gelmez ve kaybolmaz.","mid":"Producer'da `acks=all` ve idempotence, topic'te replication factor 3 ve `min.insync.replicas=2` kullanırım. Böylece onay en az iki replikaya yazınca gelir. Consumer'da auto commit yerine işlemden sonra commit ederim, exception yutmam ve DLT kullanırım.","senior":"$3f","interviewer":"Junior `acks=all`'u \"tüm replikalar\" sanıyor; ISR kavramını ve `min.insync.replicas`'ı bilmiyor. Mid doğru config setini veriyor. Senior kaybı uçtan uca üç segmente ayırıyor; asenkron `send()`'in yutulan hatasını, retention ile kesinti süresinin ilişkisini ve availability bedelini açıkça söylüyor.\n\n**Takip sorusu:** `min.insync.replicas=2` iken iki broker aynı anda bakıma alınırsa producer'lar ne görür, sen bunu nasıl önlersin?"},"href":"/kitap/12-kafka/"},{"kind":"open","id":"kitap/13-saga-outbox-ve-idempotency#1","category":"Dağıtık Sistemler","label":"Saga, Transactional Outbox ve Idempotency","level":"Orta","short":"$undefined","questionMd":"Sipariş oluşunca kargo servisine Kafka ile haber vermek istiyorsun. Nasıl yaparsın?","answers":{"junior":"`OrderService`'te siparişi kaydettikten sonra `kafkaTemplate.send` ile `OrderCreated` event'ini gönderirim. Metodu `@Transactional` yaparım, hata olursa her şey geri alınır.","mid":"`@Transactional` sadece DB'yi kapsar; Kafka gönderimi transaction'ın parçası değildir. Send commit'ten önce yapılırsa ve commit fail olursa var olmayan bir sipariş için event gider; commit'ten sonra yapılırsa ve gönderim fail olursa event kaybolur. Bu dual write problemi. Transactional Outbox kullanırım: event'i siparişle aynı transaction'da `outbox_event` tablosuna yazarım, bir scheduler bu tabloyu okuyup Kafka'ya gönderir ve gönderildi diye işaretler. Teslimat at-least-once olduğu için kargo servisi idempotent olmalı.","senior":"$40","interviewer":"Junior `@Transactional`'ın Kafka'yı kapsadığını sanıyor; en yaygın ve en tehlikeli yanlış. Mid dual write'ı adlandırıyor ve standart çözümü veriyor. Senior outbox'ı bir ürün gibi ele alıyor: relay seçiminin trade-off'u, sıralamanın üç ayrı kırılma noktası, replication slot riski, relay'in transaction süresi, temizlik ve izleme. \"Ne zaman kullanmam\" cümlesi de olgunluk göstergesi.\n\n**Takip sorusu:** Outbox relay'i üç pod'da çalışıyor ve aynı siparişin `OrderCreated` ve `OrderCancelled` event'leri ters sırayla yayınlandı. Bu nasıl oldu, nasıl düzeltirsin?"},"href":"/kitap/13-saga-outbox-ve-idempotency/"},{"kind":"open","id":"kitap/13-saga-outbox-ve-idempotency#2","category":"Dağıtık Sistemler","label":"Saga, Transactional Outbox ve Idempotency","level":"İleri","short":"$undefined","questionMd":"Saga'yı orchestration ile mi choreography ile mi kurarsın?","answers":{"junior":"Choreography daha iyi, çünkü merkezi bir servis yok ve servisler gevşek bağlı oluyor. Her servis event dinleyip kendi işini yapıyor.","mid":"Duruma göre. Choreography'de her servis event dinler ve yayınlar; basit ama adım sayısı artınca akışı takip etmek zorlaşır. Orchestration'da bir orchestrator komut gönderir ve cevapları dinler; akış ve telafi mantığı tek yerdedir ama orchestrator'a mantık birikebilir. Sipariş gibi çok adımlı ve telafili bir akışta orchestration, basit akışlarda choreography seçerim.","senior":"$41","interviewer":"Junior choreography'yi koşulsuz \"daha iyi\" ilan ediyor; gevşek bağlılığın akış görünürlüğü bedelini görmüyor. Mid doğru trade-off'u söylüyor. Senior seçim kriterlerini açıkça veriyor, orchestrator'ın nasıl sağlam kurulacağını (outbox, idempotent cevap işleme, timeout) anlatıyor, iki yaklaşımı birlikte kullanıyor ve workflow motoru alternatifini biliyor.\n\n**Takip sorusu:** Orchestrator `ChargePayment` komutunu gönderdi, 5 dakikadır cevap yok. Ödeme alındı mı bilmiyorsun. Ne yaparsın?"},"href":"/kitap/13-saga-outbox-ve-idempotency/"},{"kind":"open","id":"kitap/13-saga-outbox-ve-idempotency#3","category":"Dağıtık Sistemler","label":"Saga, Transactional Outbox ve Idempotency","level":"İleri","short":"$undefined","questionMd":"Flash sale: 100 stok, 10 pod, saniyede binlerce istek. Overselling'i nasıl önlersin?","answers":{"junior":"Stok kontrolünü `synchronized` bir metotta yaparım, böylece aynı anda tek thread stok düşer. Ya da Redis ile distributed lock alırım.","mid":"`synchronized` sadece tek JVM'de çalışır, 10 pod'da işe yaramaz. DB'de atomik bir koşullu UPDATE kullanırım: `UPDATE stock SET quantity = quantity - 1 WHERE product_id = ? AND quantity >= 1`. Etkilenen satır 0 ise stok yoktur. PostgreSQL satırı kilitlediği için iki istek aynı stoğu düşemez. Ayrıca `CHECK (quantity >= 0)` koyarım. Distributed lock'a gerek yok.","senior":"$42","interviewer":"Junior iki yaygın yanlışı birden yapıyor: tek JVM'lik `synchronized` ve gereksiz distributed lock. Mid doğru atomik UPDATE'i biliyor. Senior doğruluk ile throughput'u ayırıyor, hot row ve connection havuzu etkisini görüyor, Redis'in kalıcılık zayıflığını hesaba katıp katmanlı bir tasarım kuruyor, ölçüm ve test stratejisi ekliyor.\n\n**Takip sorusu:** Redis'te stok düştü, DB'ye sipariş yazarken uygulama çöktü. Redis'teki stok ne olacak?"},"href":"/kitap/13-saga-outbox-ve-idempotency/"},{"kind":"open","id":"kitap/13-saga-outbox-ve-idempotency#4","category":"Dağıtık Sistemler","label":"Saga, Transactional Outbox ve Idempotency","level":"Orta","short":"$undefined","questionMd":"Mobil uygulama ödeme isteğini timeout sonrası tekrar gönderiyor. Çift çekimi nasıl önlersin?","answers":{"junior":"İstek gelince aynı kullanıcının son birkaç saniyede aynı tutarda ödemesi var mı diye kontrol ederim, varsa ikinciyi reddederim.","mid":"Idempotency key kullanırım. İstemci her ödeme için bir UUID üretip `Idempotency-Key` header'ında gönderir, retry'larda aynısını kullanır. Sunucu key'i ödeme kaydıyla birlikte unique olarak saklar; aynı key tekrar gelirse yeni ödeme oluşturmadan ilk cevabı döner. Unique constraint eşzamanlı iki isteğin yarışını kapatır.","senior":"$43","interviewer":"Junior zaman ve tutar sezgisine dayalı bir deduplikasyon öneriyor; aynı tutarda iki meşru ödemeyi reddeder, gecikmeli retry'ı kaçırır. Mid standart çözümü ve unique constraint'in rolünü biliyor. Senior key kapsamını, fingerprint'i, eşzamanlı istek tasarımını, idempotency'nin harici sağlayıcıya kadar uzatılmasını ve hangi sonucun saklanacağı kararını konuşuyor.\n\n**Takip sorusu:** Sağlayıcıya ödeme isteği gönderdin ve timeout aldın. Kayıt `IN_PROGRESS`'te. Kullanıcı aynı key ile tekrar geldi. Ne yaparsın?"},"href":"/kitap/13-saga-outbox-ve-idempotency/"},{"kind":"open","id":"kitap/14-dayaniklilik-resilience#1","category":"Dağıtık Sistemler","label":"Dayanıklılık","level":"Orta","short":"$undefined","questionMd":"Harici bir API'yi senkron çağırıyorsun. Hangi dayanıklılık önlemlerini alırsın?","answers":{"junior":"Çağrıyı try-catch ile sararım, hata olursa birkaç kez tekrar denerim. Resilience4j ile `@CircuitBreaker` ve `@Retry` eklerim.","mid":"Dört şey eklerim: connect ve read timeout, sadece idempotent çağrılarda exponential backoff + jitter ile retry, circuit breaker ve fallback. Timeout'u API'nin p99'una göre seçerim. Circuit breaker hata oranı eşiği aşınca açılır, OPEN'da çağrı göndermez, HALF_OPEN'da birkaç deneme yapar. 4xx hatalarını retry etmem ve circuit breaker'da saymam. Gerekirse bulkhead ile eşzamanlı çağrı sayısını sınırlarım.","senior":"$44","interviewer":"Junior araç isimlerini sayıyor ama timeout'tan hiç bahsetmiyor; oysa timeout'suz bir circuit breaker yavaşlığa karşı geç kalır. Ayrıca ayrım yapmadan retry ediyor. Mid doğru dört deseni ve 4xx ayrımını biliyor. Senior ölçümle başlıyor, Little's law ile kapasite düşünüyor, varsayılan değerlerin tuzaklarını (yavaş çağrı eşiği, CB açıkken retry) biliyor, fallback'i iş kararı olarak ele alıyor, test ve metrik ekliyor ve \"bu çağrı senkron olmak zorunda mı\" diye sorarak problemi kökten değiştiriyor.\n\n**Takip sorusu:** Circuit breaker 20 pod'un her birinde ayrı çalışıyor. Bunun sakıncası var mı, ne zaman önemli olur?"},"href":"/kitap/14-dayaniklilik-resilience/"},{"kind":"open","id":"kitap/14-dayaniklilik-resilience#2","category":"Dağıtık Sistemler","label":"Dayanıklılık","level":"İleri","short":"$undefined","questionMd":"Retry ne zaman durumu kötüleştirir?","answers":{"junior":"Çok fazla retry yaparsak sistem yavaşlar. O yüzden retry sayısını 3 ile sınırlarım.","mid":"Üç durumda: idempotent olmayan işlemlerde çift etki yaratır (çift ödeme); aşırı yüklenmiş bir servise retry yükü artırır ve toparlanmasını engeller; birden fazla katman retry ederse denemeler çarpılır. Çözüm olarak idempotency key, exponential backoff + jitter, tek katmanda retry ve circuit breaker kullanırım.","senior":"$45","interviewer":"Junior retry'ın tehlikesini \"yavaşlık\" olarak görüyor ve sayıyı sınırlamayı çözüm sanıyor; 3 deneme de katmanlarda çarpılır. Mid üç temel riski biliyor. Senior retry'ın aşırı yükte neden zararlı olduğunu mekanizmasıyla anlatıyor, retry budget ve deadline propagation gibi ileri çözümleri öneriyor ve retry'ın faydasını ölçülebilir bir metrikle sorguluyor.\n\n**Takip sorusu:** Retry budget'ı somut olarak nasıl uygularsın? Hangi metriğe göre?"},"href":"/kitap/14-dayaniklilik-resilience/"},{"kind":"open","id":"kitap/14-dayaniklilik-resilience#3","category":"Dağıtık Sistemler","label":"Dayanıklılık","level":"İleri","short":"$undefined","questionMd":"Circuit breaker nasıl çalışır, değerlerini nasıl seçersin?","answers":{"junior":"Circuit breaker hata sayısı artınca açılır ve istekleri engeller, bir süre sonra tekrar kapanır. Değerleri genelde varsayılan bırakırım.","mid":"Üç durumu var. CLOSED'da çağrılar geçer ve sonuçlar sliding window'da tutulur. Hata oranı eşiği aşılırsa OPEN olur ve çağrılar gönderilmeden `CallNotPermittedException` ile reddedilir. Bekleme süresi dolunca HALF_OPEN'a geçer, birkaç deneme çağrısına izin verir; başarılıysa CLOSED, değilse yine OPEN. Değerler: sliding window 50-100 çağrı, hata eşiği %50, OPEN süresi birkaç saniye ile birkaç on saniye arası. Yavaş çağrı eşiğini de ayarlarım.","senior":"$46","interviewer":"Junior \"varsayılanı bırakırım\" diyor; q15 senaryosunda bu, devrenin hiç açılmaması demek. Mid mekanizmayı doğru anlatıyor ve makul değerler veriyor. Senior değerleri trafik ve gecikme ölçümünden türetiyor, varsayılanların somut tuzaklarını sayıyor, hangi hatanın sayılacağını ayırıyor, `METRICS_ONLY` ile güvenli devreye alma ve gözlemlenebilirlik ekliyor.\n\n**Takip sorusu:** Pod başına saniyede 2 çağrı alan düşük trafikli bir bağımlılık için sliding window'u nasıl kurarsın?"},"href":"/kitap/14-dayaniklilik-resilience/"},{"kind":"open","id":"kitap/14-dayaniklilik-resilience#4","category":"Dağıtık Sistemler","label":"Dayanıklılık","level":"Orta","short":"$undefined","questionMd":"Liveness ve readiness probe'larına veritabanı kontrolü koymalı mıyız?","answers":{"junior":"Evet, servis DB olmadan çalışamıyorsa liveness probe'u DB'yi kontrol etmeli ki DB yoksa pod yeniden başlasın.","mid":"Liveness'a koymam; DB çökünce tüm pod'lar restart olur ve restart DB'yi düzeltmez. Liveness sadece process'in kendisinin takılıp takılmadığını kontrol etmeli. Readiness'a, servis DB olmadan hiç çalışamıyorsa koyabilirim; o zaman pod trafikten çıkar ama restart olmaz.","senior":"$47","interviewer":"Junior en yaygın ve en tehlikeli hatayı öneriyor: liveness'ı bağımlılığa bağlamak. Mid liveness/readiness ayrımını doğru yapıyor. Senior readiness'ın da tüm filoyu aynı anda kapatabileceğini görüyor, restart'ın DB'ye ikinci dalga yük getirmesini mekanizmasıyla anlatıyor ve bağımlılık arızasını probe yerine istek seviyesinde yönetmeyi öneriyor.\n\n**Takip sorusu:** Uygulama açılışta 40 saniye cache ısıtıyor. Bu süre boyunca probe'ları nasıl yapılandırırsın?"},"href":"/kitap/14-dayaniklilik-resilience/"},{"kind":"open","id":"kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat#1","category":"Operasyon","label":"Kubernetes, gözlemlenebilirlik ve teslimat hattı","level":"Başlangıç","short":"$undefined","questionMd":"Liveness ve readiness probe arasındaki fark nedir? Spring Boot servisinde nasıl ayarlarsın?","answers":{"junior":"Liveness uygulamanın ayakta olup olmadığını kontrol eder, readiness da trafik almaya hazır olup olmadığını. İkisini de `/actuator/health`'e bağlarım; böylece DB ya da Redis giderse pod restart olur ve sorun çözülür.","mid":"Liveness fail ederse container restart edilir, readiness fail ederse pod Service'ten çıkarılır ama öldürülmez. Spring Boot'ta `/actuator/health/liveness` ve `/actuator/health/readiness` gruplarını kullanırım; liveness'a DB koymam, çünkü DB gidince bütün pod'lar restart olur. Spring Boot yavaş açılıyorsa `startupProbe` eklerim ki liveness açılışta öldürmesin.","senior":"$48","interviewer":"Junior cevap tanımı biliyor ama tam olarak production'ı çökerten yanlışı öneriyor: bağımlılığı liveness'a bağlamak. Mid cevap doğru ayrımı ve startupProbe'u biliyor; ancak readiness'ın da ortak bağımlılıkta benzer bir etki yarattığını ve sayıların nasıl seçildiğini anlatmıyor. Senior cevap probe'ları \"hangi aksiyonu tetikler\" üzerinden tanımlıyor, failure mode'u (filo çapında restart, boş Service) ve alternatifini (circuit breaker) söylüyor, management port tuzağı ve kapanıştaki gecikme gibi işletme detaylarını ekliyor.\n\n**Takip sorusu:** Uygulamanın Kafka consumer'ı kalıcı olarak koptu ama HTTP tarafı çalışıyor. Bu durumu hangi probe'a yansıtırsın, yoksa hiçbirine mi?"},"href":"/kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat/"},{"kind":"open","id":"kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat#2","category":"Operasyon","label":"Kubernetes, gözlemlenebilirlik ve teslimat hattı","level":"İleri","short":"$undefined","questionMd":"Pod'un OOMKilled oluyor ama JVM metriklerinde heap kullanımı düşük görünüyor. Nasıl araştırırsın?","answers":{"junior":"Heap yetmiyordur, `-Xmx`'i artırırım ya da memory limitini yükseltirim. Bir de heap dump alıp memory leak var mı bakarım.","mid":"OOMKilled heap OOM'u değil, process'in toplam belleğinin container limitini aşmasıdır; heap dump da alınmaz çünkü kernel process'i doğrudan öldürür. Heap dışında metaspace, thread stack'leri, direct buffer'lar var. `-Xmx`'i limite eşitlemişlerse sorun budur; `MaxRAMPercentage=70` gibi bir değere geçerim. `kubectl describe pod` ile reason'ın gerçekten OOMKilled olduğunu ve exit code 137'yi doğrularım.","senior":"$49","interviewer":"Junior cevap iki farklı olayı (Java heap OOM ve kernel OOM kill) karıştırıyor ve işe yaramayacak bir aracı (heap dump) öneriyor. Mid cevap mekanizmayı ve en yaygın nedeni doğru biliyor. Senior cevap teşhisi doğruluyor (137'nin belirsizliği), ölçümle ilerliyor (working set vs JVM metrikleri, NMT diff), somut şüpheli listesi veriyor ve \"limiti artırmak\" ile \"kök nedeni çözmek\" arasındaki farkı açıkça söylüyor.\n\n**Takip sorusu:** CPU limiti 500m olan bir pod'da `Runtime.availableProcessors()` kaç döner ve bu uygulamanın davranışını nerelerde değiştirir?"},"href":"/kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat/"},{"kind":"open","id":"kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat#3","category":"Operasyon","label":"Kubernetes, gözlemlenebilirlik ve teslimat hattı","level":"İleri","short":"$undefined","questionMd":"Production'da sipariş API'sinin p99 latency'si iki katına çıktı. Nasıl araştırırsın?","answers":{"junior":"Log'lara bakarım, hata var mı diye. CPU ve bellek grafiklerine bakarım; yüksekse pod sayısını artırırım.","mid":"Önce ne zaman başladığına ve o sırada deploy olup olmadığına bakarım. Endpoint bazında p99'a bakıp hangi endpoint'in etkilendiğini bulurum. Sonra yavaş isteklerin trace'lerini açıp zamanın nerede geçtiğini görürüm: DB sorgusu mu, dış servis mi. DB ise slow query log ve `EXPLAIN ANALYZE`'a bakarım.","senior":"$4a","interviewer":"Junior cevap rastgele bakıyor ve \"pod artır\" diyor; bu, sorun bir DB kilidi ya da havuz tükenmesiyse durumu kötüleştirir. Mid cevap mantıklı bir sıra izliyor ama kapsamı daraltma ve hipotez testi yapmıyor; trace'e doğrudan atlıyor. Senior cevap sistematik: zaman korelasyonu, kapsam (hepsi mi biri mi), USE metrikleriyle hipotez, sonra trace'le kanıt. Ayrıca \"önce etkiyi azalt (rollback)\" ve \"olaydan sonra gözlemlenebilirlik boşluğunu kapat\" diyerek operasyonel olgunluk gösteriyor.\n\n**Takip sorusu:** Grafana'daki p99 paneli pod'ların kendi hesapladığı p99'ların ortalamasını gösteriyorsa bu panele ne kadar güvenirsin?"},"href":"/kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat/"},{"kind":"open","id":"kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat#4","category":"Operasyon","label":"Kubernetes, gözlemlenebilirlik ve teslimat hattı","level":"Orta","short":"$undefined","questionMd":"Bir kolonun adını sıfır kesintiyle nasıl değiştirirsin?","answers":{"junior":"Flyway'de `ALTER TABLE orders RENAME COLUMN address TO shipping_address` migration'ı yazarım, entity'deki alan adını değiştiririm ve deploy ederim.","mid":"Rolling update sırasında eski pod'lar eski kolon adını kullanmaya devam eder, bu yüzden tek adımda rename kırılır. Önce yeni kolonu eklerim, kod iki kolona da yazar, eski veriyi kopyalarım, sonra okumayı yeni kolona alırım, en sonda eski kolonu silerim.","senior":"$4b","interviewer":"Junior cevap, rolling update'te iki sürümün aynı anda çalıştığını hesaba katmıyor; rollout'un ilk dakikasında eski pod'lar hata verir, rollback da kırık olur. Mid cevap doğru sırayı biliyor. Senior cevap sırayı bir \"geri alınabilirlik\" kuralına bağlıyor, PostgreSQL'e özgü kilit davranışını ve backfill'in operasyonel etkisini düşünüyor, migration'ın nerede çalışacağını ve event/sözleşme tarafını ekliyor, sonunda da maliyet sorusunu soruyor.\n\n**Takip sorusu:** Yeni sürüm, eski sürümün okuyamadığı yeni bir enum değeri yazmaya başladı. Rollback yaparsan ne olur, bunu nasıl önlersin?"},"href":"/kitap/15-kubernetes-gozlemlenebilirlik-ve-teslimat/"},{"kind":"open","id":"kitap/16-test-stratejisi-ve-tdd#1","category":"Zanaat","label":"Test stratejisi, Mockito, Testcontainers ve TDD","level":"Başlangıç","short":"$undefined","questionMd":"Unit test ile integration test arasındaki sınırı nasıl çizersin?","answers":{"junior":"Unit test tek bir metodu test eder ve her şeyi mock'larız. Integration test ise Spring context'i ayağa kaldırır ve veritabanına bağlanır. Genelde her servis sınıfı için unit test yazarım, controller'lar için de birkaç integration test.","mid":"Unit test bir sınıfın mantığını bağımlılıkları test double ile değiştirerek test eder; hızlıdır, iş kuralları ve sınır değerler için kullanırım. Integration testte gerçek altyapıyla (Testcontainers ile PostgreSQL, Kafka) birlikte çalışmayı test ederim: SQL, mapping, transaction. Controller için `@WebMvcTest`, repository için `@DataJpaTest` gibi dilimleri kullanırım ki tüm context'i yüklemeyeyim.","senior":"$4c","interviewer":"Junior cevap \"unit = her şeyi mock'la\" yanılgısını taşıyor ve kararı sınıf türüne göre veriyor. Mid cevap araçları ve dilimleri doğru biliyor. Senior cevap sınırı bir ilkeye bağlıyor (risk mantıkta mı mekanizmada mı), mock'ların neyi kanıtlayamadığını açıkça söylüyor, refactor dayanıklılığı (sociable), test paketinin maliyeti (context cache, container) ve `@Transactional` testlerin gizlediği şeyler gibi işletme detaylarını ekliyor.\n\n**Takip sorusu:** `@Transactional` ile işaretli bir integration testinin geçip production'da patlayabileceği iki somut durum söyler misin?"},"href":"/kitap/16-test-stratejisi-ve-tdd/"},{"kind":"open","id":"kitap/16-test-stratejisi-ve-tdd#2","category":"Zanaat","label":"Test stratejisi, Mockito, Testcontainers ve TDD","level":"Başlangıç","short":"$undefined","questionMd":"Mock ile stub arasındaki fark ne? Ne zaman mock kullanmazsın?","answers":{"junior":"Mock sahte nesnedir, stub da sahte bir metottur. Mockito'da `mock()` ile oluşturur, `when` ile davranış veririz. Dış bağımlılıkların hepsini mock'larım.","mid":"Stub önceden belirlenmiş cevap döner ve sonucu (durumu) doğrularım; mock ise etkileşimi doğrular, `verify` ile. Mockito'da aynı nesne ikisi için de kullanılabilir. Value object'leri ve kendi domain sınıflarımı mock'lamam; gerçeğini oluşturmak daha kolay. Void metotlar için `doThrow().when()` kullanırım.","senior":"Ayrım kullanımda: stub ile durum doğrularım, mock ile davranış. Kuralım \"sorgulara stub, komutlara mock\": `findById`'i stub'larım ve sonuca bakarım, ayrıca `verify(repo).findById(...)` yazmam çünkü bu testi implementasyona kilitler. `save`, `send`, `publish` gibi yan etkiler davranışın kendisiyse onları `verify` ederim, `ArgumentCaptor` ile içeriklerini de.\n\nMock'lamadıklarım: value object, entity (builder kullanırım), kendi domain mantığım ve sahibi olmadığım tipler. `KafkaTemplate`'i mock'lamak, Kafka'nın nasıl davrandığına dair benim varsayımımı test eder; onu kendi `EventPublisher` arayüzümün arkasına sarar, uygulamada o arayüzü mock'lar, sarmalayıcıyı gerçek Kafka ile test ederim. Saati de mock'lamam, `Clock` enjekte ederim. Bir test kurulumu çok fazla mock gerektiriyorsa bunu test sorunu değil tasarım sinyali olarak okurum: sınıf çok fazla işbirlikçiyi koordine ediyordur. Strict stubs'ı da bilinçli kullanırım; `UnnecessaryStubbingException` genelde testin sandığım yoldan geçmediğini gösterir.","interviewer":"Junior cevap kavramları karıştırıyor ve \"her şeyi mock'la\" diyor; bu, refactor'da sürekli kırılan testlere götürür. Mid cevap doğru tanımı ve temel istisnaları biliyor. Senior cevap ayrımı bir karar kuralına dönüştürüyor (sorgu ve komut), \"don't mock what you don't own\" ilkesini gerekçesi ve alternatifiyle anlatıyor ve mock sayısını tasarım geri bildirimi olarak okuyor.\n\n**Takip sorusu:** Bir spy üzerinde `when(spy.calculate()).thenReturn(...)` yazdığında beklenmedik bir şey olabilir mi? Neden?"},"href":"/kitap/16-test-stratejisi-ve-tdd/"},{"kind":"open","id":"kitap/16-test-stratejisi-ve-tdd#3","category":"Zanaat","label":"Test stratejisi, Mockito, Testcontainers ve TDD","level":"Orta","short":"$undefined","questionMd":"TDD uyguluyor musun? Live coding'de nasıl görünür?","answers":{"junior":"Evet, önce testi yazıp sonra kodu yazıyorum. Live coding'de de önce bütün testleri yazar, sonra implementasyona geçerim.","mid":"Red-green-refactor döngüsüyle çalışırım: başarısız bir test, onu geçiren en basit kod, sonra testler yeşilken refactor. Live coding'de küçük adımlarla ilerler, her adımda testleri çalıştırırım. Önce boş ya da en basit durumla başlarım, sonra kuralları tek tek eklerim.","senior":"Önce soruları netleştirip bir test listesi çıkarırım; listede implementasyon değil davranışlar olur. Sonra en basit maddeyle başlarım ve ritmi sesli anlatırım: \"Bu test doğru sebepten kırmızı\", \"Şimdilik sabit dönüyorum, bir sonraki test bunu zorlayacak\", \"Yeşil, şimdi refactor\". Listeyi gereksinimdeki riskli ifadelere göre sıralarım; k4'te \"sırayla uygulanır\" ifadesi için ayrı bir test yazarım, çünkü yanlış bir implementasyonu tam olarak o yakalar.\n\nZaman kısıtlıysa adım büyüklüğünü ayarlarım: açık olan kısımlarda obvious implementation, belirsiz kısımlarda küçük adımlar. Refactor'ı sadece yeşilken yaparım ve testleri public davranış üzerinden yazdığım için refactor'da testlere dokunmam gerekmez. TDD'yi dogma olarak da görmem: keşif aşamasındaki bir prototipte ya da sadece framework konfigürasyonundan oluşan kodda test-sonra yazarım. Ama iş kuralı yoğun bir modülde TDD'nin bana en büyük katkısı tasarım oluyor: test yazmak zorlaşınca bağımlılığı fark ediyorum.","interviewer":"Junior cevap TDD'yi \"önce bütün testler\" diye tarif ediyor; bu döngü değil, test-first bir şelale. Mid cevap döngüyü doğru biliyor. Senior cevap döngünün önüne test listesini koyuyor, mülakatta ritmi görünür kılıyor, testlerin seçimini riskle ilişkilendiriyor (kural sırası testi), adım büyüklüğünü bilinçli ayarlıyor ve TDD'nin uygun olmadığı durumları söylüyor.\n\n**Takip sorusu:** Refactor adımında bir test kırıldı. Bu neyi gösterir ve ne yaparsın?"},"href":"/kitap/16-test-stratejisi-ve-tdd/"},{"kind":"open","id":"kitap/16-test-stratejisi-ve-tdd#4","category":"Zanaat","label":"Test stratejisi, Mockito, Testcontainers ve TDD","level":"Orta","short":"$undefined","questionMd":"CI'da testlerimiz ara sıra fail ediyor, tekrar çalıştırınca geçiyor. Ne yaparsın?","answers":{"junior":"Testi birkaç kez tekrar çalıştırırım, geçerse devam ederim. Sürekli sorun çıkaran testi `@Disabled` yaparım.","mid":"Bu flaky test. Sık nedenleri zaman, test sırası, paylaşılan durum ve asenkron beklemeler. `Thread.sleep` gördüğüm yerde Awaitility kullanırım, `LocalDateTime.now()` yerine `Clock` enjekte ederim, testlerin kendi verisini kurup temizlediğinden emin olurum.","senior":"Önce görünür kılarım: CI'da her test sonucunu kaydedip hangi testlerin kod değişmeden hem geçip hem kaldığını listelerim. Sonra flaky testleri sahibi ve süresi belli bir karantinaya alırım; ana build'i bloklamaz ama kaybolmaz da. `@Disabled` testi unutur, retry ise gerçek bir race condition'ı da gizler.\n\nTeşhiste deseni ararım: belli saatlerde mi (zaman, saat dilimi), sadece paralel çalışmada mı (paylaşılan DB satırı, static durum), tek başına geçip pakette mi kalıyor (sıra ve context cache), yavaş runner'larda mı (sabit bekleme). Testi döngüde yüz kez çalıştırmak ya da sırayı rastgeleleştirmek çoğu zaman yeniden üretir. Bazen flaky test production'daki gerçek bir eşzamanlılık hatasını gösterir; o yüzden \"test sorunu\" diye kapatmadan önce kodda yarış olup olmadığına bakarım. Kalıcı çözüm olarak `Clock`, Awaitility, benzersiz test verisi ve `Locale.ROOT` gibi alışkanlıkları ekip standardı yaparım.","interviewer":"Junior cevap semptomu bastırıyor; flaky testler birikir ve ekip kırmızı build'e güvenmeyi bırakır. Mid cevap nedenleri ve teknik çareleri biliyor. Senior cevap önce ölçüp görünür kılıyor, karantina ile retry/disable farkını gerekçelendiriyor, sistematik bir teşhis yolu izliyor ve en önemlisi flaky testin production'daki gerçek bir yarışın belirtisi olabileceğini hatırlatıyor.\n\n**Takip sorusu:** Sadece CI'da, paralel test çalıştırmada kalan bir repository testi var. İlk neye bakarsın?"},"href":"/kitap/16-test-stratejisi-ve-tdd/"},{"kind":"open","id":"kitap/17-solid-design-patterns-ve-refactoring#1","category":"Zanaat","label":"SOLID, design pattern'ler ve refactoring","level":"Başlangıç","short":"$undefined","questionMd":"SOLID'i anlatır mısın? Projende en çok hangisinin ihlal edildiğini gördün?","answers":{"junior":"S tek sorumluluk, O açık/kapalı, L Liskov, I interface ayrımı, D bağımlılıkların tersine çevrilmesi. Spring'de dependency injection kullandığımız için D'yi zaten uyguluyoruz. En çok SRP ihlal ediliyor, çünkü servisler çok uzun oluyor.","mid":"SRP bir sınıfın değişmek için tek nedeni olması; OCP yeni davranışı mevcut kodu değiştirmeden eklemek, genelde Strategy ile; LSP alt tipin üst tipin sözleşmesini bozmaması; ISP istemcinin kullanmadığı metotlara bağımlı olmaması; DIP üst katmanın soyutlamaya bağımlı olması. En çok OCP ihlali görüyorum: tip bazlı switch'ler, her yeni ödeme tipinde bir case daha. Bunu Strategy ve Spring'in List enjeksiyonuyla çözüyorum.","senior":"Hepsinin ortak amacı değişimin maliyetini düşürmek; bu yüzden her birini \"hangi değişimi kolaylaştırır\" diye düşünürüm. SRP'de \"neden\" insanlar: fiyat kuralını pazarlama, fatura formatını finans değiştiriyorsa ikisi aynı sınıfta olmamalı. DI ile DIP'i ayırırım: Spring somut `IyzicoClient`'ı da enjekte eder, bu DIP değildir; DIP, domain'in port'u tanımlayıp altyapının onu uygulamasıdır.\n\nEn pahalı ihlal olarak LSP ve ISP'nin birlikte göründüğü durumu gördüm: her sağlayıcının uygulamak zorunda olduğu şişman bir ödeme arayüzü ve desteklenmeyen metotlarda `UnsupportedOperationException`. Çağıran kod \"bu sağlayıcı taksit destekliyor mu\" diye `instanceof` yapmaya başlamıştı; yeni sağlayıcı her eklendiğinde bu kontrollerin bir yerde eksik kalması production hatası üretiyordu. Rol arayüzlerine böldük ve desteklenen yetenekleri tip sistemine taşıdık. Ama ilkeleri körü körüne de uygulamam: tek implementasyonu olan, değişim ekseni kanıtlanmamış bir yer için interface eklemem; yanlış soyutlama tekrardan pahalıdır.","interviewer":"Junior cevap kısaltmaları açıyor ama yaygın bir yanılgıyı (DI = DIP) taşıyor ve \"servisler uzun\" gibi boyuta dayalı, mekanizmasız bir gözlem yapıyor. Mid cevap tanımları doğru veriyor ve somut bir ihlal ile çözümünü biliyor. Senior cevap ilkeleri ortak bir amaca bağlıyor, SRP'nin gerçek anlamını (değişim nedeni = aktör) ve DI/DIP farkını netleştiriyor, deneyimden gelen ve maliyeti anlatılan bir örnek veriyor ve ilkelerin ne zaman uygulanmayacağını söylüyor.\n\n**Takip sorusu:** Liskov ihlalini derleyici yakalamaz. Production'a çıkmadan nasıl yakalarsın?"},"href":"/kitap/17-solid-design-patterns-ve-refactoring/"},{"kind":"open","id":"kitap/17-solid-design-patterns-ve-refactoring#2","category":"Zanaat","label":"SOLID, design pattern'ler ve refactoring","level":"Orta","short":"$undefined","questionMd":"Strategy ile Factory farkı nedir? Spring'de Strategy'yi nasıl kurarsın?","answers":{"junior":"Strategy farklı algoritmaları seçmek için, Factory nesne oluşturmak için. Spring'de bir factory sınıfı yazıp içinde switch ile doğru servisi döndürürüm.","mid":"Strategy davranış sağlar, Factory nesne üretir. Spring'de tüm strategy implementasyonlarını `List` olarak enjekte edip constructor'da `Map`'e çeviririm; her implementasyon hangi tipi desteklediğini bir metotla söyler. Böylece yeni implementasyon eklemek için factory'ye dokunmam gerekmez. Bilinmeyen tip için exception fırlatırım.","senior":"Strategy \"nasıl yapılacağı\"nı değiştirilebilir kılar; Factory \"neyin oluşturulacağı\"na karar verir. Spring'de strategy'ler zaten bean olduğu için çoğu zaman oluşturma yok, seçim var; o seçici bileşene registry demeyi tercih ederim. İçinde switch olan bir factory OCP sorununu sadece başka bir sınıfa taşır.\n\nKurulum: interface'e `carrier()` gibi bir anahtar metodu, `List` enjeksiyonu, açılışta `EnumMap`'e çevirip duplicate'te fail-fast, isteğe bağlı olarak enum'un tamamının kapsandığını açılışta doğrulamak. `Map` enjeksiyonu da var ama seçimi bean adına bağladığı için kırılgan buluyorum. Sıra önemliyse (k4'teki indirim kuralları) `@Order` ya da açık bir liste kullanırım, çünkü `List` enjeksiyonunun sırası aksi halde garanti değildir. Test tarafında her strategy saf unit test, registry için duplicate ve bilinmeyen anahtar testi yazarım. Strategy'yi ne zaman kullanmam: iki dal varsa ve yenisi beklenmiyorsa; o zaman bir if ya da davranışı enum sabitine gömmek daha okunur.","interviewer":"Junior cevap tanımı biliyor ama önerdiği çözüm (switch'li factory) sorunu taşıyor, çözmüyor. Mid cevap Spring'deki idiomatik kurulumu ve OCP faydasını biliyor. Senior cevap kavramsal farkı Spring bağlamında netleştiriyor (seçim ve oluşturma), kurulumu fail-fast ve kapsam kontrolüyle sağlamlaştırıyor, `Map` ve sıralama gibi inceliklere değiniyor ve pattern'i ne zaman kullanmayacağını söylüyor.\n\n**Takip sorusu:** Strategy'lerden birinin başka bir strategy'yi kullanması gerekiyor (kampanya ücreti, temel ücrete bağlı). Bunu nasıl modellersin?"},"href":"/kitap/17-solid-design-patterns-ve-refactoring/"},{"kind":"open","id":"kitap/17-solid-design-patterns-ve-refactoring#3","category":"Zanaat","label":"SOLID, design pattern'ler ve refactoring","level":"İleri","short":"$undefined","questionMd":"Ne zaman design pattern kullanmazsın? Over-engineering'e bir örnek verir misin?","answers":{"junior":"Pattern'ler kodu daha temiz ve genişletilebilir yaptığı için mümkün olduğunca kullanmaya çalışırım. Over-engineering çok fazla sınıf yazmaktır.","mid":"Basit bir problem için pattern kullanmam. Örneğin tek bir implementasyonu olan servis için interface yazmam; ikinci implementasyon gelince çıkarırım. YAGNI'ye uyarım. Ayrıca kodu okuyan kişinin pattern'i bilmesi gerekir, gereksiz soyutlama okumayı zorlaştırır.","senior":"Pattern'i değişim ekseni kanıtlandığında kullanırım; kanıt genelde ikinci ya da üçüncü tekrardır. Kanıtsız soyutlama yanlış ekseni seçer ve yanlış soyutlama tekrar etmekten pahalıdır: her yeni ihtiyaçta ortak sınıfa bir boolean parametre ve bir if eklenir, sonunda kimse ona dokunamaz.\n\nGördüğüm bir örnek: iki rapor tipi için \"konfigüre edilebilir rapor motoru\" yazılmıştı; abstract üst sınıf, factory, builder ve YAML'dan okunan adım tanımları. Üçüncü rapor bambaşka bir veri kaynağı gerektirdiğinde motorun her katmanına istisna eklendi. Motoru inline edip üç düz sınıfa döndük; kod kısaldı ve her rapor bağımsız değişmeye başladı. Bu yüzden soyutlamayı geri açmayı da meşru bir refactoring sayarım. Live coding'de de aynı ilke: 35 dakikada sadece görevin istediği ekseni soyutlarım (k1'de firma), geri kalanını \"ihtiyaç olursa şöyle genişletirim\" diye sözlü anlatırım.","interviewer":"Junior cevap pattern'i amaç sanıyor; tam olarak over-engineering'e götüren tutum. Mid cevap doğru sezgiye ve basit bir kurala sahip. Senior cevap kararı bir kanıt eşiğine bağlıyor (değişim ekseni), yanlış soyutlamanın maliyetini mekanizmasıyla anlatıyor, somut bir deneyim ve geri dönüş hikâyesi veriyor ve ilkeyi live coding'in zaman kısıtına uyguluyor.\n\n**Takip sorusu:** Bir interface'in tek implementasyonu var ama ekip \"test için mock'lamak lazım\" diyor. Bu geçerli bir gerekçe mi?"},"href":"/kitap/17-solid-design-patterns-ve-refactoring/"},{"kind":"open","id":"kitap/17-solid-design-patterns-ve-refactoring#4","category":"Zanaat","label":"SOLID, design pattern'ler ve refactoring","level":"İleri","short":"$undefined","questionMd":"Testi olmayan legacy bir sınıfı nasıl güvenle refactor edersin?","answers":{"junior":"Önce kodu okuyup anlarım, sonra daha temiz bir versiyonunu yazarım ve eskisini silerim. Sonra test yazarım.","mid":"Önce mevcut davranışı sabitleyen testler yazarım, sonra küçük adımlarla refactor ederim: Extract Method, Rename, Strategy'ye geçiş. Her adımdan sonra testleri çalıştırırım. Davranış değişikliği gerekiyorsa refactor'dan ayrı yaparım.","senior":"Önce characterization testleri: doğru davranışı değil, mevcut davranışı sabitlerim; bug gibi görünen şeyleri de belgeler ve iş tarafına sorarım. Test yazılamayacak kadar bağımlıysa (static çağrılar, `new` ile oluşturulan client'lar, `now()`), önce küçük ve güvenli dikiş noktaları (seam) açarım: bağımlılığı constructor parametresine çıkarmak, `Clock` enjekte etmek. Bunlar IDE'nin otomatik refactoring'leriyle yapılır, risk düşüktür.\n\nSonra küçük, her biri derlenen ve testten geçen adımlar; refactor commit'leri ile davranış değişikliği commit'leri ayrı. Production'a büyük patlama ile değil, parallel change ile çıkarırım: yeni yol eskisinin yanında kurulur, kritik akışlarda bir süre ikisi birlikte çalışıp sonuçları karşılaştırılır, metriklerle doğrulanır, sonra eski yol silinir. Kapsamı da ölçerim: refactor'u değişmesi gereken yerle sınırlarım; dokunmayacağım legacy kodu \"temizlemek\" için risk almam.","interviewer":"Junior cevap güvenlik ağı olmadan yeniden yazmayı öneriyor; davranış farklarını fark etmenin yolu kalmıyor. Mid cevap doğru sırayı (önce test, küçük adımlar, refactor ile davranış değişikliğini ayırmak) biliyor. Senior cevap test yazılamayan kod için dikiş noktalarını, production'a çıkışta parallel change ve karşılaştırmalı doğrulamayı ve refactor'ın kapsamını sınırlamayı ekliyor; risk yönetimini teknik adımların önüne koyuyor.\n\n**Takip sorusu:** Characterization testi yazarken mevcut davranışın bir bug olduğunu fark ettin. Testte neyi beklersin ve ne zaman düzeltirsin?"},"href":"/kitap/17-solid-design-patterns-ve-refactoring/"},{"kind":"open","id":"kitap/18-rest-api-tasarimi-ve-hata-yonetimi#1","category":"Zanaat","label":"REST API tasarımı, validasyon ve hata yönetimi","level":"Orta","short":"$undefined","questionMd":"Mobil uygulama sipariş isteğini ağ hatasında tekrar gönderiyor. Çift sipariş oluşmasını nasıl engellersin?","answers":{"junior":"POST yerine PUT kullanırım, PUT idempotent olduğu için tekrar gelse de sorun olmaz. Ya da kaydetmeden önce aynı müşterinin son bir dakikada aynı ürünlerle siparişi var mı diye bakarım.","mid":"İstemci her sipariş denemesi için bir UUID üretip `Idempotency-Key` header'ında gönderir, retry'larda aynı anahtarı kullanır. Sunucuda anahtarı siparişle birlikte saklarım ve unique constraint koyarım. Aynı anahtar gelirse yeni sipariş oluşturmadan ilk siparişi dönerim. Unique constraint önemli, çünkü \"önce bak sonra ekle\" kontrolü eşzamanlı iki istekte ikisine de izin verir.","senior":"$4d","interviewer":"Junior'ın cevabı iki yaygın yanlış inanç içeriyor: metodu PUT yapmak, sunucu tarafındaki mantık değişmedikçe hiçbir şeyi idempotent yapmaz (idempotency metot adının değil, uygulamanın özelliğidir); \"son bir dakikada benzer sipariş\" sezgisi ise hem yarışa açık hem de meşru ikinci siparişi engeller. Mid doğru mekanizmayı ve unique constraint'in neden gerektiğini biliyor. Senior'ı ayıran şeyler: anahtarın kapsamı (güvenlik), farklı gövde durumu (422), eşzamanlı isteğin veritabanında nasıl davrandığı (bekleme ve 23505), transaction sınırının neden ayrılması gerektiği, dış çağrı içeren akışta durum makinesi, saklama süresi ve ölçüm.\n\n**Takip sorusu:** Sipariş oluşturuldu ama ödeme sağlayıcısının cevabı timeout'a düştü. Kullanıcı aynı anahtarla tekrar denediğinde ne olur, ödemenin gerçekten alınıp alınmadığını nasıl öğrenirsin?"},"href":"/kitap/18-rest-api-tasarimi-ve-hata-yonetimi/"},{"kind":"open","id":"kitap/18-rest-api-tasarimi-ve-hata-yonetimi#2","category":"Zanaat","label":"REST API tasarımı, validasyon ve hata yönetimi","level":"Orta","short":"$undefined","questionMd":"Bir Spring Boot API'sinde hata yönetimini nasıl kurgularsın?","answers":{"junior":"Global bir exception handler yazarım, `@ControllerAdvice` ile. Exception gelince 500 ve mesajı dönerim, böylece her controller'da try-catch yazmam gerekmez.","mid":"`@RestControllerAdvice` içinde exception tiplerine göre handler'lar yazarım: `NotFoundException` 404, `MethodArgumentNotValidException` 400 ve alan bazlı hata listesi, `ConflictException` 409, geri kalan her şey 500. Gövde formatı olarak Spring 6'daki `ProblemDetail`'i kullanırım. 500'de exception mesajını istemciye dönmem, log'larım.","senior":"$4e","interviewer":"Junior merkezi handler fikrini biliyor ama her şeyi 500'e çevirmek asıl problemi (yanlış status) çözmüyor; mesajı dönmek de iç detay sızdırıyor. Mid doğru eşlemeyi ve ProblemDetail'i biliyor, sızıntıya dikkat ediyor. Senior bunu bir **sözleşme** olarak ele alıyor: stabil hata kodu, domain'in HTTP'den bağımsızlığı, Spring'in kendi exception'larının aynı formata girmesi, log seviyesi stratejisi, güvenlikle etkileşim (403'ün yutulması), test ve gözlemlenebilirlik.\n\n**Takip sorusu:** Mobil istemci hata mesajlarını kullanıcıya Türkçe ve İngilizce göstermek istiyor. Bunu sunucuda mı, istemcide mi çözersin; ProblemDetail'de nasıl taşırsın?"},"href":"/kitap/18-rest-api-tasarimi-ve-hata-yonetimi/"},{"kind":"open","id":"kitap/18-rest-api-tasarimi-ve-hata-yonetimi#3","category":"Zanaat","label":"REST API tasarımı, validasyon ve hata yönetimi","level":"Başlangıç","short":"$undefined","questionMd":"400, 401, 403, 404, 409 ve 422 arasındaki farkı anlatır mısın? Hangisini ne zaman seçersin?","answers":{"junior":"400 hatalı istek, 401 yetkisiz, 403 yasak, 404 bulunamadı, 409 çakışma, 422 işlenemeyen içerik. Kullanıcı login olmamışsa ya da yetkisi yoksa 401 dönerim.","mid":"400 isteğin kendisi bozuksa: JSON parse edilemiyor ya da validasyon geçmiyor. 401 kimlik doğrulanmamışsa, 403 kimlik belli ama yetki yoksa. 404 hedef kaynak yoksa. 409 mevcut durumla çakışma, örneğin unique e-posta ya da zaten kargoya verilmiş siparişi iptal etmek. 422 sözdizimi doğru ama iş kuralına aykırı içerik için; bazı ekipler bunu da 400 ile döner.","senior":"Ben bunu istemcinin bir sonraki adımı üzerinden seçiyorum. 401: tekrar kimlik doğrula, `WWW-Authenticate` ile döner; adı \"Unauthorized\" ama anlamı \"unauthenticated\". 403: kimlik doğru, tekrar denemek işe yaramaz. Kaynak başka kullanıcıya aitse 403 yerine 404 dönerim, çünkü 403 o id'de bir kaynak olduğunu söyler; bu IDOR taramalarına bilgi verir. 400 ile 422 ayrımında takımın standardına uyarım; standart yoksa şema hatası 400, iş kuralı 422 öneririm ve asıl ayrımı gövdedeki stabil `code` alanıyla yaparım, çünkü istemci kodu status'tan çok code'a bakar. 404 hedef URI içindir: gövdedeki `productId` yoksa 404 değil 422/400'dür. 409'u durum çakışması için kullanırım; eşzamanlı güncellemede ETag/If-Match kullanıyorsam ön koşul hatası 412'dir, `If-Match` zorunlu ama gelmemişse 428. Retry edilebilir kodlarda da ayrım önemli: 503 ve 429'a `Retry-After` eklerim, çünkü istemcinin retry davranışını bu header yönlendirir.","interviewer":"Junior'ın cevabı ezber ve 401/403'ü karıştırıyor; bu yaygın yanlış inanç, istemcinin yetkisiz kullanıcıyı sonsuz login döngüsüne sokmasına yol açar. Mid doğru tanımları biliyor. Senior kodları istemci davranışıyla ilişkilendiriyor, 404'ü güvenlik aracı olarak kullanıyor, 404'ün hedef URI'yle ilgili olduğunu biliyor, 412/428/Retry-After gibi daha ince araçları doğru yere koyuyor ve 400/422 tartışmasında dogmatik değil.\n\n**Takip sorusu:** Toplu bir işlemde (100 ürünün fiyatını güncelle) 97'si başarılı, 3'ü hatalı. Hangi status kodunu dönersin, gövdeyi nasıl tasarlarsın?"},"href":"/kitap/18-rest-api-tasarimi-ve-hata-yonetimi/"},{"kind":"open","id":"kitap/18-rest-api-tasarimi-ve-hata-yonetimi#4","category":"Zanaat","label":"REST API tasarımı, validasyon ve hata yönetimi","level":"İleri","short":"$undefined","questionMd":"Ödeme sağlayıcısını çağıran bir servis yazıyorsun. HTTP client tarafında nelere dikkat edersin?","answers":{"junior":"RestTemplate ya da Feign kullanırım. Hata gelirse exception fırlatırım, bir de birkaç kez retry eklerim ki geçici hatalarda işlem başarısız olmasın.","mid":"Yeni kodda RestClient kullanırım, tek bir bean olarak ve connect/read timeout ayarlı. 4xx ve 5xx'i ayrı ele alırım: 4xx'te retry yapmam, 5xx ve timeout'ta exponential backoff ile sınırlı retry yaparım. Resilience4j ile circuit breaker eklerim ki sağlayıcı çökünce thread'lerim tükenmesin. Çağrıyı `@Transactional` metodun içinde yapmam.","senior":"$4f","interviewer":"Junior'ın retry önerisi tehlikeli: idempotency olmadan ödeme çağrısını tekrarlamak çift tahsilat demektir; timeout'tan hiç bahsetmemesi de en büyük eksik. Mid teknik olarak doğru araçları sayıyor. Senior'ı ayıran şey **belirsiz sonuç** kavramı (timeout = bilinmiyor), idempotency key'in dış sisteme taşınması, uzlaştırma, transaction sınırı, bulkhead ile izolasyon, PCI farkındalığı ve client seçiminin güncel durumunu bilmesi.\n\n**Takip sorusu:** Sağlayıcı idempotency key desteklemiyor. Çift tahsilat riskini nasıl yönetirsin?"},"href":"/kitap/18-rest-api-tasarimi-ve-hata-yonetimi/"},{"kind":"open","id":"kitap/19-live-coding-algoritmalari#1","category":"Live Coding","label":"Live coding algoritmaları","level":"İleri","short":"$undefined","questionMd":"Dağıtık bir rate limiter nasıl tasarlarsın?","answers":{"junior":"Her kullanıcı için bir sayaç tutarım, dakikada 5'i geçerse reddederim. Birden fazla sunucu varsa sayaçları Redis'e koyarım, `INCR` ile artırırım.","mid":"Token bucket kullanırım, kısa patlamalara izin verip ortalama hızı koruyor. Tek instance'ta `ConcurrentHashMap` ve kullanıcı başına kilit, zaman enjekte edilir ki test edilebilsin. Çok pod'da state Redis'te; okuma-hesaplama-yazma atomik olsun diye Lua script yazarım. Anahtara TTL koyarım ki boşta kalan kullanıcılar bellekte kalmasın. Reddedilen isteğe 429 ve `Retry-After` dönerim.","senior":"$50","interviewer":"Junior'ın `INCR`'ı fixed window'dur ve iki hata taşır: pencere sınırında 2× patlama, ve `INCR` ile `EXPIRE` ayrı komutlarsa TTL'siz kalıcı sayaç riski. Mid doğru algoritmayı, atomikliği ve TTL'yi biliyor. Senior amaçla başlıyor (amaç algoritmayı belirler), uygulama katmanını seçiyor, saat farkı, fail-open/closed, hot key, latency bütçesi ve gözlemlenebilirliği tartışıyor, testi eşzamanlılığa kadar götürüyor.\n\n**Takip sorusu:** Limit kullanıcı başına değil, tüm sistem için saniyede 10.000 istek olsaydı ve tek bir Redis anahtarı darboğaz olsaydı ne yapardın?"},"href":"/kitap/19-live-coding-algoritmalari/"},{"kind":"open","id":"kitap/19-live-coding-algoritmalari#2","category":"Live Coding","label":"Live coding algoritmaları","level":"Orta","short":"$undefined","questionMd":"Thread-safe bir LRU cache yazar mısın? Production'da da bunu mu kullanırsın?","answers":{"junior":"`LinkedHashMap` kullanırım, `removeEldestEntry`'yi override ederim. Thread-safe olması için `ConcurrentHashMap` kullanırım.","mid":"`LinkedHashMap`'i `accessOrder = true` ile kurarım, `removeEldestEntry`'de `size() > capacity` dönerim. `ConcurrentHashMap`'in erişim sırası yok, o yüzden metotları `synchronized` yaparım; `get` de sırayı değiştirdiği için okumayı da senkronize etmek gerekiyor. Mülakatçı isterse `HashMap` ve çift yönlü listeyle de yazarım. Production'da Caffeine kullanırım.","senior":"$51","interviewer":"Junior iki yaygın hata yapıyor: `accessOrder`'ı unutuyor (sonuç FIFO olur) ve `ConcurrentHashMap`'in LRU sırası tutmadığını bilmiyor. Mid doğru ve dikkatli; `get`'in yazma olduğunu biliyor. Senior veri yapısının neden böyle olduğunu mekanizmayla anlatıyor, LRU'nun zayıflığını ve Caffeine'in bunu nasıl çözdüğünü biliyor, konuyu cache tasarımının gerçek problemlerine (isabet oranı, invalidation, mutable nesne, stampede) taşıyor.\n\n**Takip sorusu:** Bu cache ürün detayını tutuyor ve fiyat değiştiğinde 20 pod'daki kopyaların en geç 5 saniye içinde güncellenmesi gerekiyor. Nasıl yaparsın?"},"href":"/kitap/19-live-coding-algoritmalari/"},{"kind":"open","id":"kitap/19-live-coding-algoritmalari#3","category":"Live Coding","label":"Live coding algoritmaları","level":"Başlangıç","short":"$undefined","questionMd":"HashMap'in get ve put'u neden O(1)? Her zaman O(1) mi?","answers":{"junior":"HashMap hash kullandığı için direkt erişir, bu yüzden her zaman O(1)'dir.","mid":"Anahtarın `hashCode`'u ile bucket bulunur, bucket içinde `equals` ile anahtar aranır. Çakışma azsa ortalama O(1). Çok çakışma olursa bucket'taki liste uzar; Java 8'den beri liste belli bir uzunluğu geçince ağaca dönüşüyor ve en kötü durum O(log n) oluyor. Doluluk load factor'ı geçince tablo büyüyor ve rehash yapılıyor.","senior":"$52","interviewer":"Junior'ın \"her zaman O(1)\" cümlesi yaygın bir yanlış inanç: çakışma ve rehash'i yok sayıyor. Mid mekanizmayı ve treeify'ı biliyor. Senior sayılarla konuşuyor (0,75, 8, 64), hash karıştırmanın nedenini biliyor, amortize maliyeti ve gecikme sıçramasını ayırıyor, güvenlik boyutunu (hash flooding) ve gerçek hayattaki hata kaynağını (equals/hashCode sözleşmesi) ekliyor.\n\n**Takip sorusu:** `ConcurrentHashMap` aynı problemi eşzamanlı ortamda nasıl çözüyor; `size()` neden tam bir an görüntüsü vermeyebilir?"},"href":"/kitap/19-live-coding-algoritmalari/"},{"kind":"open","id":"kitap/19-live-coding-algoritmalari#4","category":"Live Coding","label":"Live coding algoritmaları","level":"İleri","short":"$undefined","questionMd":"Günün en çok satan 10 ürününü bul. Veri milyonlarca satırsa ne değişir?","answers":{"junior":"Ürün başına toplamları bir map'te toplarım, sonra değere göre sıralayıp ilk 10'u alırım.","mid":"Toplamları `HashMap.merge` ile O(n)'de çıkarırım. Sonra tamamını sıralamak O(m log m); bunun yerine boyutu 10 olan bir min-heap tutarım, tepede en kötü aday durur, daha iyisi gelince tepeyi atarım: O(m log k). Eşitlikte küçük id önce geleceği için heap comparator'ında id'yi ters sıralarım ve sonunda listeyi ters çeviririm.","senior":"Tek makinede ve bellek yetiyorsa map + boyutu k heap; m küçükse okunabilirlik için stream ile sıralama da kabul. Quickselect ortalama O(m) ama en kötü O(m²) ve girdiyi değiştiriyor, burada heap'i tercih ederim. Veri \"milyonlarca satır\" ve gün boyu akıyorsa bu artık batch değil stream problemi: siparişleri Kafka'dan productId ile partition'layıp her partition'da tam sayım, sonra partition başına top-10'ları birleştiririm; partition'lama şart, çünkü her pod'un kendi top-10'u global top-10'u vermez. Daha basit bir yol Redis Sorted Set: sipariş event'inde `ZINCRBY`, panoda `ZREVRANGE 0 9`; idempotent olmayan `ZINCRBY` yüzünden tekrar gelen event çift sayılır, bu yüzden event id ile tekilleştirme gerekir. Kardinalite çok yüksek ve yaklaşık sonuç kabulse Count-Min Sketch + heap. Panonun ne kadar taze olması gerektiğini sorarım: 1 dakika gecikme kabulse dakikalık batch, saniyelik gerekiyorsa stream.","interviewer":"Junior çalışan ama ölçeği düşünmeyen bir çözüm veriyor. Mid algoritmik iyileştirmeyi ve comparator'ın inceliğini biliyor. Senior girdi büyüklüğüne ve tazelik gereksinimine göre çözümü değiştiriyor, dağıtık birleştirmenin tuzağını (lokal top-K yetmez) ve idempotency'yi görüyor, kesinlik/bellek takasını adlandırıyor.\n\n**Takip sorusu:** \"Son 1 saatin\" top-10'u istenseydi (kayan pencere), Redis'te nasıl modellerdin?"},"href":"/kitap/19-live-coding-algoritmalari/"},{"kind":"open","id":"kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi#1","category":"Live Coding","label":"Sistem tasarımı, code review ve mülakat davranışı","level":"Orta","short":"$undefined","questionMd":"Bir PR'ı nasıl review edersin? İyi bir commit'in kriterleri neler?","answers":{"junior":"Kodu satır satır okurum, isimlendirmeye ve formatlamaya bakarım, hata görürsem yorum yazarım. Testler geçiyorsa onaylarım. İyi commit açıklayıcı mesajı olan commit'tir.","mid":"Önce PR açıklamasını ve neyi çözdüğünü okurum, sonra güvenlik, doğruluk, performans ve okunabilirlik sırasıyla bakarım: SQL injection, null ve boş liste durumları, transaction, N+1. Yorumlarımda blocker olanlarla öneri olanları ayırırım. Stil konularını linter'a bırakırım. İyi commit atomiktir, testleri geçer, mesajı neden'i anlatır; Conventional Commits formatını kullanırım.","senior":"Önce bağlam: PR'ın amacı, ilgili ticket, ve PR'ın boyutu; birkaç yüz satırı aşıyorsa bölünmesini isterim çünkü büyük PR'da review kalitesi düşer. Sonra riske göre okurum: güvenlik (injection, yetki, log'a giden veri), veri bütünlüğü (transaction sınırı, eşzamanlılık, idempotency), sonra performans ve tasarım. Testlere koddan önce bakarım: testler davranışı anlatıyorsa kodu anlamak kolaylaşır, anlatmıyorsa bu başlı başına bir yorumdur. Her yorumu ciddiyetiyle etiketlerim (blocking, suggestion, nit), ne-neden-nasıl yazarım, mümkünse kod önerisiyle gelirim ve iyi olanı da söylerim. Ölçütüm mükemmellik değil: PR kod tabanını kesin olarak iyileştiriyorsa ve blocker yoksa onaylarım, nit'ler için merge'ü bekletmem. Tekrar eden yorumları sürece çeviririm: aynı şeyi üçüncü kez yazıyorsam o bir ArchUnit kuralı, linter ayarı ya da PR şablonu maddesidir. Commit'te atomiklik, her commit'in yeşil olması (bisect için), refactor ile davranış değişikliğinin ayrılması ve mesajda nedenin yazılması benim için kriter.","interviewer":"Junior stil odaklı ve \"testler geçiyorsa onayla\" diyor; testlerin neyi test ettiğini sorgulamıyor, güvenlikten hiç bahsetmiyor. Mid doğru öncelik sırasını ve ciddiyet ayrımını biliyor. Senior review'ı bir risk yönetimi ve ekip süreci olarak ele alıyor: PR boyutu, testleri önce okumak, onay ölçütü (mükemmeliyetçilik değil iyileştirme), tekrar eden yorumları otomasyona çevirmek ve iletişim tonu.\n\n**Takip sorusu:** PR'da üç blocker buldun ama yazar \"yarın release var, sonra düzeltiriz\" diyor. Ne yaparsın?"},"href":"/kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi/"},{"kind":"open","id":"kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi#2","category":"Live Coding","label":"Sistem tasarımı, code review ve mülakat davranışı","level":"Başlangıç","short":"$undefined","questionMd":"Kendinden bahseder misin?","answers":{"junior":"Beş yıldır Java ile backend geliştiriyorum. Spring Boot, Kafka, PostgreSQL, Docker kullandım. Bankacılık projelerinde çalıştım. Yeni teknolojiler öğrenmeyi seviyorum ve kendimi geliştirmek istiyorum.","mid":"Beş yıldır Java ve Spring Boot ile backend geliştiriyorum, son dönemde bir bankanın teknoloji merkezinde müşteri ve hesap verileriyle ilgili servisler üzerinde çalışıyorum. REST API'ler, Kafka ile event tabanlı entegrasyonlar ve PostgreSQL üzerinde performans iyileştirmeleri yaptım. Bir API'nin feature owner'ıydım; tasarımından production'a kadar sorumluydum. Şimdi daha yüksek trafikli, e-ticaret ölçeğinde problemlerle çalışmak istiyorum.","senior":"Beş yıldır backend geliştiriyorum, son yılım bir bankanın teknoloji merkezinde, müşteri ve hesap domain'inde geçti. Orada bir hesaplama API'sinin feature owner'ıydım: gereksinimleri iş birimiyle netleştirdim, API sözleşmesini tasarladım, birkaç tüketici ekiple entegrasyonu yönettim ve production'a çıktıktan sonra performansını izledim. Bankacılık bana iki şey öğretti: veri doğruluğunda ve denetlenebilirlikte taviz verilmiyor, yani idempotency, transaction sınırları ve uzlaştırma benim için refleks; ve değişiklik maliyeti yüksek olduğu için test ve gözlemlenebilirlik olmadan bir şeyi \"bitti\" saymıyorum. Bunun dışında yan projelerde uçtan uca ürün geliştiriyorum, mobil tarafı da dahil; bu bana ürün düşüncesi kazandırdı. Bu role başvurma nedenim ölçek: bankacılıktaki tutarlılık disiplinini, çok daha yüksek trafik ve daha hızlı teslimat döngüsüyle birleştirmek istiyorum. Bu pozisyonda özellikle sipariş ve ödeme gibi tutarlılığın kritik olduğu alanlarda katkı verebileceğimi düşünüyorum.","interviewer":"Junior teknoloji listesi sayıyor; liste özgeçmişte zaten var, mülakatçı yeni bir şey öğrenmiyor. \"Kendimi geliştirmek istiyorum\" her adayın cümlesi. Mid sorumluluk ve somut iş anlatıyor. Senior 90 saniyede bir **hikaye** kuruyor: sahiplik (feature owner, uçtan uca), deneyimden çıkan ilkeler (tutarlılık, test, gözlemlenebilirlik), neden bu şirket ve bu rol, ve kendi geçmişini hedef rolün ihtiyacına bağlıyor. Kalıp: şimdiki rol ve sahiplik → öğrendiğin ve taşıdığın ilkeler → neden burası.\n\n**Takip sorusu:** Feature owner olarak aldığın ve sonradan yanlış olduğunu düşündüğün bir teknik karar var mı?"},"href":"/kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi/"},{"kind":"open","id":"kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi#3","category":"Live Coding","label":"Sistem tasarımı, code review ve mülakat davranışı","level":"Orta","short":"$undefined","questionMd":"Karşılaştığın en zor teknik problemi anlatır mısın?","answers":{"junior":"Bir projede API çok yavaştı. Cache ekledik ve sorun çözüldü. Ekipçe çok uğraştık ama sonunda başardık.","mid":"Bir hesap listeleme API'sinin p99 latency'si yük altında 2 saniyeye çıkıyordu. Log'lara ve trace'lere baktım, her hesap için ilişkili tabloya ayrı sorgu atıldığını, yani N+1 olduğunu gördüm. Sorguyu tek bir join'li projection'a çevirdim ve eksik bir composite index ekledim. p99 200 milisaniyenin altına indi. Sonrasında benzer endpoint'lerde de aynı kalıbı aradık.","senior":"$53","interviewer":"Junior'ın hikayesinde \"ben\" yok, teşhis yok, sonuç ölçülmemiş; \"cache ekledik\" de çoğu zaman problemi gizler. Mid somut ve ölçülmüş bir hikaye anlatıyor. Senior STAR yapısını kullanıyor ve şunları ekliyor: problemin neden fark edilmediği (ortalama vs. p99), değerlendirilen ve gerekçeyle reddedilen alternatifler (domain bilgisine dayalı), production'a güvenli çıkış (`CONCURRENTLY`, feature flag, kademeli açma) ve tekrarı önleyen kalıcı değişiklikler. Bu hikaye mülakatçıya beş farklı takip sorusu kapısı açar ve aday hepsine hazırdır.\n\n**Takip sorusu:** `CREATE INDEX CONCURRENTLY` yarıda kalırsa ne olur, nasıl tespit edip düzeltirsin?"},"href":"/kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi/"},{"kind":"open","id":"kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi#4","category":"Live Coding","label":"Sistem tasarımı, code review ve mülakat davranışı","level":"İleri","short":"$undefined","questionMd":"Yaşadığın bir production incident'ını anlatır mısın?","answers":{"junior":"Bir gün production'da servis çöktü. Hemen restart attık ve düzeldi. Sonra log'lara baktık ama sebebini tam bulamadık.","mid":"Bir deploy sonrası bir consumer'ın sürekli aynı mesajda hata alıp partition'ı tıkadığını fark ettik, consumer lag artıyordu. Önce deploy'u geri aldık, lag eridi. Sonra sebebin yeni eklenen bir alanın eski formatlı mesajlarda null gelmesi olduğunu bulduk. Null kontrolünü ekledik, hatalı mesajlar için dead letter topic tanımladık ve tekrar deploy ettik.","senior":"$54","interviewer":"Junior'ın hikayesi \"restart attık, sebebini bulamadık\"; bu bir incident değil, yarım kalmış bir incident ve en zayıf sinyaldir. Mid etkiyi durdurmayı ve kök nedeni bulmayı anlatıyor. Senior incident yönetiminin tam döngüsünü gösteriyor: tespit (alarm), önce etkiyi azaltma (rollback, iletişim), sonra kök neden, birden fazla katkıda bulunan faktörü ayırma (şema + retry politikası), kalıcı süreç iyileştirmeleri ve blameless kültür. Ayrıca teknik derinlik (poison pill, DLT, şema uyumluluğu) hikayenin içinde doğal olarak geçiyor.\n\n**Takip sorusu:** Rollback mümkün olmasaydı, örneğin şema değişikliği veritabanına da yansımış olsaydı, ne yapardın?"},"href":"/kitap/20-sistem-tasarimi-code-review-ve-mulakat-davranisi/"},{"kind":"open","id":"kitap/21-gercek-mulakatta-sorulanlar#1","category":"Gerçek Mülakattan","label":"Gerçek mülakatta sorulanlar","level":"Başlangıç","short":"$undefined","questionMd":"Dead letter queue nedir?","answers":{"junior":"İşlenemeyen mesajların gittiği kuyruktur. Bir mesaj hata verirse DLQ'ya atarız, sonra bakarız. Kafka'da da DLQ vardır, otomatik olarak hatalı mesajları oraya gönderir.","mid":"İşlenemeyen mesajları ana akıştan ayırıp saklamak için kullanılan kuyruk ya da topic. Consumer bir mesajı birkaç kez backoff ile dener, olmazsa DLQ'ya gönderir ve sonraki mesaja geçer; böylece bir poison message tüm partition'ı tıkamaz ve mesaj da kaybolmaz. Spring Kafka'da `DefaultErrorHandler` ile `DeadLetterPublishingRecoverer` kullanırım; deserialization hataları için `ErrorHandlingDeserializer` eklerim, bunlar retry edilmeden DLT'ye gider. RabbitMQ'da kuyruğa dead letter exchange tanımlanır, reject edilen mesaj oraya gider.","senior":"$55","interviewer":"Junior tanımı biliyor ama Kafka'nın \"otomatik DLQ'su\" olduğunu sanıyor; bu yaygın bir yanlış inanç: klasik consumer group'larda DLQ'yu uygulama veya framework yazar. \"Sonra bakarız\" da sahipsiz bir DLQ'nun habercisi. Mid doğru araçları ve poison message problemini biliyor, Spring Kafka kurulumunu yapabilir. Senior hataları sınıflandırıyor, \"downstream çökmüşse DLQ değil pause\" diyerek back-pressure düşünüyor, broker'lar arası farkları ve tehlikeli varsayılanları (delivery-limit, at-most-once dead lettering) biliyor, DLQ'nun operasyonel hayatını (alarm, sahip, replay, idempotency, sıra) anlatıyor ve deneyimden bir örnek veriyor.\n\n**Takip sorusu:** DLQ'da 20.000 mesaj birikmiş ve hepsi aynı deploy'dan sonra düşmüş. Adım adım ne yaparsın?"},"href":"/kitap/21-gercek-mulakatta-sorulanlar/"},{"kind":"open","id":"kitap/21-gercek-mulakatta-sorulanlar#2","category":"Gerçek Mülakattan","label":"Gerçek mülakatta sorulanlar","level":"İleri","short":"$undefined","questionMd":"DLQ'daki mesajları ne yaparsın?","answers":{"junior":"Logları inceleyip hatayı buluruz, düzelttikten sonra mesajları tekrar ana kuyruğa göndeririz.","mid":"Önce DLQ'ya neden düştüklerine bakarım; DLT header'larında exception sınıfı ve mesajı var. Hatayı düzeltip deploy ettikten sonra DLQ'yu okuyup mesajları ana topic'e geri yazan bir araçla replay ederim. Bozuk ve düzeltilemeyecek mesajları atarım. Replay sırasında consumer'ın idempotent olmasına dikkat ederim ki aynı mesaj iki kez işlenmesin.","senior":"$56","interviewer":"Junior'ın cevabı doğru yönde ama süreç yok: sınıflandırma, karar, güvenli replay ve idempotency eksik. Mid replay aracını ve idempotency'yi biliyor, bu iyi bir çıta. Senior önce DLQ'nun büyümesini durduruyor, mesajları gruplayıp farklı kararlar veriyor, replay'i hız sınırı ve sayaçla güvenli hale getiriyor, sıra ve versiyon problemini görüyor ve süreci alarm ile retention açısından iyileştiriyor.\n\n**Takip sorusu:** Kafka'da DLT'den okumak mesajı silmiyor. Replay aracını iki kez çalıştırırsan ne olur, bunu nasıl önlersin?"},"href":"/kitap/21-gercek-mulakatta-sorulanlar/"},{"kind":"open","id":"kitap/21-gercek-mulakatta-sorulanlar#3","category":"Gerçek Mülakattan","label":"Gerçek mülakatta sorulanlar","level":"Orta","short":"$undefined","questionMd":"Bir mesajı retry mı edersin, DLQ'ya mı atarsın? Nasıl karar verirsin?","answers":{"junior":"Önce 3 kez retry ederim, yine olmazsa DLQ'ya atarım. Her hata için aynısını yaparım.","mid":"Hatanın türüne bakarım. Timeout, 503 gibi geçici hataları exponential backoff ile birkaç kez retry ederim; bozuk JSON, validation hatası gibi kalıcı hataları retry etmeden doğrudan DLQ'ya gönderirim, çünkü tekrar denemek sonucu değiştirmez. Spring Kafka'da bunu `addNotRetryableExceptions` ile yaparım. Retry süresinin `max.poll.interval.ms`'i aşmamasına dikkat ederim.","senior":"Karar sorusu şu: aynı mesajı biraz sonra tekrar denesem sonuç değişir mi? Değişmezse (parse, validation, iş kuralı) retry boşa kaynak harcar ve partition'ı bekletir; doğrudan DLQ ya da, iş kuralı ihlaliyse, bir \"rejected\" event'i. Değişirse retry; ama süresine göre şekli değişir.\n\nSaniyeler süren hatalarda (deadlock, optimistic lock, pod restart) kısa blocking retry. Dakikalar sürebilecek hatalarda, sıra önemli değilse non-blocking retry topic'leri; sıra önemliyse blocking retry ve gerekirse container pause. Saatler süren ya da tüm mesajları etkileyen hatalarda (downstream çökmüş) retry de DLQ de değil, circuit breaker ve tüketimi durdurma; aksi halde DLQ trafiğin tamamıyla dolar.\n\nSınıflandırmayı metrikle doğrularım: bir exception sürekli retry'ı tüketip DLQ'ya düşüyorsa yanlış sınıflandırılmıştır.","interviewer":"Junior tek bir kural uyguluyor; kalıcı hatayı da üç kez deneyip partition'ı bekletiyor. Mid geçici-kalıcı ayrımını ve Spring Kafka karşılığını biliyor. Senior kararı tek bir soruya indirgiyor, hatanın süresine göre farklı stratejiler (blocking, non-blocking, pause) seçiyor, sıra ve back-pressure'ı hesaba katıyor ve sınıflandırmanın doğru olup olmadığını metrikle ölçüyor.\n\n**Takip sorusu:** `@RetryableTopic` kullanan bir consumer'da aynı siparişin \"oluştu\" ve \"iptal\" event'leri ters sırada işlendi. Neden oldu, nasıl düzeltirsin?"},"href":"/kitap/21-gercek-mulakatta-sorulanlar/"},{"kind":"open","id":"kitap/21-gercek-mulakatta-sorulanlar#4","category":"Gerçek Mülakattan","label":"Gerçek mülakatta sorulanlar","level":"Orta","short":"$undefined","questionMd":"@SpringBootApplication nasıl çalışır?","answers":{"junior":"Spring Boot uygulamasını başlatan anotasyondur. Bunu main sınıfına koyunca her şey otomatik konfigüre olur ve uygulama çalışır.","mid":"Üç anotasyonun birleşimidir: `@SpringBootConfiguration`, `@EnableAutoConfiguration`, `@ComponentScan`. Component scan ana sınıfın paketinden başlar ve `@Component`'leri bulur. Auto-configuration classpath'e bakarak bean'ler oluşturur, mesela JDBC driver varsa `DataSource`. `@ConditionalOnMissingBean` sayesinde ben kendi bean'imi tanımlarsam Boot'unki oluşmaz.","senior":"Mid'in söylediklerine mekanizmayı eklerim: `@EnableAutoConfiguration`, `AutoConfigurationImportSelector`'ı import eder; bu bir `DeferredImportSelector`, yani kullanıcının configuration class'ları işlendikten sonra çalışır. Bu sıra sayesinde `@ConditionalOnMissingBean` \"kullanıcı zaten tanımladı mı\" sorusunu güvenilir şekilde cevaplar. Aday listesi Boot 3'ten beri `AutoConfiguration.imports` dosyalarından gelir (auto-configuration için `spring.factories` desteği 3.0'da kaldırıldı).\n\nPratikte bir bean beklenmedik şekilde yoksa ya da varsa `--debug` ile condition evaluation report'a bakarım. Ortak kütüphanemiz için auto-configuration yazarken her bean'i `@ConditionalOnMissingBean` ile korur, bir kapatma property'si koyarım.","interviewer":"Junior \"otomatik\" kelimesinde duruyor; mekanizma yok. Mid üç parçayı ve geri çekilme davranışını biliyor; çoğu mülakat için yeterli. Senior sıranın neden önemli olduğunu (`DeferredImportSelector`), sürüm farkını ve bu bilginin hata ayıklamada ve kütüphane yazarken nasıl kullanıldığını anlatıyor.\n\n**Takip sorusu:** Ana sınıfı `com.example.payment.api` paketine taşıdın, `com.example.payment.infra` paketindeki repository bean'i bulunamıyor. Neden ve iki çözüm yolu nedir?"},"href":"/kitap/21-gercek-mulakatta-sorulanlar/"},{"kind":"open","id":"kitap/22-case-hesap-servisi-deposit-withdraw-exchange#1","category":"Gerçek Mülakattan","label":"Case","level":"İleri","short":"$undefined","questionMd":"Deposit, withdraw ve exchange servisini baştan kur. Tek DB, günde 1 milyon istek.","answers":{"junior":"Controller, service, repository katmanlarını kurarım. `Account` entity'sinde bakiye tutarım; withdraw'da bakiyeyi okuyup yetiyorsa düşerim. Metotları `@Transactional` yaparım. Yük yüksek olduğu için Redis cache ve Kafka eklerim.","mid":"Önce kapsamı sorarım: para birimi başına hesap, overdraft, kurun kaynağı. 1M/gün ≈ 12 rps; tek PostgreSQL yeter. Tablolar: `accounts`, değişmez `ledger_entries`, idempotency key'li `transactions`. Withdraw koşullu `UPDATE ... WHERE balance >= :amount` ile; exchange'de kuru transaction dışında alırım ve iki hesabı id sırasıyla kilitlerim. Para `BigDecimal`. Kur client'ına timeout, retry ve circuit breaker koyarım.","senior":"Netleştirme sorularıyla başlar, varsayımları yazarım. Kapasite: ortalama ~12, tepe ~100-200 rps; ölçtüğüm tam withdraw transaction'ı 2 vCPU'da ~2.000 tps. Teşhisim: problem ölçek değil doğruluk. Modular monolith; account, ledger, exchange aynı transaction'ı paylaştığı için ayrı servis değil. Bakiye bir projeksiyon, doğruluk kaynağı append-only ledger; gece `balance = SUM(ledger)` mutabakatı. Withdraw tek koşullu UPDATE, her para endpoint'i `(customer_id, key)` unique idempotency ile. Exchange quote/execute: kur 30 sn kilitli, execute'ta dış çağrı yok, iki hesap id sırasıyla `FOR NO KEY UPDATE`. Sağlayıcı işlemi yürütüyorsa PENDING, idempotent dış çağrı, kurtarma worker'ı. Kanıtı Testcontainers'ta 100 thread'lik test. Kafka/Redis/sharding'i hangi metrikle ekleyeceğimi söylerim, şimdi eklemem.","interviewer":"Junior yükü abartıp gereksiz altyapı ekliyor, asıl riski (oku-kontrol-yaz yarışı) kodunda taşıyor. Mid doğru araçları seçiyor. Senior ölçerek teşhis koyuyor, modül sınırını transaction sınırına göre çiziyor, ledger ve mutabakatla doğruluğu sürekli kanıtlanabilir yapıyor ve neyi eklemediğini gerekçelendiriyor.\n\n**Takip sorusu:** Bakiye kolonu ile ledger toplamı gece mutabakatında 980 TL farklı çıktı. Nasıl araştırırsın?"},"href":"/kitap/22-case-hesap-servisi-deposit-withdraw-exchange/"},{"kind":"open","id":"kitap/22-case-hesap-servisi-deposit-withdraw-exchange#2","category":"Gerçek Mülakattan","label":"Case","level":"Orta","short":"$undefined","questionMd":"Race condition'ı nasıl engellersin?","answers":{"junior":"Withdraw metodunu `synchronized` yaparım, aynı anda tek thread bakiyeyi değiştirir.","mid":"`synchronized` çoklu pod'da çalışmaz. DB'de `UPDATE accounts SET balance = balance - :a WHERE id = :id AND balance >= :a` yaparım; etkilenen satır 0 ise yetersiz bakiye. Satır kilidi ve READ COMMITTED'daki yeniden değerlendirme iki çekimin aynı parayı harcamasını önler. Ayrıca `CHECK (balance >= 0)`.","senior":"Önce yarışları ayırırım: eşzamanlı farklı istekler (lost update), aynı isteğin tekrarı, çok hesaplı kilit sırası. Tek satır için koşullu UPDATE: retry yok, kilit milisaniyeler. Kural domain'de veya iki satırdaysa sıralı `FOR NO KEY UPDATE` (FK'li insert'lerin KEY SHARE kilidiyle çakışmasın diye); sırasız denediğimde 10 sn'de 30 deadlock, sıralı 0. Optimistic lock sıcak hesapta 100 denemenin 93'ünü düşürdü; SERIALIZABLE retry'la doğru ama 1.905 retry. Tekrar için idempotency key aynı transaction'da. `synchronized` hem çoklu pod hem \"kilit commit'ten önce bırakılır\" yüzünden yanlış. `CHECK` lost update'i yakalamaz: naive kod bakiyeyi negatife düşürmeden 980 TL kaybettirdi. `lock_timeout` ile beklemeyi sınırlarım.","interviewer":"Junior'ın cevabı tek pod'da bile yanlış. Mid doğru atomik UPDATE'i ve mekanizmasını biliyor. Senior yarış türlerini ayırıyor, her biri için aracı ölçümle seçiyor ve constraint'in neyi yakalamadığını biliyor.\n\n**Takip sorusu:** \"Günlük çekim limiti 10.000 TL\" kuralı eklendi. Koşullu UPDATE hâlâ yeter mi?"},"href":"/kitap/22-case-hesap-servisi-deposit-withdraw-exchange/"},{"kind":"open","id":"kitap/22-case-hesap-servisi-deposit-withdraw-exchange#3","category":"Gerçek Mülakattan","label":"Case","level":"İleri","short":"$undefined","questionMd":"3rd party kur servisi yavaşlar ya da timeout olursa?","answers":{"junior":"Try-catch ile yakalayıp hata dönerim, belki 3 kez tekrar denerim.","mid":"Connect/read timeout, sınırlı retry (GET olduğu için güvenli), circuit breaker. Çağrıyı `@Transactional` dışında yaparım ki DB bağlantısı tutulmasın. Devre açıksa 503 + `Retry-After`.","senior":"Önce rolünü netleştiririm. Sadece kur veriyorsa: timeout 1 sn, tek retry jitter'lı, circuit breaker, çift başına kısa önbellek; bayat kur ancak iş biriminin onayladığı yaşa kadar, yoksa 503. Execute adımında dış çağrı olmadığı için kur servisi düşse bile verilmiş quote'lar yürür. Sağlayıcı trade'i yürütüyorsa timeout ne başarı ne hatadır: işlem PENDING kalır, kaynak para düşülmüştür, aynı referansla sorulur, kesin red gelirse telafi kaydıyla iade; gün sonu raporla mutabakat. Sağlayıcının idempotency desteği seçim kriterim. İzlediklerim: sağlayıcı p99, devre durumu, en eski PENDING yaşı.","interviewer":"Junior retry'ı körlemesine yapıyor; yan etkili çağrıda çift işlem riski. Mid doğru katmanları biliyor. Senior çağrının yan etkisine göre ayrışıyor, belirsiz sonucu ayrı bir durum olarak modelliyor ve bayat kur kararını işe bırakıyor.\n\n**Takip sorusu:** Trade isteği timeout aldı, kurtarma worker'ı sorduğunda sağlayıcı \"böyle bir işlem yok\" dedi. Hemen iade eder misin?"},"href":"/kitap/22-case-hesap-servisi-deposit-withdraw-exchange/"},{"kind":"open","id":"kitap/22-case-hesap-servisi-deposit-withdraw-exchange#4","category":"Gerçek Mülakattan","label":"Case","level":"İleri","short":"$undefined","questionMd":"Günde 1M için ne değişir, 100M olursa ne değişir?","answers":{"junior":"100M'de mikroservislere bölerim, Kafka ve Redis eklerim, Kubernetes ile ölçeklerim.","mid":"1M'de tek DB yeter. 100M ≈ 1.150 rps ortalama, tepede ~10 bin. Okumaları read replica'ya taşırım, cache eklerim, ledger'ı partition'larım, pod sayısını artırıp PgBouncer koyarım.","senior":"1M'de değişen bir şey yok; mevcut tasarım tepeyi 10 kat karşılar. 100M'de önce ölçerim: yazma tepesi binlerce tps, tek primary'nin sınırına yaklaşır. Sırayla: bakiye dışındaki okumalar replica'ya (yazma sonrası okuma primary'den), PgBouncer, ledger'ın aylık partition'ları, bildirim gibi kritik olmayan işler outbox + Kafka ile asenkron, sıcak sistem hesapları için bucket. Yine yetmezse `customer_id` ile sharding: exchange aynı müşterinin hesapları arasında olduğu için tek shard'da kalır, ACID korunur; sadece müşteriler arası transfer shard'lar arası saga olur. Shard anahtarını bu yüzden seçerim.","interviewer":"Junior ölçmeden mimari değiştiriyor. Mid doğru teknikleri sayıyor. Senior adımları maliyet sırasıyla diziyor ve shard anahtarını işlemlerin tek shard'da kalmasına göre seçerek tutarlılığı koruyor.\n\n**Takip sorusu:** Sharding sonrası \"bir müşterinin tüm hesaplarının TL karşılığı toplamı\" raporu nasıl üretilir?"},"href":"/kitap/22-case-hesap-servisi-deposit-withdraw-exchange/"},{"kind":"open","id":"kitap/23-production-hata-ayiklama-loglama-ve-tracing#1","category":"Gerçek Mülakattan","label":"Production'da hata ayıklama","level":"Orta","short":"$undefined","questionMd":"Distributed logging nasıl yapılır?","answers":{"junior":"Bütün servislerin loglarını ELK gibi merkezi bir yere gönderirim. Sonra Kibana'da hata mesajını ya da zamanı arayarak ilgili logları bulurum. Her servise de bir request id ekleyebilirim.","mid":"Her isteğe bir traceId atanır ve servisler arasında `traceparent` header'ıyla taşınır. Spring Boot 3'te Micrometer Tracing bunu yapar, traceId ve spanId MDC'ye girer ve log satırına eklenir. Loglar JSON olarak stdout'a yazılır, Fluent Bit ile Elasticsearch'e gider; Kibana'da traceId ile arayınca tüm servislerin logları gelir. Kafka'da da observation açılırsa traceId header'la taşınır. Trace'leri de Zipkin ya da Jaeger'da görürüm.","senior":"Üç parçası var: kimlik, taşıma, toplama. Kimlik W3C Trace Context; traceId edge'de üretilir, her atlamada `traceparent`'la taşınır. Spring'de Micrometer Tracing + OTel bridge kullanırım ve zincirin kırıldığı yerleri bilirim: builder'sız HTTP client'lar, executor ve `CompletableFuture`'lar (`ContextPropagatingTaskDecorator`), Kafka'da `observation-enabled` ve batch listener'lar, outbox relay. Eski Sleuth servisleri varsa geçişte B3 de üretirim.\n\nLoglar ortak alan şemalı ECS JSON; traceId'nin yanında orderId gibi iş anahtarları da var, çünkü bir siparişin yaşamı birden çok trace'tir. Toplama stdout → DaemonSet ajanı → backend; backend seçimi maliyet sorusu: tam metin arama gerekiyorsa Elasticsearch, hacim büyükse Loki (traceId label değil, içerik filtresi). traceId her logda var ama trace'ler örneklenir; hatalı trace'leri tail sampling ile tutarım. Ve üç sinyal arasında tek tıkla geçiş: exemplar ile p99'dan trace'e, trace'ten loglara.","interviewer":"Junior cevap merkezi toplamayı biliyor ama korelasyonu zamana ve mesaja bırakıyor; \"request id\" doğru sezgi ama nasıl taşınacağı yok. Mid cevap mekanizmayı doğru anlatıyor. Senior cevap mekanizmanın **nerelerde kırıldığını** biliyor, örneklemenin \"logda var, trace'te yok\" sonucunu söylüyor ve backend seçimini maliyete bağlıyor.\n\n**Takip sorusu:** `@Async` ile çalışan bir metodun loglarında traceId boş geliyor. Neden olur ve hangi iki farklı yolla çözersin?"},"href":"/kitap/23-production-hata-ayiklama-loglama-ve-tracing/"},{"kind":"open","id":"kitap/23-production-hata-ayiklama-loglama-ve-tracing#2","category":"Gerçek Mülakattan","label":"Production'da hata ayıklama","level":"Orta","short":"$undefined","questionMd":"Serviste hata aldın, ilk nereye bakarsın?","answers":{"junior":"Önce loglara bakarım, hata mesajını ve stack trace'i bulurum. Kodda o satıra gidip hatayı düzeltirim. Gerekirse local'de tekrar etmeye çalışırım.","mid":"Önce ne zaman başladığına ve o sırada deploy olup olmadığına bakarım; deploy varsa rollback düşünürüm. Sonra Grafana'da hata oranına ve latency'ye bakarım, hangi endpoint'in etkilendiğini bulurum. Bir hatalı isteğin traceId'siyle trace'i açıp hangi serviste ve hangi çağrıda hata olduğunu görürüm, sonra o traceId ile logları okurum. DB ya da başka bir servis kaynaklıysa oraya geçerim.","senior":"Önce etki ve aciliyet: hangi SLO, kaç kullanıcı, ne zamandan beri. Sonra \"ne değişti\": deploy, config, flag, trafik, altyapı. Deploy ile başladıysa ve geri uyumsuz bir migration yoksa kök nedeni beklemeden rollback; flag varsa daha da hızlı.\n\nSonra daraltırım: sadece p99 mu kötü yoksa p50 de mi, tek pod mu hepsi mi, 4xx mi 5xx mi. Bir örneğin traceId'siyle hatanın ya da zamanın hangi span'de olduğunu görürüm. Span bir bağımlılığı gösteriyorsa hipotezi metrikle doğrularım: Hikari pending, `pg_stat_activity`'de kilit bekleyenler ve `blocked_by`, consumer lag, circuit breaker. Bağımlılıklar temizse JVM (GC, throttling, birkaç thread dump), restart varsa `describe` ve `--previous`. Gerekirse tek pod'u `/actuator/loggers` ile geçici DEBUG'a alırım. Sonunda blameless postmortem; aksiyonlardan biri her zaman \"bunu neden daha önce görmedik?\"in cevabıdır.","interviewer":"Junior cevap local debug zihniyetinde: etkiyi ve son değişikliği sormuyor, kullanıcılar hata alırken kod okuyor. Mid cevap doğru başlıyor ve trace kullanıyor ama hipotezi metrikle test etmiyor, alt katmanları somut araçlarla anlatmıyor. Senior cevap önceliği (önce hafiflet), daraltma tekniklerini, her katman için somut bir sinyali ve olay sonrası öğrenmeyi içeriyor; rollback'in ne zaman güvenli olmadığını da biliyor.\n\n**Takip sorusu:** Rollback yaptın ama hata oranı düşmedi. Bu sana ne söyler ve sonraki adımın ne olur?"},"href":"/kitap/23-production-hata-ayiklama-loglama-ve-tracing/"},{"kind":"open","id":"kitap/23-production-hata-ayiklama-loglama-ve-tracing#3","category":"Gerçek Mülakattan","label":"Production'da hata ayıklama","level":"İleri","short":"$undefined","questionMd":"traceId servisler arasında nasıl taşınır? Kafka'da ne olur?","answers":{"junior":"traceId bir header'la gönderilir, karşı servis de onu alıp kullanır. Kafka'da da mesajın içine traceId alanı eklerim.","mid":"HTTP'de W3C `traceparent` header'ıyla taşınır: sürüm, traceId, parent span id ve sampled flag. Spring Boot'ta `RestClient.Builder` ya da `WebClient.Builder` ile oluşturulan client'lar header'ı otomatik ekler, gelen istekte de Spring MVC okur. Kafka'da payload'a değil record header'ına yazılır; Spring Kafka'da `spring.kafka.template.observation-enabled` ve `spring.kafka.listener.observation-enabled` açılınca producer yazar, consumer okur ve span'i aynı trace'e bağlar.","senior":"$57","interviewer":"Junior cevap traceId'yi payload'a koymayı öneriyor; bu, iş sözleşmesini taşıma detayıyla kirletir ve framework enstrümantasyonunu devre dışı bırakır. Mid cevap standardı ve Spring ayarlarını biliyor. Senior cevap header'ın her atlamada nasıl değiştiğini, zincirin kırıldığı yerleri, mesajlaşmada parent-child ile link farkını ve edge'deki güven sınırını ekliyor.\n\n**Takip sorusu:** Bir consumer aynı mesajı retry topic üzerinden üç kez işledi. Trace'te bunu nasıl görmek istersin ve loglarda nasıl ayırt edersin?"},"href":"/kitap/23-production-hata-ayiklama-loglama-ve-tracing/"},{"kind":"open","id":"kitap/23-production-hata-ayiklama-loglama-ve-tracing#4","category":"Gerçek Mülakattan","label":"Production'da hata ayıklama","level":"Başlangıç","short":"$undefined","questionMd":"Log, metrik ve trace arasındaki fark nedir, ne zaman hangisini kullanırsın?","answers":{"junior":"Log uygulamanın yazdığı mesajlardır, metrik CPU ve bellek gibi sayılardır, trace de isteğin servisler arasındaki yoludur. Hata olunca log'a, performans için metriğe bakarım.","mid":"Metrik zamana göre toplanmış sayılardır; ucuzdur, alarm ve dashboard için kullanılır (RED, USE). Log tek bir olayın detayıdır; hatanın nedenini anlamak için. Trace bir isteğin servisler arası yolculuğudur; darboğazın nerede olduğunu gösterir. Üçünü traceId bağlar: alarm metrikten gelir, yavaş trace'e bakarım, sonra o trace'in loglarını okurum. Metriğe userId gibi yüksek kardinaliteli label koymam, onlar log ve trace'e gider.","senior":"Üçü farklı soruları farklı maliyetle cevaplar. Metrik \"ne kadar, ne zaman\": önceden toplanmış, ucuz, uzun saklanır; alarm ve SLO metrikten kurulur, bedeli kardinalitedir. Log \"tam olarak ne oldu\": sınırsız bağlam ama hacimle doğrusal maliyet; sayımı log'a yaptırmam. Trace \"zaman nerede geçti, kim kimi çağırdı\": yapısı vardır ama örneklenir, tam sayım için güvenilmez.\n\nKullanım bir akıştır: metrik bozulduğunu, trace nerede bozulduğunu, aynı traceId'li loglar neden bozulduğunu söyler. Bir sinyal diğerinin işini yapınca (log'dan sayım, metrikte userId, trace'i audit kaydı sanmak) maliyet ya da doğruluk sorunu çıkar. Dördüncü sinyal continuous profiling'dir: trace span'in yavaş olduğunu, profil CPU'nun o sürede hangi metotta harcandığını söyler.","interviewer":"Junior cevap tanımları biliyor ama \"metrik CPU ve bellektir\" diyerek istek ve iş metriklerini atlıyor. Mid cevap üç sinyali doğru konumluyor ve kardinaliteyi biliyor. Senior cevap her sinyali cevapladığı soru ve maliyetiyle tanımlıyor, örneklemenin trace'e etkisini, yanlış kullanımın sonuçlarını ve profiling'i ekliyor.\n\n**Takip sorusu:** Bir ödeme sağlayıcısının hata oranını sağlayıcı bazında izlemek istiyorsun. Bunu metrik mi, log mu, trace mi olarak tasarlarsın ve label'ların ne olur?"},"href":"/kitap/23-production-hata-ayiklama-loglama-ve-tracing/"},{"kind":"open","id":"kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan#1","category":"Gerçek Mülakattan","label":"Spring'in iç yüzü","level":"Orta","short":"$undefined","questionMd":"@SpringBootApplication nasıl çalışır?","answers":{"junior":"`@SpringBootApplication`, Spring Boot uygulamasını başlatan anotasyon. İçinde `@Configuration`, `@EnableAutoConfiguration` ve `@ComponentScan` var. Bu anotasyonu main sınıfına koyunca Spring her şeyi otomatik ayarlıyor, bean'leri buluyor ve Tomcat'i başlatıyor.","mid":"Üç annotation'ın birleşimi. `@SpringBootConfiguration` ana sınıfı konfigürasyon sınıfı yapıyor. `@ComponentScan` ana sınıfın paketinden itibaren `@Component`, `@Service` gibi sınıfları tarıyor; bu yüzden ana sınıfı kök pakete koyuyoruz. `@EnableAutoConfiguration`, jar'lardaki `AutoConfiguration.imports` dosyalarında listelenen auto-configuration sınıflarını yüklüyor; bunlar `@ConditionalOnClass`, `@ConditionalOnMissingBean` gibi koşullarla korunuyor. Belirli bir auto-config'i `exclude` ile kapatabiliyorum, tarama kökünü `scanBasePackages` ile değiştirebiliyorum. Asıl işi `SpringApplication.run` başlatıyor.","senior":"$58","interviewer":"Junior \"otomatik ayarlıyor\" diyerek mekanizmayı atlıyor ve annotation'ın kendisinin iş yaptığını ima ediyor; bu, \"annotation'lar metadata'dır\" farkındalığının olmadığını gösterir. Ayrıca içinde doğrudan `@Configuration` değil, onu meta-annotation olarak taşıyan `@SpringBootConfiguration` vardır. Mid parçaları ve işlevlerini doğru sayıyor. Senior annotation'ı okuyan kodu (run, `ConfigurationClassPostProcessor`, `MergedAnnotations`) adlandırıyor, deferred import ile `@ConditionalOnMissingBean` arasındaki nedensellik bağını kuruyor, `@AutoConfigurationPackage`'ın gözden kaçan etkisini biliyor ve mekanizmadan pratik kurallar ile doğrulama yöntemi çıkarıyor.\n\n**Takip sorusu:** \"Ana sınıfı `com.example.checkout.api` paketine taşıdık; controller'lar çalışıyor ama `OrderRepository` bulunamıyor. Neden ve nasıl düzeltirsin?\""},"href":"/kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan/"},{"kind":"open","id":"kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan#2","category":"Gerçek Mülakattan","label":"Spring'in iç yüzü","level":"Orta","short":"$undefined","questionMd":"Reflection nedir, Spring nerede kullanır, bedeli ne?","answers":{"junior":"Reflection, Java'da çalışma anında sınıfların metotlarına ve alanlarına erişmeyi sağlayan bir API. Private alanlara bile erişebiliyoruz. Spring de `@Autowired` için reflection kullanıyor. Yavaş olduğu için çok kullanılmaması gerekiyor.","mid":"`Class` nesnesi üzerinden `getDeclaredFields`, `getDeclaredMethods`, `getDeclaredConstructors` ile yapıyı okuyorum; `Constructor.newInstance`, `Method.invoke`, `Field.set` ile çalıştırıyorum; private üyeler için `setAccessible(true)` gerekiyor. Spring bean'leri constructor'ı reflection ile çağırarak oluşturuyor, field injection'da `Field.set` kullanıyor, `@PostConstruct` ve controller metotlarını `Method.invoke` ile çağırıyor. Jackson ve Hibernate de DTO ve entity'leri reflection ile okuyor. Java 16'dan beri modül sistemi yüzünden JDK iç paketlerine reflection ile erişim varsayılan olarak `InaccessibleObjectException` veriyor, eski kütüphanelerde `--add-opens` gerekebiliyor. Annotation'ları okumak için retention'ın `RUNTIME` olması gerekiyor.","senior":"$59","interviewer":"Junior tanımı ve \"yavaştır\" ezberini veriyor ama ne kadar, nerede ve neden yavaş olduğunu bilmiyor. Mid API'yi ve Spring'deki kullanım yerlerini somut sayıyor, JPMS'i biliyor. Senior maliyeti kalemlere ayırıyor, nerede ödendiğini (açılış vs istek) ayırt ediyor, JDK sürümündeki değişikliği biliyor, kapsülleme ve native image boyutunu ekliyor, alternatifleri sıralıyor ve \"ne zaman kullanmam\" diyor. Ayrıca scan'in reflection değil bytecode okuma olduğunu belirtmesi, mekanizmayı gerçekten bildiğini gösteriyor.\n\n**Takip sorusu:** \"Spring'in `@Transactional`'ı uygulamak için kullandığı proxy reflection mı? JDK proxy ile CGLIB arasında bu açıdan ne fark var?\""},"href":"/kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan/"},{"kind":"open","id":"kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan#3","category":"Gerçek Mülakattan","label":"Spring'in iç yüzü","level":"Orta","short":"$undefined","questionMd":"@ComponentScan nasıl çalışır?","answers":{"junior":"`@ComponentScan` verilen paketteki `@Component`, `@Service`, `@Repository` ve `@Controller` anotasyonlu sınıfları bulup bean olarak ekliyor. Spring Boot'ta `@SpringBootApplication` içinde olduğu için ayrıca yazmaya gerek yok.","mid":"Paket verilmezse annotation'ın bulunduğu sınıfın paketinden başlayıp alt paketleri tarar, bu yüzden Boot'ta ana sınıf kök pakette olmalı. `@Service`, `@Repository` gibi anotasyonlar `@Component` ile meta-annotated olduğu için hepsi bulunur. `includeFilters` ve `excludeFilters` ile tarama daraltılabilir. Bulunan sınıflar bean tanımı olarak kaydedilir; bean adı sınıf adının küçük harfle başlayan hali olur. Kütüphanelerde scan yerine `@Import` veya auto-configuration kullanılır.","senior":"$5a","interviewer":"Junior \"ne yapar\"ı söylüyor. Mid kök paket kuralını, meta-annotation'ı, filtreleri ve isimlendirmeyi biliyor. Senior tarama hattını uçtan uca (deseni, kaynak çözümlemeyi, bytecode okumayı, filtre sırasını, koşulları, isimlendirmeyi, kaydı) ve her adımın nedenini anlatıyor, hata modlarını ve ölçümü ekliyor, kütüphane ile uygulama arasında bilinçli bir tasarım kuralı koyuyor.\n\n**Takip sorusu:** \"Classpath'te `ojdbc` olmayan bir projede, Oracle'a referans veren bir sınıf taranan pakette duruyor. Spring açılışta neden patlamıyor, hangi durumda patlar?\""},"href":"/kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan/"},{"kind":"open","id":"kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan#4","category":"Gerçek Mülakattan","label":"Spring'in iç yüzü","level":"Başlangıç","short":"$undefined","questionMd":"Spring context nedir? BeanFactory'den farkı ne?","answers":{"junior":"Spring context, Spring'in bean'leri tuttuğu yer. `ApplicationContext` ile bean'lere erişebiliyoruz. `BeanFactory` daha eski ve basit bir versiyonu, artık `ApplicationContext` kullanılıyor.","mid":"`ApplicationContext`, Spring'in IoC container'ı ve `BeanFactory`'yi genişletiyor. `BeanFactory` bean tanımlarını tutar ve `getBean` ile nesne verir; `ApplicationContext` buna event yayını, `Environment` ve profiller, i18n, kaynak yükleme ve post-processor'ların otomatik kaydını ekler. Ayrıca singleton'ları açılışta eager oluşturur, bu yüzden konfigürasyon hataları açılışta görünür. Boot'ta web uygulamasında context `AnnotationConfigServletWebServerApplicationContext` oluyor ve `refresh()` sırasında bean'ler oluşup Tomcat başlıyor.","senior":"$5b","interviewer":"Junior `BeanFactory`'yi \"eski versiyon\" sanıyor; oysa `ApplicationContext` onu kullanıyor, yerine geçmiyor. Mid ayrımı ve eklenen hizmetleri doğru biliyor. Senior context'i iç yapısıyla (tarif deposu, cache, BPP listesi) tarif ediyor, refresh şablonunu operasyonel sonuçlarına (readiness, kaynak sızıntısı, graceful shutdown, test süresi) bağlıyor ve hiyerarşinin pratik etkisini biliyor.\n\n**Takip sorusu:** \"Bir `BeanFactoryPostProcessor`'ı `@Bean` metoduyla tanımladın ve aynı `@Configuration` sınıfındaki `@Value` alanları `null` geldi. Neden?\""},"href":"/kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan/"},{"kind":"open","id":"kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan#5","category":"Gerçek Mülakattan","label":"Spring'in iç yüzü","level":"Başlangıç","short":"$undefined","questionMd":"Uygulama açılırken bir bean bulunamadı hatası alıyorsun. Nasıl çözersin?","answers":{"junior":"Hata mesajında hangi bean'in bulunamadığını görürüm. Genelde o sınıfa `@Service` veya `@Component` eklemeyi unutmuşuzdur, eklerim. Olmazsa `@ComponentScan` ile paketi eklerim.","mid":"Boot'un \"APPLICATION FAILED TO START\" raporu hangi sınıfın hangi constructor parametresinin hangi tipi istediğini söyler. Önce o tipin implementasyonunun bean olup olmadığına bakarım: stereotype annotation var mı, ana sınıfın paketinin altında mı, bir `@Profile` veya `@ConditionalOnProperty` yüzünden mi elenmiş. Auto-configuration'dan gelmesi gereken bir bean'se `--debug` ile conditions report'a bakarım; rapor hangi koşulun tutmadığını yazar. Interface için birden çok implementasyon varsa hata farklı olur, `NoUniqueBeanDefinitionException` alırım.","senior":"$5c","interviewer":"Junior semptomu tek bir nedene bağlıyor ve tahminle `@ComponentScan` ekliyor; bu, ana sınıftaki meta scan'i bozarak daha büyük bir soruna yol açabilir. Mid doğru teşhis araçlarını biliyor. Senior exception türlerini oluştukları aşamaya göre ayırıyor, nedenleri mekanizma katmanlarına göre sistematik eliyor (scan, koşul, auto-config, özel tarayıcılar, test slice, tip), her katman için bir kanıt aracı veriyor ve hatanın tekrarını önleyen test stratejisiyle kapatıyor.\n\n**Takip sorusu:** \"Lokalde açılıyor, CI'daki `@SpringBootTest`'te aynı bean bulunamıyor. Nerelere bakarsın?\""},"href":"/kitap/24-spring-ic-yuzu-baslangic-reflection-ve-component-scan/"},{"kind":"open","id":"sorular/ci-cd#1","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"CI, geliştiricilerin değişikliklerini sık (en az günde bir) ana dala entegre ettiği ve her commit'in otomatik olarak build edilip test edildiği bir pratiktir. Amaç entegrasyon hatalarını küçükken ve oluştuğu anda yakalamaktır. Jenkins ya da GitHub Actions bu pratiği otomatikleştiren araçlardır; CI'ın kendisi değildir.","questionMd":"CI nedir, neden yapılır?","answers":{"junior":"CI, Jenkins gibi bir aracın her push'ta kodu derleyip testleri çalıştırmasıdır. Bizde Jenkins var, yani CI yapıyoruz.","mid":"CI, herkesin kodunu sık sık ana dala merge etmesi ve her merge'de otomatik build ve test koşması demek. Böylece iki kişinin değişikliği çakışırsa günler sonra değil hemen fark ediliyor. Araç bunun otomasyon kısmı.","senior":"CI bir alışkanlıktır: küçük değişiklikler, günde en az bir kez ana dala entegrasyon, her commit'te otomatik build ve test, ve kırmızı build'in hemen düzeltilmesi. Uzun ömürlü feature branch'lerde çalışıp sonunda merge eden bir ekip, her branch'te pipeline koşsa bile CI yapmıyordur; çünkü entegrasyon hâlâ sonda ve büyük parçalar hâlinde oluyor.","interviewer":"Junior cevap CI'ı araçla eşitliyor; en yaygın yanlış budur. Mid cevap pratiği ve amacını doğru anlatıyor. Senior cevap ayırt edici iki noktayı ekliyor: entegrasyonun sıklığı ve kırmızı build'e verilen tepki. Mülakatta \"araç var, pipeline var\" demek CI'ı bildiğini göstermez; \"ne sıklıkla ana dala merge ediyorsunuz?\" sorusuna verilen cevap gösterir.\n\n**Takip sorusu:** Ekibinde branch'ler ortalama iki hafta açık kalıyor. Pipeline her branch'te yeşilse bu ekip CI yapıyor mu?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#2","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Continuous delivery'de ana dal her an production'a çıkabilir durumdadır, ama prod'a çıkış bilinçli bir karar ya da onayla yapılır. Continuous deployment'ta tüm kontrollerden geçen her değişiklik insan müdahalesi olmadan otomatik olarak prod'a gider. Aradaki fark son adımdaki manuel onaydır; geri kalan otomasyon aynıdır.","questionMd":"Continuous delivery ile continuous deployment arasındaki fark nedir?","answers":{"junior":"Continuous delivery kodu staging'e otomatik deploy etmek, continuous deployment ise prod'a deploy etmek demek. CD ikisinin kısaltması.","mid":"İkisinde de pipeline otomatik. Delivery'de prod'a çıkmadan önce birisi onay veriyor ya da butona basıyor; deployment'ta testler geçerse doğrudan prod'a çıkıyor. Delivery'de de her build prod'a çıkabilecek kalitede olmalı.","senior":"Delivery'de her build bir release adayıdır ve prod'a çıkış bir iş kararıdır; deployment'ta bu karar test ve otomatik kontrollere devredilmiştir. Deployment'a geçmenin ön koşulu teknik değil güvendir: güçlü test seti, canary ve otomatik rollback, feature flag. Bankacılıkta genelde delivery + dört göz onayı görülür.","interviewer":"Junior cevap farkı \"staging mi prod mu\" olarak kuruyor; yanlış. Delivery'de de pipeline prod'a kadar gider, sadece son adım onaylıdır. Mid cevap doğru. Senior cevap deployment'a geçişin neye bağlı olduğunu söyleyerek kavramı pratiğe bağlıyor. Bonus: \"deploy\" ile \"release\"i ayırabilen aday (flag ile kapalı deploy) bir adım öndedir.\n\n**Takip sorusu:** Continuous deployment yapan bir ekipte bitmemiş bir özellik nasıl prod'a çıkar ama kullanıcıya görünmez?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#3","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Checkout, build, unit test, statik analiz ve güvenlik taraması, integration test, artifact/image build ve registry'e push, staging deploy, smoke/e2e test, (delivery'de) manuel onay, prod deploy, post-deploy doğrulama ve gerekirse rollback. Sıralama ilkesi: en ucuz ve hızlı geri bildirim en önde. Image yalnızca testlerden geçen kod için build edilir ve ortamlar arasında aynı image taşınır.","questionMd":"Tipik bir CI/CD pipeline'ının aşamaları nelerdir, neden bu sırada?","answers":{"junior":"Önce Docker image'ı build ederim, sonra staging'e deploy edip orada testleri koşarım. Testler geçerse prod'a çıkarım.","mid":"Checkout, derleme, unit test, Sonar analizi, integration test, image build ve push, staging deploy, smoke test, onay ve prod deploy. Hızlı testler önce gelir ki hatalı kod için boşuna image build edilmesin.","senior":"Aynı listeyi \"geri bildirim maliyeti\" ile sıralarım: saniyelik kontroller (derleme, unit, lint) önce, dakikalık olanlar (Testcontainers, tarama) sonra, ortam gerektirenler (smoke, e2e) en sonda. Prod deploy bitince iş bitmez: hata oranı ve latency izlenir, eşik aşılırsa geri dönülür. Sıra aynı zamanda güven zinciridir: prod'a giden şey, her aşamadan geçmiş aynı artifact'tır.","interviewer":"Junior cevap test etmeden image build ediyor ve testleri staging'e erteliyor; geri bildirim gecikiyor, staging kırık image'larla doluyor. Mid cevap doğru sırayı veriyor. Senior cevap sırayı bir ilkeye bağlıyor ve post-deploy doğrulamayı hattın parçası sayıyor; mülakatta ezber listeden çok bu \"neden\" aranır.\n\n**Takip sorusu:** Integration testler 15 dakika sürüyor. PR pipeline'ında mı, merge sonrası pipeline'da mı koşmalı?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#4","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Ana dalda kırmızı build ekibin en öncelikli işidir. Önce kimin hangi commit'le kırdığını ve hatanın gerçek mi ortamdan mı kaynaklandığını anlarım; hızlı düzeltilemiyorsa commit'i revert ederim, sonra düzeltip tekrar gönderirim. Kırmızının üstüne yeni değişiklik merge edilmez ve \"bir daha koşalım yeşil olur\" yaklaşımı kabul edilmez.","questionMd":"Build kırıldığında ne yaparsın?","answers":{"junior":"Pipeline'ı bir daha çalıştırırım, genelde ikinci seferde geçiyor. Geçmezse hatayı düzeltip yeni commit atarım; bu arada diğerleri çalışmaya devam edebilir.","mid":"Logdan hangi adımın kırıldığına bakarım. Lokal ortamda pipeline'daki komutun aynısıyla (`./mvnw -B verify`) yeniden üretmeye çalışırım. Hata benim commit'imdense hemen düzeltirim, uzun sürecekse revert ederim. Ekibe kırmızı olduğunu haber veririm.","senior":"Kural \"hattı durdur\": kırıldığı sürece ana dala başka merge girmez, sorumlu kişi on dakika içinde düzeltemiyorsa revert eder. Revert bir başarısızlık değil, ana dalı her an çıkarılabilir tutmanın yoludur. Tekrar eden kırılmalara ayrıca bakarım: aynı test sık kırılıyorsa flaky'dir ve ayrı ele alınır.","interviewer":"Junior cevap iki yaygın hatayı içeriyor: körlemesine yeniden çalıştırmak (gerçek bir race condition'ı gizleyebilir) ve kırmızının üstüne çalışmaya devam etmek (bir sonraki kırılmanın nedeni karışır). Mid cevap doğru adımları biliyor. Senior cevap bunu ekip kuralına çeviriyor ve revert'i normal bir araç olarak görüyor.\n\n**Takip sorusu:** Build sadece CI'da kırılıyor, lokalde her seferinde geçiyor. Hangi farklara bakarsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#5","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Unit testler build'in hemen ardından, en önde koşar; saniyeler sürer ve dış bağımlılık kullanmaz. Integration testler unit testler geçtikten sonra, Testcontainers ile ayağa kaldırılan gerçek PostgreSQL ya da Kafka'ya karşı koşar. Maven'da unit testleri Surefire (`test` fazı), integration testleri Failsafe (`integration-test` ve `verify` fazları) çalıştırır; `mvn verify` ikisini de koşar.","questionMd":"Unit ve integration testler pipeline'da nerede ve nasıl koşar?","answers":{"junior":"Testlerin hepsi `mvn test` ile koşuyor. Integration testler için ortak dev veritabanına bağlanıyoruz, orada veri zaten hazır.","mid":"Unit testleri Surefire, `*IT` adlı integration testleri Failsafe ile ayırırım; pipeline'da `./mvnw verify` ikisini de sırayla koşar. Integration testlerde Testcontainers ile her koşuda temiz bir PostgreSQL açarım, böylece testler ortak bir veritabanına bağımlı olmaz.","senior":"Ayrımın amacı geri bildirim hızı ve izolasyon. Unit testler kırılırsa integration aşamasına hiç geçilmez. Integration testler kendi container'ını açar ve kendi verisini kurar; paylaşılan bir dev DB'ye bağlı testler sıraya ve başkasının verisine bağımlı hale gelip flaky olur. Testcontainers'ı test sınıfları arasında tek container ile paylaşarak süreyi düşürürüm.","interviewer":"Junior cevaptaki asıl sorun ortak dev veritabanı: testler başkasının verisiyle, sıraya bağlı ve paralel koşulamaz hale gelir; flaky testin bir numaralı kaynaklarından biridir. Mid cevap Surefire/Failsafe ayrımını ve izolasyonu biliyor. Senior cevap ayrımın nedenini ve süreyi düşürme yolunu ekliyor.\n\n**Takip sorusu:** Failsafe ile koşan bir integration test başarısız olduğunda neden `integration-test` fazında değil de `verify` fazında build kırılır?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#6","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Artifact, build'in ürettiği ve deploy edilen çıktıdır: bir JAR, bir Docker image. \"Build once, deploy many\" ilkesine göre artifact bir kez üretilir, registry'e konur ve staging'den prod'a aynı artifact (aynı image digest'i) taşınır. Böylece prod'a giden şey, test edilenin ta kendisi olur; ortamlar arasında yalnızca konfigürasyon değişir.","questionMd":"Artifact nedir, neden bir kez build edip ortamlar arasında taşırız?","answers":{"junior":"Prod için aynı commit'ten yeniden build alırız. Kod aynı olduğu için çıkan JAR da aynı olur, sorun yok.","mid":"Aynı commit'ten yeniden build almak aynı sonucu garanti etmez: bağımlılık sürümleri, SNAPSHOT'lar, base image ya da build aracı değişmiş olabilir. Bu yüzden staging'de test ettiğim image'ı prod'a terfi ettiririm.","senior":"Artifact'ın kimliği etiketi değil digest'idir; staging'de doğrulanan digest prod'a gider. Ortam farkı image içinde değil, konfigürasyondadır. Bu aynı zamanda denetim izi sağlar: prod'daki image'dan commit'e, test sonuçlarına ve tarama raporuna geri gidebilirim.","interviewer":"Junior cevap \"aynı kod aynı binary\" varsayımı yapıyor; build tekrarlanabilir değilse (ki çoğu zaman tam değildir) prod'a test edilmemiş bir şey gider. Mid cevap nedenleri sayıyor. Senior cevap digest kavramını ve izlenebilirliği getiriyor.\n\n**Takip sorusu:** Maven ile `-Pprod` profiliyle prod'a özel bir JAR build eden bir ekibe ne önerirsin?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#7","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Servis image'larını değişmez bir etiketle versiyonlarım: genelde git commit SHA'sı (gerekirse build numarası ya da semver ile birlikte). `latest` değişken bir etikettir: bugün başka, yarın başka image'ı gösterir; hangi kodun çalıştığını bilemezsin, rollback hedefi belirsizleşir ve iki pod farklı image çekebilir. Kütüphaneler için semver anlamlıdır, servis image'ları için asıl kimlik digest'tir.","questionMd":"Docker image'ını nasıl versiyonlarsın, latest etiketinin sorunu nedir?","answers":{"junior":"Her build'de image'ı `latest` olarak push'larız, deployment da `latest`'i çeker. Böylece hep en güncel sürüm çalışır.","mid":"Image'ı commit SHA'sıyla etiketlerim, örneğin `order-service:3f2c1ab`. Böylece prod'da hangi commit'in çalıştığını bilirim ve önceki SHA'ya dönerek rollback yaparım. Registry'de etiketlerin üzerine yazılmasını (tag immutability) kapatırım.","senior":"SHA ile etiketler, deploy manifest'inde mümkünse digest'i kullanırım. Semver'i, başka ekiplerin bağımlı olduğu kütüphaneler ve API sözleşmeleri için kullanırım; orada major/minor/patch bir anlam taşır. `latest` yalnızca lokal deneme içindir.","interviewer":"Junior cevap tam olarak tuzağın kendisi: `latest` ile neyin çalıştığı bilinmez, rollout sırasında farklı pod'lar farklı image çekebilir ve \"önceki sürüme dön\" diyecek bir hedef yoktur. Ayrıca Kubernetes'te etiket `latest` ise varsayılan `imagePullPolicy` `Always` olur; davranış ortamdan ortama şaşırtıcı biçimde değişir. Mid ve senior cevaplar değişmezliği ve izlenebilirliği öne koyuyor.\n\n**Takip sorusu:** Etiketi SHA olan bir image registry'de silinip aynı etiketle yeniden push'lanırsa ne olur, bunu nasıl engellersin?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#8","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Secret'lar Git'e, Dockerfile'a ya da image'a girmez. Pipeline'da CI aracının secret deposunu (GitHub Secrets, GitLab masked/protected variables, Jenkins Credentials) kullanırım; bulut erişimi için mümkünse statik anahtar yerine OIDC ile kısa ömürlü kimlik alırım. Uygulamanın çalışma zamanı secret'ları Vault ya da AWS Secrets Manager'da durur ve pod'a runtime'da gelir.","questionMd":"Pipeline'da secret'ları nasıl saklarsın?","answers":{"junior":"Veritabanı şifresini `application-prod.yml`'a koyarız, repo zaten private. Bazen Dockerfile'da `ENV DB_PASSWORD=...` olarak da veriyoruz.","mid":"Şifreleri GitHub Secrets'ta tutar, workflow'da `${{ secrets.DB_PASSWORD }}` ile kullanırım; loglarda maskelenir. Uygulama şifreleri image'a değil, Kubernetes'e Secrets Manager'dan gelir. Private repo güvenlik önlemi değildir; repo'ya erişen herkes ve her fork şifreyi görür.","senior":"İki ayrı secret türü var: pipeline'ın kendi kimliği (registry, bulut) ve uygulamanın runtime secret'ları. Birincisi için OIDC ile repo ve ortama kısıtlı kısa ömürlü rol, ikincisi için secret manager ve rotasyon. Image katmanları ve `docker history` kalıcıdır; bir kez image'a giren secret sızmış sayılır ve rotate edilir.","interviewer":"Junior cevap iki ciddi hata yapıyor: secret'ı Git'e koymak (geçmişte sonsuza kadar kalır) ve image'a gömmek (image'ı çeken herkes okur). Mid cevap doğru yeri biliyor ve \"private repo\" yanılgısını düzeltiyor. Senior cevap pipeline kimliği ile uygulama secret'ını ayırıyor ve sızıntı sonrası rotasyonu biliyor.\n\n**Takip sorusu:** Fork'tan açılan bir PR'ın pipeline'ı secret'lara erişebilmeli mi? Neden?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#9","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"Aynı artifact her ortamda çalışır; ortam farkı dışarıdan verilen konfigürasyondur. Spring Boot'ta profil (`SPRING_PROFILES_ACTIVE`), ortam değişkenleri (`SPRING_DATASOURCE_URL` gibi relaxed binding), Kubernetes ConfigMap, ya da Spring Cloud Config / AWS Parameter Store kullanılır. Secret'lar konfigürasyondan ayrı, secret manager'dan gelir.","questionMd":"Ortam bazlı konfigürasyonu (dev, staging, prod) nasıl yönetirsin?","answers":{"junior":"Her ortam için Maven profili var: `mvn package -Pprod` ile prod JAR'ını build ederiz, içinde prod ayarları olur.","mid":"Tek JAR build ederim. Ortak ayarlar `application.yml`'da, ortama özgü olanlar `application-staging.yml` gibi profillerde ya da ortam değişkenlerinde. Kubernetes'te ConfigMap ile `SPRING_PROFILES_ACTIVE` ve URL'leri veririm. Şifreler ayrı, Secret'tan gelir.","senior":"Kural: image ortamı bilmez. Profil dosyalarını az ve sade tutarım; çoğu değeri ortam değişkeni ya da merkezi config'ten alırım ki hangi değerin nereden geldiği belli olsun. Başlangıçta `@ConfigurationProperties` + `@Validated` ile eksik konfigürasyonda uygulamanın açılmamasını sağlarım; yanlış ayarla açılıp sessizce çalışmasından iyidir.","interviewer":"Junior cevap ortam başına build alarak \"build once\" ilkesini bozuyor: prod'a giden JAR staging'de test edilmemiş bir JAR olur. Mid cevap doğru ayrımı yapıyor. Senior cevap konfigürasyonun izlenebilirliğini ve erken doğrulamayı ekliyor; bu, \"staging'de çalışıyordu, prod'da açılmadı\" sorunlarını önler.\n\n**Takip sorusu:** Aynı property hem `application-prod.yml`'da hem ortam değişkeninde tanımlıysa hangisi kazanır?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#10","category":"Operasyon","label":"CI/CD ve pipeline","level":"Başlangıç","short":"PR pipeline'ı değişikliğin merge edilmeye uygun olup olmadığını hızlıca söyler: build, unit ve integration test, statik analiz, güvenlik taraması; bunlar branch protection'da zorunlu kontroldür. Main pipeline'ı bunlara ek olarak artifact ve image üretir, registry'e push'lar ve deploy eder. PR pipeline'ı deploy etmez ve prod kimlik bilgilerine erişmez.","questionMd":"Pull request açıldığında pipeline'da ne koşmalı, main'e merge sonrası ne değişir?","answers":{"junior":"PR'da bir şey koşmaya gerek yok, merge edince pipeline zaten koşuyor. Kırılırsa düzeltiriz.","mid":"PR'da build, testler ve Sonar koşar; hepsi yeşil olmadan ve review onayı gelmeden merge edilemez. Merge sonrası aynı kontroller tekrar koşar, ardından image build ve staging deploy olur.","senior":"PR pipeline'ı hızlı olmalı ki küçük PR'lar teşvik edilsin. Bir tuzak: PR, eski bir main'e göre test edilmiş olabilir; iki yeşil PR birlikte main'i kırabilir. Bunu merge queue (ya da \"branch güncel olmalı\" kuralı) ile çözerim. PR job'larına minimum izin veririm.","interviewer":"Junior cevap hatayı main'e taşıyor: herkes kırık main üzerinde çalışır. Mid cevap zorunlu kontrolleri ve review'u biliyor. Senior cevap \"iki yeşil PR main'i kırabilir\" problemini ve merge queue çözümünü biliyor; bu, pipeline'ı gerçekten işleten birinin bildiği bir ayrıntıdır.\n\n**Takip sorusu:** PR pipeline'ı 25 dakika sürüyor ve geliştiriciler PR'ları büyütmeye başladı. Ne yaparsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#11","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Flaky test, kod değişmeden bazen geçip bazen kalan testtir ve pipeline'a güveni yok eder. Önce tespit ederim (aynı commit'te farklı sonuç), testi bir sahibi ve kaydı olan karantinaya alırım, sonra kök nedeni düzeltirim: zaman, sıra bağımlılığı, paylaşılan durum, asenkron bekleme, port veya container başlangıcı. Otomatik retry ile gizlemek kalıcı çözüm değildir.","questionMd":"Flaky test'i nasıl ele alırsın?","answers":{"junior":"Surefire'da `rerunFailingTestsCount=3` açarız, test üç denemede bir kere geçerse sorun yok demektir.","mid":"Retry kısa vadeli bir yamadır. Flaky testi `@Disabled` ya da bir tag ile ana hattan çıkarıp ticket açarım, sonra nedenine bakarım. Sık neden `Thread.sleep` ile asenkron sonucu beklemek; bunu Awaitility ile koşul bekleyecek şekilde değiştiririm. Saat bağımlılığı varsa `Clock` enjekte ederim.","senior":"Flaky oranını ölçerim: CI geçmişinden aynı commit'te hem geçen hem kalan testleri çıkarırım. Karantinanın süresi ve sahibi olur; yoksa karantina mezarlığa döner. Kök neden kategorileri: paylaşılan durum (static, DB verisi, test sırası), zaman ve timezone, asenkron işlem, kaynak yarışları (port, container), dış servis. Bazen flaky test production'daki gerçek bir race condition'ın tek işaretidir; bu yüzden \"testi sil\" son seçenektir. Kural olarak yeni flaky test eklenmesini görünür kılarım, çünkü ekip kırmızıya alışınca gerçek kırılmayı da yeniden çalıştırmaya başlar.","interviewer":"Junior cevap sorunu gizliyor: retry hem pipeline'ı yavaşlatır hem de gerçek bir eşzamanlılık hatasını görünmez yapar. Mid cevap karantina ve yaygın nedenleri biliyor. Senior cevap ölçüm, sahiplik ve \"flaky test bir bug olabilir\" bakışını getiriyor. Takipte, adayın somut bir flaky test hikayesi anlatabilmesi aranır.\n\n**Takip sorusu:** Bir integration test sadece testler paralel koşunca kalıyor. Nereden başlarsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#12","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Önce ölçerim: hangi adım zamanın çoğunu alıyor. Sonra tipik kazançlar: bağımlılık cache'i (Maven/Gradle), Docker layer cache, bağımsız job'ları paralel koşmak, testleri parçalara bölmek (sharding), Testcontainers container'larını paylaşmak, ucuz kontrolleri öne alıp erken düşmek. Gereksiz işi de kaldırırım: değişmeyen modülü build etmemek, ağır e2e testleri her PR'da değil merge sonrası koşmak.","questionMd":"Yavaş bir pipeline'ı nasıl hızlandırırsın?","answers":{"junior":"Daha güçlü bir runner alırız. Olmazsa yavaş testleri `@Disabled` yaparız.","mid":"Maven repository'yi cache'lerim (`setup-java` ile `cache: maven`), Docker build'de `cache-from` kullanırım, integration testleri ayrı bir job'a alıp unit testlerle paralel koşarım. Maven'da `-T 1C` ile modülleri paralel build ederim.","senior":"Önce kritik yolu çıkarırım; paralellik ancak kritik yoldaki adımı kısaltırsa işe yarar. Sonra ölçülebilir değişiklikler: bağımlılık ve build cache, Dockerfile'da katman sırası (bağımlılıklar kodu değiştirmeden önce), Testcontainers'ta singleton container, test sınıflarını eşit sürelere göre shard'lamak. Hızı kaliteden çalarak almam: testi kapatmak geri bildirimi hızlandırmaz, yok eder. Hedefi açık koyarım (PR pipeline'ı on dakikanın altında) ve süreyi metrik olarak izlerim, çünkü pipeline'lar fark edilmeden yavaşlar.","interviewer":"Junior cevap ya donanıma para atıyor ya da kaliteyi kesiyor; ikisi de ölçüm yapmadan verilen kararlar. Mid cevap somut teknikleri biliyor. Senior cevap \"önce ölç, kritik yolu bul\" diyerek mühendislik yaklaşımı gösteriyor ve pipeline süresini izlenen bir metrik olarak görüyor.\n\n**Takip sorusu:** Cache'i ekledin ama build süresi değişmedi. Cache'in gerçekten kullanıldığını nasıl doğrularsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#13","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Quality gate, pipeline'ın devam edebilmesi için kodun sağlaması gereken koşullardır: testlerin geçmesi, yeni kritik bulgu olmaması, yeni kodda belirli bir coverage, güvenlik açığı olmaması gibi. Tek başına coverage eşiği yeterli değildir: testin satırı çalıştırması, davranışı doğruladığı anlamına gelmez ve eşik oyunlaştırılabilir. Gate'i, yeni koda odaklanan ve riskle ilişkili koşullara kurarım.","questionMd":"Quality gate nedir, coverage eşiği koymak yeterli mi?","answers":{"junior":"SonarQube'da tüm proje için %80 coverage zorunlu yaparız; altına düşerse build kırılır. Böylece kod kalitesi garanti olur.","mid":"Tüm projeye eşik koymak eski kodu olan projelerde herkesin işini bloklar. Bunun yerine yeni koda bakarım: yeni kodda coverage, yeni bug ve güvenlik bulgusu olmaması. Coverage'ı bir sinyal olarak görürüm, hedef olarak değil.","senior":"Gate'in iki özelliği olmalı: güvenilir (yanlış alarm vermemeli) ve anlamlı (gerçek riski yakalamalı). Coverage'ın kalitesini görmek için kritik modüllerde mutation testing (PIT) kullanırım; assert'i olmayan test coverage'ı yükseltir ama hiçbir mutasyonu öldürmez. Gate'e, ekibin düzeltmeye hazır olduğu kurallar girer; yoksa insanlar istisna eklemeyi öğrenir. Gate hattı durdurduğunda bunun bir nedeni ve sahibi olmalı.","interviewer":"Junior cevap coverage'ı kaliteyle eşitliyor; Goodhart yasasının tipik örneği: assert'siz testlerle %80'e ulaşılır. Mid cevap \"yeni koda odaklan\" fikrini biliyor. Senior cevap gate'in tasarımına dair bir bakış ve test kalitesini ölçmenin yolunu (mutation testing) veriyor.\n\n**Takip sorusu:** Coverage %90 ama production'da sık bug çıkıyor. Nereye bakarsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#14","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Katmanlı düşünürüm: secret taraması (commit'te şifre var mı), SAST (kaynak kodda zafiyet kalıpları), SCA / bağımlılık taraması (kütüphanelerde bilinen CVE'ler) ve SBOM üretimi, container image taraması (base image ve OS paketleri), IaC taraması, ve çalışan uygulamaya karşı DAST. İlk dördü her build'de, DAST staging'de ya da periyodik olarak koşar. Bulgu politikası nettir: düzeltmesi olan kritik zafiyet hattı durdurur.","questionMd":"Pipeline'a hangi güvenlik taramalarını koyarsın?","answers":{"junior":"SonarQube koşuyoruz, güvenlik için yeterli. Bir de her commit'te DAST koşturabiliriz.","mid":"Sonar ya da Semgrep ile SAST, OWASP Dependency-Check, Snyk veya Dependabot ile bağımlılık taraması, Trivy ile image taraması, gitleaks ile secret taraması koyarım. DAST (OWASP ZAP) çalışan bir uygulama istediği için staging'e deploy sonrası koşar. Kritik ve düzeltmesi olan bulgularda build'i kırarım.","senior":"Taramayı build zamanıyla sınırlamam: bugün temiz olan bir image yarın yayınlanan bir CVE ile zafiyetli olur. Bu yüzden her image için SBOM (CycloneDX ya da SPDX) üretip saklarım ve prod'daki image'ları periyodik olarak yeniden değerlendiririm. Gürültüyü yönetirim: istisnalar gerekçeli, sahipli ve son kullanma tarihli olur; aksi halde ekip uyarıları okumayı bırakır. Base image'ı küçük tutmak (distroless ya da minimal JRE image'ı) bulgu sayısını en ucuz düşüren adımdır.","interviewer":"Junior cevap iki kavram hatası yapıyor: Sonar tek başına bağımlılık ve image zafiyetlerini kapsamaz; DAST ise çalışan bir uygulama gerektirdiği için her commit'te koşacak bir şey değildir. Mid cevap katmanları ve yerlerini doğru koyuyor. Senior cevap zamanın etkisini (yeni CVE'ler), SBOM'un neden saklandığını ve uyarı yorgunluğunu yönetmeyi biliyor.\n\n**Takip sorusu:** Log4Shell gibi bir zafiyet sabah duyuruldu. Hangi servislerinizin etkilendiğini kaç dakikada söyleyebilirsin, bunun için pipeline'da ne olmalıydı?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#15","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Rolling pod'ları kademeli değiştirir; ucuzdur ama trafiğin ne kadarının yeni sürüme gittiğini kontrol etmezsin. Blue-green yeni ortamı tam kurar ve trafiği tek seferde çevirir; rollback anlıktır ama kaynak iki katıdır ve risk tek seferde açılır. Canary trafiğin küçük bir yüzdesini yeni sürüme verir, metrikler iyiyse artırır; en düşük risk ama trafik bölme ve metrik analizi altyapısı ister. Üçünde de eski ve yeni sürüm bir süre aynı veritabanını paylaşır (ayrıntılı tablo için bkz. Kitap Bölüm 15).","questionMd":"Rolling, blue-green ve canary arasındaki fark nedir, hangisini ne zaman seçersin?","answers":{"junior":"Canary her zaman en iyisidir, çünkü en az risklidir. Blue-green'de iki ortam olduğu için veritabanı uyumu sorun olmaz, her ortamın kendi şeması olur.","mid":"Kubernetes varsayılanı rolling ve çoğu servis için yeterli. Anında rollback gereken, kesintiye toleransı düşük sistemlerde blue-green; yüksek trafikli ve metriği iyi ölçülen servislerde canary seçerim. Blue-green'de de veritabanı genelde ortaktır, bu yüzden şema iki sürüme uyumlu olmalı.","senior":"Seçimi üç soru belirler: riskin maliyeti, trafiğin istatistiksel olarak yeterli olup olmadığı ve altyapı. Düşük trafikli bir servisin %5 canary'si anlamlı bir sinyal üretmez; orada blue-green ve iyi smoke test daha dürüsttür. Canary'yi otomatik analizle (Argo Rollouts ya da Flagger) kurarım; insanın grafiğe bakıp karar verdiği canary yavaş ve tutarsızdır. Kafka consumer'ları gibi trafik yüzdesiyle bölünemeyen iş yüklerinde feature flag daha uygun bir canary aracıdır. Bankacılıkta yeni sürümü önce iç kullanıcılara açmak da bir canary biçimidir.","interviewer":"Junior cevap iki yanlış içeriyor: canary her durumda doğru seçim değil (düşük trafikte sinyal yok, altyapı maliyeti var) ve blue-green'de veritabanı neredeyse her zaman ortaktır; şema uyumluluğu ortadan kalkmaz. Mid cevap dengeli. Senior cevap seçimi kriterlere bağlıyor, otomasyonun önemini ve HTTP dışı iş yüklerini düşünüyor.\n\n**Takip sorusu:** Canary'de hata oranı stabil sürümle aynı ama iş metriği (ödeme dönüşümü) düşük. Rollout'u devam ettirir misin?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#16","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"Trunk-based development'ta herkes ana dala (trunk) sık merge eder; branch'ler kısa ömürlüdür (bir-iki gün). Bitmemiş iş, feature flag arkasında kapalı olarak ana dala girer; böylece kod sürekli entegre olur ama kullanıcıya görünmez. Flag deploy ile release'i ayırır ve iş bitince kaldırılır.","questionMd":"Trunk-based development nedir; bitmemiş bir özelliği ana dala nasıl merge edersin?","answers":{"junior":"Büyük bir özellik için uzun ömürlü bir feature branch açarız, iş bitince tek seferde merge ederiz. Böylece yarım iş ana dala girmez.","mid":"Özelliği küçük parçalara bölüp her gün merge ederim. Kullanıcıya görünen kısmı bir feature flag'in arkasında tutarım; flag kapalıyken eski akış çalışır. İş bitince flag'i önce test ortamında, sonra kademeli olarak prod'da açarım ve en son flag'i ve eski kodu silerim.","senior":"Flag dışında iki teknik daha kullanırım: önce altyapıyı görünmez biçimde eklemek (yeni endpoint kimse çağırmadan önce hazır olur) ve branch by abstraction (eski ve yeni implementasyonu bir arayüzün arkasına koyup geçişi oradan yapmak). Flag'lerin maliyetini yönetirim: her release flag'inin bir sahibi ve kaldırma tarihi olur, çünkü unutulan flag'ler test kombinasyonlarını katlar ve ölü kod bırakır. Flag kapalıyken de yeni kodun derlenip test edildiğini unutmam; hem açık hem kapalı yol test edilir.","interviewer":"Junior cevap, CI'ın çözmeye çalıştığı sorunu yeniden üretiyor: uzun branch, büyük ve riskli merge, geç fark edilen çakışma. Mid cevap flag ile kademeli açılımı ve temizliği biliyor. Senior cevap flag dışındaki teknikleri ve flag borcunu yönetmeyi ekliyor (flag türleri için bkz. Kitap Bölüm 15).\n\n**Takip sorusu:** Flag'in değerlendirmesi bir istekte açık, aynı kullanıcının sonraki isteğinde kapalı çıkıyor. Ne sorun yaratır, nasıl önlersin?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#17","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"OIDC federasyonu kullanırım: CI sağlayıcısı (GitHub Actions gibi) her job için imzalı, kısa ömürlü bir kimlik token'ı üretir; AWS bu token'ı güvenilir bir kimlik sağlayıcısından geldiği için kabul eder ve geçici kimlik bilgileri verir. Workflow'da `id-token: write` izni ve `aws-actions/configure-aws-credentials` ile `role-to-assume` gerekir. IAM rolünün trust policy'si, token'daki `sub` alanıyla hangi repo, branch ya da environment'ın rolü alabileceğini kısıtlar.","questionMd":"Pipeline'dan AWS'e uzun ömürlü access key olmadan nasıl erişirsin?","answers":{"junior":"Bir IAM kullanıcısı açıp access key ve secret key'i GitHub Secrets'a koyarız. Secrets şifreli olduğu için güvenli.","mid":"Statik anahtar sızarsa elle iptal edilene kadar geçerlidir ve genelde rotate edilmez. OIDC'de GitHub'ı AWS'te identity provider olarak tanımlarım, deploy için bir IAM rolü açarım, workflow'da `permissions: id-token: write` verip `configure-aws-credentials` ile rolü üstlenirim. Kimlik bilgisi job süresince geçerlidir.","senior":"Güvenlik trust policy'dedir: `aud` olarak `sts.amazonaws.com`, `sub` olarak `repo:org/repo:environment:prod` gibi dar bir değer. `repo:org/*` gibi geniş bir koşul, organizasyondaki herhangi bir repo'nun prod rolünü almasına izin verir. Her ortam için ayrı ve en az yetkili rol açarım: PR job'ları hiçbir role erişemez, staging rolü prod'a dokunamaz. Prod environment'ına onaycı koyarım ki rol ancak onaydan sonra alınabilsin. Üçüncü parti action'ları SHA'ya sabitlerim, çünkü kimlik token'ı alabilen her kod o rolü kullanabilir.","interviewer":"Junior cevap \"şifreli saklanıyor\" ile \"güvenli\" arasındaki farkı kaçırıyor: sorun saklama değil, anahtarın uzun ömürlü olması ve sızdığında geçerliliğini korumasıdır. Mid cevap mekanizmayı biliyor. Senior cevap asıl riskin trust policy'deki koşul olduğunu, ortam ayrımını ve tedarik zinciri boyutunu görüyor.\n\n**Takip sorusu:** Trust policy'de `sub` koşulunu `StringLike` ile `repo:org/order-service:*` yaptın. Bir geliştirici feature branch'inden prod rolünü alabilir mi?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#18","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"İki yaygın seçenek var: uygulama açılışında (Spring Boot'un Flyway/Liquibase entegrasyonu) ya da deploy'dan önce ayrı bir pipeline adımında veya Kubernetes Job'ında. Açılışta çalıştırmak basittir ama uzun migration'lar açılışı uzatır ve probe'ları aşabilir; büyük sistemlerde ayrı adım tercih edilir. Hangisi olursa olsun migration, o an çalışan eski sürümle uyumlu olmalıdır, çünkü rollout boyunca iki sürüm aynı şemayı kullanır.","questionMd":"Veritabanı migration'ları pipeline'ın neresinde çalışmalı?","answers":{"junior":"`spring.flyway.enabled=true` yeterli, uygulama açılırken migration'ları çalıştırır. Her pod kendi migration'ını çalıştırır, sorun olmaz.","mid":"Flyway aynı anda açılan pod'ları veritabanı kilidiyle sıraya sokar, yani migration iki kez çalışmaz. Ama uzun bir migration açılışı uzatır ve startupProbe aşılırsa pod restart döngüsüne girer. Bu yüzden büyük migration'ları ayrı bir pipeline adımında (`flyway migrate` ya da Maven plugin'i) deploy'dan önce çalıştırırım.","senior":"Ayrı adımın bir faydası daha var: yetki ayrımı. Uygulamanın DB kullanıcısı DDL yetkisine sahip olmaz; migration'ı ayrı, daha yetkili bir kullanıcı çalıştırır. Pipeline'da sıra şöyle olur: expand migration'ları deploy'dan önce, contract migration'ları birkaç release sonra ayrı bir değişiklikle. Migration önce staging'de, prod'a benzer veri hacmiyle koşar; küçük bir test DB'sinde saniyeler süren `ALTER` prod'da tabloyu dakikalarca kilitleyebilir. Migration oturumunda `lock_timeout` koyarım. Flyway'in checksum doğrulamasını da açık tutarım; uygulanmış bir migration dosyasını değiştirmek hatadır, yeni bir migration yazılır.","interviewer":"Junior cevap çalışır ama sınırlarını bilmiyor: kilit davranışı, uzun migration ve probe ilişkisi, yetki. Mid cevap sorunu ve alternatifi doğru anlatıyor. Senior cevap yetki ayrımı, expand ve contract'ın pipeline'daki zamanlaması, prod hacmiyle prova ve checksum disiplinini ekliyor (PostgreSQL kilit tuzakları için bkz. Kitap Bölüm 15).\n\n**Takip sorusu:** Migration ayrı adımda başarıyla çalıştı ama ardından gelen deploy başarısız oldu. Şema yeni, kod eski. Bu durum güvenli mi?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#19","category":"Operasyon","label":"CI/CD ve pipeline","level":"Orta","short":"GitOps'ta kümenin istenen durumu Git'te tutulur; Argo CD ya da Flux gibi bir controller küme içinde çalışır, Git'i sürekli kümeyle karşılaştırır ve farkı uygular (pull modeli). CI pipeline'ı kümeye erişmez; image'ı üretir ve Git'teki manifest'te image etiketini günceller. Böylece her deploy bir commit olur, geri almak bir revert olur ve elle yapılan değişiklikler (drift) otomatik düzeltilir.","questionMd":"GitOps nedir, pipeline'ın doğrudan kubectl apply yapmasından farkı ne?","answers":{"junior":"GitOps, Git'e push edince pipeline'ın tetiklenip `kubectl apply` ile deploy etmesi demek. Bizde zaten öyle.","mid":"Fark kimin kümeye dokunduğunda. Push modelinde CI'ın küme kimlik bilgisi vardır ve bir kez uygular; biri elle bir şey değiştirirse fark edilmez. GitOps'ta Argo CD kümenin içinden Git'i izler ve sürekli uzlaştırır. Deploy için ayrı bir config repo'sunda image etiketini değiştiren bir PR açılır.","senior":"GitOps'un kazancı denetim ve uzlaştırma: kim neyi ne zaman değiştirdi Git geçmişinde, prod'da elle yapılan değişiklik geri alınır, felaket sonrası küme Git'ten yeniden kurulabilir. Bedeli de var: uygulama kodu ile ortam konfigürasyonu ayrı repo'larda yaşar, \"deploy oldu mu\" sorusunun cevabı pipeline'da değil Argo CD'dedir, secret'lar için Sealed Secrets, SOPS ya da External Secrets gerekir. Ortamlar arası terfi, config repo'sunda bir etiketin staging dizininden prod dizinine taşınmasıdır; bu adıma PR onayı koyarak continuous delivery'nin onay kapısını Git'te uygularım.","interviewer":"Junior cevap tetikleyicinin Git olmasını GitOps sanıyor; asıl fark pull modeli ve sürekli uzlaştırmadır. Mid cevap farkı doğru koyuyor. Senior cevap faydaları ve bedelleri dengeli anlatıyor, terfiyi ve onayı GitOps içinde nasıl kuracağını gösteriyor.\n\n**Takip sorusu:** Bir mühendis gece olay sırasında `kubectl scale` ile replika sayısını artırdı. Argo CD ne yapar, bu iyi mi kötü mü?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#20","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"Migration geriye uyumluysa (expand) yalnızca uygulamayı önceki image'a döndürürüm; eski kod yeni şemayla çalışır, şemaya dokunmam. Bu yüzden rollback'in gerçek ön koşulu, her migration'ın N-1 sürümüyle uyumlu olmasıdır. Uyumsuz bir değişiklik çıktıysa seçenekler kötüleşir: veri kaybı riskli bir \"down\" migration ya da hızlı bir düzeltmeyle ileri gitmek (roll forward). İlk savunma hattı genelde feature flag'i kapatmaktır.","questionMd":"Deploy'u geri alman gerekti ama yeni sürüm bir migration çalıştırmıştı. Ne yaparsın?","answers":{"junior":"`kubectl rollout undo` ile uygulamayı geri alırım, sonra veritabanını da geri almak için migration'ın tersini yazıp çalıştırırım ya da yedekten dönerim.","mid":"Önce şemayı geri almam gerekip gerekmediğine bakarım. Eklenen nullable bir kolon ya da yeni bir tablo eski kodu bozmaz; sadece uygulamayı geri alırım, şema kalır. Yedekten dönmek, aradaki tüm gerçek işlemleri siler; bankacılıkta kabul edilemez. Migration'ları ileri yönlü düşünürüm.","senior":"Karar sırası: etkiyi en hızlı ne durdurur? Flag kapatmak saniyeler, image rollback dakikalar, roll forward ise düzeltmeyi yazmak, test etmek ve pipeline'dan geçirmek kadar sürer. Rollback'i güvenli kılan şey önceden alınmış kararlardır: migration'lar expand/contract ile bölünür, contract adımı rollback penceresi kapandıktan sonra yapılır, yeni sürüm eski sürümün okuyamayacağı veri yazmaya ancak eski sürüme dönülmeyeceği kesinleşince başlar. Down migration'a güvenmem: kolonu düşüren bir down script'i, yeni sürümün o kolona yazdığı veriyi siler. Flyway'in undo özelliği açık kaynak sürümde bulunmaz; Liquibase rollback tanımlarına izin verir, ama ikisinde de veri yönü sorunu aynıdır. Rollback'i prova ederim; hiç denenmemiş rollback planı, plan değildir.","interviewer":"Junior cevap şemayı da geri almaya çalışıyor; bu çoğu zaman veri kaybı demektir ve yedekten dönmek araya giren tüm işlemleri siler. Mid cevap \"şemaya dokunma, uygulamayı geri al\" ilkesini biliyor. Senior cevap kararı zamana göre sıralıyor, rollback'in güvenliğinin deploy öncesi tasarımda kazanıldığını gösteriyor ve araçların sınırlarını temkinli anlatıyor.\n\n**Takip sorusu:** Rollback penceresini (contract adımına kadar geçen süre) nasıl belirlersin? Bir hafta mı, bir release mi?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#21","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"Expand/contract (parallel change) ile değişikliği her biri geriye uyumlu adımlara bölerim: yeni yapıyı ekle, kod iki yere yazsın, eski veriyi batch'lerle taşı, okumayı yeni yapıya al, eskiye yazmayı bırak, en son eski yapıyı kaldır. Her adım ayrı bir release'tir ve tek başına geri alınabilir. Örnek: `amount numeric` kolonunu kuruş cinsinden `amount_minor bigint` kolonuna taşımak tek bir `ALTER COLUMN TYPE` ile yapılmaz.","questionMd":"Geriye uyumsuz bir şema değişikliğini sıfır kesintiyle nasıl deploy edersin?","answers":{"junior":"Flyway'de `ALTER TABLE payments ALTER COLUMN amount TYPE bigint USING (amount * 100)` yazarım, kodu da aynı anda güncellerim. Gece trafiği az olduğunda deploy ederim.","mid":"Tip değişikliği PostgreSQL'de tabloyu yeniden yazar ve yazmaları bloklayan bir kilit alır; büyük tabloda dakikalar sürer. Üstelik rollout sırasında eski pod'lar `amount`'u ondalıklı bekler. Bu yüzden `amount_minor` kolonunu nullable ekler, kodu iki kolona yazacak şekilde güncellerim, eski satırları batch'lerle doldururum, okumayı yeni kolona alırım ve en sonda eski kolonu silerim.","senior":"Adımlar Kitap Bölüm 15'teki rename örneğiyle aynı; burada farkı yaratan doğruluk kontrolleri. Çift yazma aynı transaction içinde olur ki iki kolon ayrışmasın. Backfill idempotent ve sürdürülebilir olur (id aralıkları, aralarda bekleme, replikasyon gecikmesini izleme). Okumayı taşımadan önce bir doğrulama sorgusu koşarım: `amount * 100 <> amount_minor` olan satır sayısı sıfır olmalı. Okumayı flag arkasında taşırım ki geri dönüş deploy gerektirmesin. Kolonu okuyan başka tüketicileri de listelerim: raporlama, CDC/Debezium üzerinden beslenen sistemler, Kafka event'leri. Contract adımına, rollback penceresi kapandıktan ve hiçbir tüketici eski kolonu kullanmadığı kanıtlandıktan sonra geçerim.","interviewer":"Junior cevap iki şeyi kaçırıyor: tip değişikliğinin tabloyu yeniden yazıp uzun süre kilitlemesi ve rollout sırasında iki sürümün birlikte çalışması. \"Gece deploy\" kesintiyi küçültür, ortadan kaldırmaz. Mid cevap doğru sırayı biliyor. Senior cevap sıranın ötesine geçiyor: tutarlılık (aynı transaction), doğrulama sorgusu, flag ile geri dönüş ve şemanın diğer tüketicileri. Senior seviyesini ayıran, \"veritabanı benim servisimin özel alanı mı\" sorusunu sormasıdır.\n\n**Takip sorusu:** Backfill sırasında replika gecikmesi 30 saniyeye çıktı. Ne yaparsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#22","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"Kısa ömürlü bir branch'te küçük bir değişiklik, PR pipeline'ı (build, test, analiz, tarama) ve review, merge queue ile main'e merge, main'de bir kez build edilen ve SHA ile etiketlenen image, registry, staging deploy ve otomatik testler, onay, prod'a kademeli (canary) çıkış, otomatik metrik analizi, flag ile kullanıcıya açılış ve sonrasında izleme. Her adım bir öncekinin ürettiği aynı artifact üzerinde çalışır ve izlenebilir.","questionMd":"Production'a giden bir değişikliğin baştan sona yolculuğunu anlat.","answers":{"junior":"Kodu yazıp push'larım, Jenkins build alır ve testleri koşar, sonra staging'e deploy eder. Test ekibi onay verince prod'a çıkarız.","mid":"Feature branch açıp küçük commit'lerle çalışırım. PR'da pipeline build, unit ve integration testleri, Sonar ve bağımlılık taramasını koşar; review onayı gelince merge ederim. Main pipeline'ı image'ı commit SHA'sıyla build edip ECR'a push'lar, staging'e deploy eder, smoke test koşar. Onaydan sonra aynı image rolling update ile prod'a çıkar; Grafana'da hata oranına ve latency'ye bakarım.","senior":"Yolculuğu kontrol noktaları ve kanıtlarla anlatırım. Değişiklik küçük ve flag arkasında; migration varsa expand adımı ayrı bir PR. PR'da hızlı kontroller ve review, merge queue ile güncel main üzerinde son doğrulama. Main'de tek build: image, digest, SBOM, imza; tarama sonuçları artifact'a bağlı. Deploy GitOps ile: staging'e otomatik, contract ve smoke testler, prod'a terfi config repo'sunda onaylı bir PR (bankacılıkta dört göz ve değişiklik kaydı). Prod'da canary, SLO'lara göre otomatik analiz, eşik aşılırsa otomatik geri dönüş. Sonra flag kademeli açılır; release, deploy'dan ayrı bir karardır. Son olarak ölçüm: bu yolculuğun süresi lead time, sonucu change fail rate. Her adımda \"bu adımı kim, hangi kanıta dayanarak geçirdi\" sorusunun cevabı vardır.","interviewer":"Junior cevap bir akış anlatıyor ama kalite kapılarının neden orada olduğunu, prod'a neyin gittiğini ve sonrasını anlatmıyor; manuel test onayı da tek kontrol noktası. Mid cevap sağlam bir standart akış. Senior cevap akışı güven zinciri olarak kuruyor: aynı artifact, kanıt, kademeli risk, deploy ile release ayrımı ve ölçüm. Bu soruda mülakatçı adayın gerçekten bir hattı uçtan uca sahiplendiğini mi, yoksa sadece kendi adımını mı bildiğini anlar.\n\n**Takip sorusu:** Bu yolculukta lead time 3 gün çıktı. En çok zamanın nerede kaybolduğunu nasıl bulursun?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#23","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"Monorepo'da asıl problem her değişiklikte her şeyi build etmemek: değişen modülleri ve onlara bağımlı olanları bulup sadece onları build, test ve deploy etmek gerekir (path filtreleri, Maven `-pl ... -am`, Gradle build cache, Bazel/Nx gibi araçlar). Polyrepo'da her servis bağımsızdır ama ortak pipeline mantığı ve servisler arası uyum sorun olur; bunu paylaşılan, versiyonlanan pipeline şablonları ve contract testlerle çözerim. Hangisi seçilirse seçilsin, her servis bağımsız deploy edilebilmelidir.","questionMd":"Monorepo ve polyrepo'da pipeline tasarımı nasıl değişir?","answers":{"junior":"Monorepo'da tek bir pipeline olur ve her commit'te bütün servisler build edilip deploy edilir. Böylece her şey hep uyumlu kalır.","mid":"Monorepo'da path filtresiyle sadece değişen servisin pipeline'ını tetiklerim. Ortak bir kütüphane değişirse ona bağlı tüm servisler build edilmeli; Maven'da `-pl common -amd` bağımlı modülleri de build eder. Polyrepo'da GitHub Actions reusable workflow'larıyla (`workflow_call`) ortak adımları tek yerde tutarım.","senior":"Monorepo'nun kazancı atomik değişiklik (kütüphane ve tüketicileri tek PR'da) ve tek tip araçlardır; bedeli build sisteminin olgunluğudur. Path filtrelerinin bir tuzağı var: GitHub'da path filtresi yüzünden hiç tetiklenmeyen bir workflow, zorunlu status check olarak tanımlıysa PR'ı \"beklemede\" bırakır ve merge'ü bloklar; bunu, her zaman koşan ve neyin etkilendiğine kendisi karar veren bir giriş job'ıyla çözerim. Monorepo'da \"her şeyi birlikte deploy etmek\" cazibesine kapılmam; aynı repo, aynı release demek değildir. Polyrepo'da ortak pipeline şablonunu versiyonlarım ki bir değişiklik yüz servisi aynı anda kırmasın; servisler arası uyumu da entegre bir staging'e güvenmek yerine consumer-driven contract testlerle sağlarım.","interviewer":"Junior cevap monorepo'yu \"her şeyi her seferinde deploy et\" ile karıştırıyor; bu hem yavaş hem de bağımsız deploy'u yok eder. Mid cevap etkilenen modül mantığını ve paylaşılan workflow'ları biliyor. Senior cevap trade-off'u açıkça koyuyor, zorunlu kontrol ile path filtresi etkileşimi gibi pratik bir tuzağı biliyor ve servis bağımsızlığını korumayı vurguluyor.\n\n**Takip sorusu:** Polyrepo'da paylaşılan pipeline şablonuna bir güvenlik taraması eklemek istiyorsun. Yüz servise nasıl ve hangi hızla yayarsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#24","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"DORA, yazılım teslimat performansını ölçen metriklerdir. Güncel tanımda beş metrik var: throughput tarafında change lead time, deployment frequency ve failed deployment recovery time; instability tarafında change fail rate ve deployment rework rate. Hız ve kararlılık birlikte okunur. Ekip düzeyinde iyileşmeyi izlemek içindir; bireyleri ya da ekipleri birbiriyle kıyaslamak için kullanılınca bozulur.","questionMd":"DORA metrikleri nedir, nasıl ölçülür ve nasıl yanlış kullanılır?","answers":{"junior":"DORA, ekibin ne kadar sık deploy ettiğini ölçer. Ne kadar çok deploy o kadar iyi; hedef olarak günde on deploy koyarız.","mid":"Dört temel metrik: lead time, deployment frequency, change failure rate ve hatadan kurtulma süresi. Hız metrikleri ile kararlılık metrikleri birlikte izlenir; sadece frekansı artırırsan hatalar da artabilir. Verileri Git, pipeline ve olay yönetimi aracından toplarım.","senior":"DORA son yıllarda tanımı güncelledi: kurtarma metriği artık \"failed deployment recovery time\" olarak deploy kaynaklı olaylara odaklanıyor ve \"deployment rework rate\" eklendi; mülakatta dört metrik demek de anlaşılır, ama güncel hali bilmek iyi bir sinyaldir. Ölçüm tanımlarını baştan netleştiririm: lead time commit'ten mi PR açılışından mı başlar, \"başarısız deploy\" neyi kapsar (rollback, hotfix, flag kapatma). Veriyi mümkün olduğunca otomatik toplarım; elle girilen veri hızla bozulur. En önemlisi kullanım: metrik bir darboğaz tartışması başlatmak içindir (\"lead time'ın yarısı review beklemesi\"), hedef olmak için değil. Frekansa hedef konursa ekip deploy'ları anlamsızca böler; change fail rate cezalandırılırsa olaylar sınıflandırılmaz.","interviewer":"Junior cevap tek bir metriği hedefe çeviriyor; Goodhart yasası burada hızla işler ve kararlılık tarafı hiç görünmez. Mid cevap klasik dört metriği ve dengeyi biliyor. Senior cevap güncel tanımı temkinli biçimde anıyor, ölçüm tanımlarının önemini ve metriğin kültürel olarak nasıl kullanılması gerektiğini anlatıyor.\n\n**Takip sorusu:** Change fail rate'iniz %2 ama ekipte herkes deploy'dan korkuyor. Bu metrik neyi kaçırıyor olabilir?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/ci-cd#25","category":"Operasyon","label":"CI/CD ve pipeline","level":"İleri","short":"Tedarik zinciri güvenliğinin üç parçası var: image'ı imzalamak (ör. Sigstore cosign), nasıl ve nerede build edildiğini anlatan provenance (köken) kaydı üretmek ve içindeki bileşenleri listeleyen SBOM'u saklamak. Deploy tarafında bir politika (ör. Kubernetes admission controller) yalnızca güvenilen kimlikçe imzalanmış ve beklenen pipeline'dan çıkmış image'ların çalışmasına izin verir. SLSA bu konudaki olgunluk seviyelerini tanımlayan bir çerçevedir.","questionMd":"Build ettiğin image'ın gerçekten senin pipeline'ından çıktığını ve değiştirilmediğini nasıl kanıtlarsın?","answers":{"junior":"Image'ı private registry'de tutuyoruz ve tarama yapıyoruz, yani güvenli. İmzalamaya gerek yok.","mid":"Registry'ye yazma yetkisi olan biri (ya da ele geçirilmiş bir CI) aynı etiketle başka bir image push'layabilir. Image'ı pipeline'da cosign ile imzalarım; keyless modda imza, pipeline'ın OIDC kimliğine bağlanır. Kümede bir politika aracıyla imzasız image'ları reddederim. Deploy'da etiket yerine digest kullanırım.","senior":"İmza \"kim\" sorusunu, provenance \"nasıl\" sorusunu cevaplar: hangi repo, hangi commit, hangi workflow, hangi parametrelerle. GitHub'ın artifact attestation'ları ve Docker BuildKit'in attestation desteği bu kaydı üretebilir; kesin özellikleri sürüme göre değiştiği için kurarken dokümana bakarım. Doğrulama asıl iştir: üretilen ama kontrol edilmeyen imza bir şey kanıtlamaz; admission politikası imzalayan kimliği (belirli repo ve workflow) da kontrol etmelidir. Zincirin başını da korurum: üçüncü parti action'ları SHA ile sabitlemek, bağımlılıkları checksum ile doğrulamak, base image'ı digest ile sabitleyip kontrollü güncellemek, build ortamını kısa ömürlü ve izole tutmak. İmza zafiyet olmadığını göstermez; sadece image'ın beklenen yerden geldiğini gösterir. Bu yüzden tarama ve SBOM ile birlikte çalışır.","interviewer":"Junior cevap erişim kontrolü ve taramayı köken doğrulamasıyla karıştırıyor; private registry, içeriden ya da ele geçirilmiş bir CI'dan gelen değişikliği engellemez. Mid cevap imza ve politika ile doğrulamayı biliyor. Senior cevap imza, provenance ve SBOM'un farklı soruları cevapladığını, doğrulamanın asıl kontrol olduğunu ve zincirin girdilerini (action'lar, bağımlılıklar, base image) korumayı anlatıyor; araç özellikleri konusunda temkinli olması da olgunluk işaretidir.\n\n**Takip sorusu:** Popüler bir üçüncü parti GitHub action'ı ele geçirildi ve etiketleri kötü amaçlı bir commit'e taşındı. Pipeline'ın etkilendi mi, nasıl anlarsın?"},"href":"/sorular/ci-cd/"},{"kind":"open","id":"sorular/docker#1","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Container, namespace'lerle izole edilmiş ve cgroup'larla kaynakları sınırlanmış sıradan bir Linux sürecidir. VM kendi kernel'iyle tam bir işletim sistemi çalıştırır, container ise host kernel'ini paylaşır. Bu yüzden container çok daha hızlı açılır ve daha az kaynak harcar, ama izolasyonu VM kadar güçlü değildir.","questionMd":"Container nedir, sanal makineden (VM) farkı nedir?","answers":{"junior":"Container hafif bir sanal makinedir. İçinde küçük bir işletim sistemi çalışır, VM'e göre daha az yer kaplar ve daha hızlı açılır.","mid":"Container sanal makine değil, host üzerinde izole çalışan bir süreçtir. Namespace'ler sürecin ne gördüğünü (süreç listesi, ağ, dosya sistemi, hostname) ayırır, cgroup'lar CPU ve bellek kullanımını sınırlar. VM ise hypervisor üstünde kendi kernel'ini açar. Container'lar kernel'i paylaştığı için saniyenin altında açılır; image içindeki \"işletim sistemi\" aslında sadece kullanıcı alanı dosyalarıdır (kütüphaneler, araçlar), kernel yoktur.","senior":"Container'ı \"namespace + cgroup + katmanlı dosya sistemi ile çalışan bir süreç\" olarak tanımlarım. Bunun iki pratik sonucu var: güvenlik sınırı kernel'dir, yani çok kiracılı ve güvenilmeyen kod çalıştırılan ortamlarda VM ya da gVisor/Kata gibi ek izolasyon gerekir. İkincisi, container'ın limitleri cgroup'tan gelir; JVM gibi uygulamaların bu limitleri görmesi gerekir, yoksa host'un kaynaklarını kendi kaynağı sanar.","interviewer":"Junior cevap en yaygın yanlışı içeriyor: container'ı \"hafif VM\" sanmak ve içinde bir işletim sisteminin \"çalıştığını\" düşünmek. Container'da ayrı bir kernel açılmaz; image'daki Ubuntu ya da Alpine sadece dosyalardır. Mid cevap namespace ve cgroup'u adıyla söylüyor ve kernel paylaşımını doğru kuruyor. Senior cevap bu bilgiyi güvenlik sınırına ve JVM'in kaynak görmesine bağlıyor. Başlangıç sorusunda namespace/cgroup kelimelerini duymak bile adayı ayırır.\n\n**Takip sorusu:** Mac'te Docker Desktop ile çalışan bir Linux container'ı hangi kernel'i kullanıyor?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#2","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Image, salt okunur katmanlardan ve çalıştırma ayarlarından oluşan bir şablondur. Container ise o image'ın çalışan örneğidir: image katmanlarının üstüne container'a özel yazılabilir bir katman eklenir ve bir süreç başlatılır. Bir image'dan birçok container açılabilir; container silinince yazılabilir katmandaki değişiklikler kaybolur.","questionMd":"Image ile container arasındaki fark nedir?","answers":{"junior":"Image class gibi, container da object gibi. Image'ı build ederiz, container olarak çalıştırırız. Container'da bir dosyayı değiştirirsem image da değişir.","mid":"Benzetme doğru ama son kısım yanlış olur: image değişmez. Container, image'ın katmanlarını salt okunur kullanır, yaptığı yazmalar container'a özel copy-on-write bir katmana gider. Container silinince bu katman da gider, image aynı kalır. Kalıcı veri gerekiyorsa volume kullanırım.","senior":"Image içerik adresli bir pakettir: katmanlar ve config bir digest ile tanımlanır, bu yüzden aynı digest her yerde aynı içeriktir. Container'da elle değişiklik yapıp `docker commit` ile image üretmek tekrarlanamaz bir yöntemdir; değişiklik Dockerfile'a girmeli. Container'ı geçici kabul ederim: her an silinip yeniden oluşturulabilmeli.","interviewer":"Junior cevaptaki \"container'da değiştirirsem image da değişir\" ifadesi copy-on-write mantığını bilmediğini gösteriyor; production'da container içinde yapılan bir düzeltmenin restart'ta kaybolması tam bu yanlıştan doğar. Mid cevap yazılabilir katmanı ve volume ihtiyacını doğru söylüyor. Senior cevap digest ile değişmezliği ve \"container geçicidir\" ilkesini ekliyor.\n\n**Takip sorusu:** Aynı image'dan açılmış on container diskte on kat yer kaplar mı? Neden?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#3","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Dockerfile, bir image'ın nasıl üretileceğini adım adım tarif eden metin dosyasıdır. `FROM` taban image'ı, `WORKDIR` çalışma dizinini, `COPY` dosya kopyalamayı, `RUN` build sırasında komut çalıştırmayı, `ENV` ortam değişkenini, `USER` kullanıcıyı, `ENTRYPOINT` ve `CMD` container açılınca çalışacak komutu belirler. `EXPOSE` sadece belgelemedir, port'u dışarı açmaz.","questionMd":"Dockerfile nedir, temel talimatları nelerdir?","answers":{"junior":"`FROM` ile başlarız, `COPY` ile jar'ı kopyalarız, `RUN java -jar app.jar` ile uygulamayı çalıştırırız. `EXPOSE 8080` port'u dışarı açar.","mid":"`RUN` build zamanında çalışır ve sonucu bir katman olur; uygulamayı başlatmak için `ENTRYPOINT` ya da `CMD` kullanılır. `RUN java -jar` yazarsam build uygulama kapanana kadar takılır. `EXPOSE` port'u açmaz, sadece image'ın hangi port'u dinlediğini belgeler; dışarı açmak `docker run -p` ile olur. `COPY`'yi `ADD`'e tercih ederim çünkü `ADD` arşivleri otomatik açar ve URL'den indirir, bu sürprizlidir.","senior":"Talimatları \"build zamanı\" (`RUN`, `COPY`, `ARG`) ve \"çalışma zamanı metadata'sı\" (`ENV`, `USER`, `ENTRYPOINT`, `CMD`, `EXPOSE`) diye ikiye ayırarak anlatırım. Bir Spring Boot image'ında ayrıca taban image'ı sabitlemeyi, root olmayan `USER`'ı ve exec form `ENTRYPOINT`'i varsayılan kabul ederim.","interviewer":"Junior cevapta iki klasik yanlış var: `RUN` ile uygulamayı başlatmaya çalışmak (build ile run zamanını karıştırmak) ve `EXPOSE`'un port'u açtığını sanmak. Mid cevap ikisini de düzeltiyor ve `ADD`/`COPY` farkını biliyor. Senior cevap talimatları zamanlarına göre sınıflandırıyor, bu da sonraki cache ve güvenlik sorularına iyi bir zemin.\n\n**Takip sorusu:** `ARG` ile `ENV` arasındaki fark nedir? Hangisi çalışan container'da görünür?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#4","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"`-p HOST:CONTAINER` host makinenin port'unu container'ın port'una yönlendirir (port publish); `-p 9090:8080` host'un 9090'ına gelen istek container'ın 8080'ine gider. `EXPOSE` ise sadece belgelemedir, tek başına hiçbir port'u dışarı açmaz. Port publish edilmezse container'a host'tan `localhost` ile erişilemez, ama aynı Docker ağındaki diğer container'lar erişebilir.","questionMd":"docker run -p 8080:8080 ne yapar? EXPOSE ile farkı nedir?","answers":{"junior":"Container'ın 8080 port'unu açar. Dockerfile'da `EXPOSE 8080` yazdıysam `-p`'ye gerek yok, port zaten açık olur.","mid":"`-p 8080:8080` host'un 8080'ini container'ın 8080'ine bağlar, sol taraf host, sağ taraf container. `EXPOSE` bir şeyi açmaz; `-P` (büyük harf) kullanılırsa `EXPOSE` edilen port'lar rastgele host port'larına publish edilir, tek etkisi bu. Uygulama container içinde `127.0.0.1`'e bind olursa publish edilse bile dışarıdan erişilemez; `0.0.0.0`'a bind olmalı. Spring Boot varsayılan olarak tüm arayüzleri dinler.","senior":"Port'u gerekmiyorsa host'un tüm arayüzlerine açmam: `-p 127.0.0.1:5432:5432` ile sadece yerelden erişilebilir yaparım. Linux'ta Docker port publish için iptables kurallarını kendisi yazar ve bu kurallar ufw gibi host firewall'larını atlayabilir; sunucuda yanlışlıkla internete açılmış veritabanlarının sık bir nedeni budur.","interviewer":"Junior cevap `EXPOSE`'un port açtığını sanıyor ve host ile container port'unu ayırt etmiyor. Mid cevap yönü (host:container), `EXPOSE`'un gerçek etkisini ve container içi bind adresi tuzağını biliyor. Senior cevap güvenlik boyutunu (tüm arayüzlere publish, firewall'un atlanması) ekliyor.\n\n**Takip sorusu:** Uygulamanın container içinde 8080'de çalıştığını ama host'tan `curl localhost:8080`'in bağlantı reddettiğini görüyorsun. Hangi sırayla neleri kontrol edersin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#5","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"İkisi de container'ın yazılabilir katmanı dışında, container silinince kaybolmayan veri tutar. Named volume'u Docker yönetir ve yeri Docker'ın kendi alanıdır; veritabanı verisi gibi kalıcı veriler için kullanılır. Bind mount host'taki belirli bir dizini container'a bağlar; geliştirmede kod ya da konfigürasyon paylaşmak için kullanışlıdır ama host'un dizin yapısına ve dosya izinlerine bağımlıdır.","questionMd":"Volume ile bind mount arasındaki fark nedir?","answers":{"junior":"Volume ile bind mount aynı şey, ikisi de host'taki bir klasörü container'a bağlar. Postgres verisini proje klasöründeki `./data`'ya bağlarım, böylece görebilirim.","mid":"Bind mount host'ta benim seçtiğim bir dizindir; named volume'u Docker oluşturur ve yönetir, `docker volume ls` ile görülür. Postgres gibi bir veritabanı için named volume tercih ederim: dosya izinleri ve sahipliği container içindeki kullanıcıya göre ayarlanır, bind mount'ta ise host ile container'daki UID farkı yüzünden izin hataları sık görülür; Mac'te bind mount performansı da düşüktür. Bind mount'u konfigürasyon dosyası ya da kod için kullanırım.","senior":"Seçimi verinin sahibine göre yaparım: veri container'ındır ve kalıcı olmalıysa named volume, veri host'undur (konfigürasyon, sertifika) ise salt okunur bind mount (`:ro`). Yazılması gerekmeyen her mount'u `:ro` yaparım. Bir de `docker compose down -v` volume'ları da siler; yerel veritabanını sıfırlamak için kullanışlı, yanlışlıkla çalıştırılınca can sıkıcıdır.","interviewer":"Junior cevap ikisini aynı sanıyor ve veritabanı verisini bind mount'a koymanın izin ve performans sorunlarını bilmiyor. Mid cevap yönetim farkını, UID/izin tuzağını ve hangi durumda hangisinin seçileceğini söylüyor. Senior cevap \"verinin sahibi\" ölçütünü ve `:ro`, `down -v` gibi işletme detaylarını ekliyor.\n\n**Takip sorusu:** Container'ın yazılabilir katmanına sürekli log ya da dosya yazan bir uygulamada zamanla ne olur?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#6","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Compose, birden fazla container'dan oluşan bir uygulamayı (ör. Spring Boot servisi, PostgreSQL ve Redis) tek bir YAML dosyasında tanımlayıp tek komutla (`docker compose up`) ayağa kaldırmayı sağlar. Servisler, port'lar, ortam değişkenleri, volume'lar ve aralarındaki bağımlılıklar dosyada durur; compose proje için ortak bir ağ kurar ve servisler birbirini adıyla bulur. Yerel geliştirme ve entegrasyon testi ortamı için kullanılır, production orkestrasyonu için değil.","questionMd":"Docker Compose ne işe yarar?","answers":{"junior":"Birden fazla container'ı birlikte çalıştırmaya yarar. `depends_on` yazınca uygulama veritabanı hazır olduktan sonra açılır.","mid":"Tanım doğru, ama `depends_on`'un kısa hali sadece başlatma sırası verir: Postgres container'ı başlatılır, hemen ardından uygulama başlar; Postgres o anda bağlantı kabul etmiyor olabilir. Hazır olmayı beklemek için Postgres'e bir `healthcheck` tanımlar ve `depends_on` altında `condition: service_healthy` kullanırım. Ayrıca named volume ile veritabanı verisini kalıcı yaparım.","senior":"Compose dosyasını ekibin \"tek komutla çalışan yerel ortamı\" olarak görürüm: yeni gelen biri `docker compose up` ile servisi bağımlılıklarıyla açabilmeli. Spring Boot tarafında `spring-boot-docker-compose` ile uygulama açılırken compose'u başlatıp bağlantı bilgilerini otomatik almak, testlerde ise Testcontainers kullanmak işi kolaylaştırır. Production'da yeniden başlatma, ölçekleme ve rollout Kubernetes gibi bir orkestratörün işidir.","interviewer":"Junior cevaptaki \"`depends_on` hazır olmayı bekler\" inancı yerel ortamda aralıklı açılış hatalarının en yaygın nedenidir. Mid cevap bunu düzeltip `service_healthy` ve healthcheck'i öneriyor. Senior cevap compose'un yerini (yerel ortam, test) ve sınırını (production orkestrasyonu değil) net çiziyor.\n\n**Takip sorusu:** Healthcheck ve `service_healthy` kullanmana rağmen uygulama çalışırken Postgres yeniden başlarsa ne olur? Uygulama tarafında buna nasıl dayanıklı olursun?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#7","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Her container'ın kendi network namespace'i vardır; container içindeki `localhost` container'ın kendisidir. Compose servisleri ortak bir ağa koyar ve Docker'ın gömülü DNS'i servis adlarını container IP'lerine çözer. Bu yüzden uygulama `jdbc:postgresql://postgres:5432/orders` gibi servis adı ve container port'uyla bağlanmalıdır.","questionMd":"Compose'da uygulama container'ı veritabanına neden localhost ile bağlanamaz?","answers":{"junior":"Uygulamayı IntelliJ'den çalıştırınca `localhost:5432` çalışıyordu, container'a alınca çalışmadı. Postgres container'ının IP'sini `docker inspect` ile bulup URL'ye yazarım.","mid":"IP yazmak kırılgan: container her oluşturulduğunda IP değişebilir. Compose varsayılan bir bridge ağı kurar ve servis adı DNS adı olur; URL'yi `postgres:5432` yaparım. Port olarak host'a publish edilen değil, container port'u kullanılır; postgres'i host'ta `15432:5432` diye publish etsem bile container'dan container'a `5432` ile gidilir. URL'yi koda değil ortam değişkenine (`SPRING_DATASOURCE_URL`) koyarım ki IDE'den ve compose'dan farklı değerle çalışsın.","senior":"Ağ modelini iki yöne ayırırım: dışarıdan içeri (host port publish) ve container'dan container'a (ortak ağ, servis adı, container port'u). Container'dan host'taki bir servise gitmek gerekirse Docker Desktop'ta `host.docker.internal` var, Linux'ta `extra_hosts: [\"host.docker.internal:host-gateway\"]` gerekir. Varsayılan `bridge` ağında isimle çözümleme olmadığını, kullanıcı tanımlı ağlarda olduğunu da bilirim.","interviewer":"Junior cevap sorunu IP'ye sabitleyerek \"çözüyor\": bir sonraki `up`'ta bozulacak bir çözüm. Asıl eksik, container'ın kendi `localhost`'u olduğunu bilmemek. Mid cevap servis adı ile DNS'i, host port ile container port farkını ve konfigürasyonun dışarıdan verilmesini doğru anlatıyor. Senior cevap yönleri ayırıyor ve host'a erişim ile varsayılan bridge farkı gibi kenar durumları biliyor.\n\n**Takip sorusu:** Uygulama container'ı içinden Postgres'e bağlantıyı nasıl test edersin, image'da `psql` ya da `curl` yoksa ne yaparsın?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#8","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"`latest` özel bir anlamı olmayan, sadece varsayılan tag adıdır; \"en yeni sürüm\" garantisi vermez ve her push'ta başka bir image'ı gösterebilir. Bu yüzden hangi kodun çalıştığı belirsizleşir, iki makine aynı tag'le farklı image çekebilir ve geri dönüş (rollback) zorlaşır. Production'da değişmez sürüm tag'leri ya da digest (`@sha256:...`) kullanılır.","questionMd":"latest tag'ini kullanmanın sakıncası nedir?","answers":{"junior":"`latest` her zaman en son build edilen image'ı gösterir, bu yüzden pratik. Sorun sadece bazen eski image cache'te kalması, onu da `docker pull` ile çözerim.","mid":"`latest` otomatik güncellenmez, sadece tag verilmeden push edilen image'a takılan bir etikettir. Biri eski bir branch'ten push ederse `latest` geriye gider. Aynı tag'in içeriği değişebildiği için iki node farklı image çalıştırabilir. Sürüm tag'i (`1.4.3`) ve git SHA'lı tag kullanırım. Taban image'da da `eclipse-temurin:latest` yerine en azından `21-jre` gibi bir sürüm veririm.","senior":"Tag'ler değiştirilebilir işaretçilerdir; değişmez olan digest'tir. Production deploy'unda digest'e sabitlerim, registry'de tag'leri immutable yapan ayarı açarım. Kubernetes'te tag `latest` ise ya da hiç verilmemişse `imagePullPolicy` varsayılan olarak `Always` olur; bu hem her pod açılışında registry bağımlılığı hem de aynı Deployment'ta farklı image'lar demektir.","interviewer":"Junior cevap `latest`'in bir mekanizma olduğunu, Docker'ın onu otomatik güncellediğini sanıyor. Mid cevap bunun sadece bir etiket olduğunu ve neden tehlikeli olduğunu söylüyor, taban image'a da uyguluyor. Senior cevap tag ile digest ayrımını, registry tarafındaki immutability ayarını ve Kubernetes'teki yan etkisini biliyor.\n\n**Takip sorusu:** Taban image'ı digest'e sabitlersen güvenlik yamaları nasıl gelir? Bunu nasıl otomatikleştirirsin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#9","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Container'daki uygulama log'larını dosyaya değil stdout ve stderr'e yazmalıdır. Docker bu akışları log driver'ı ile toplar; `docker logs -f ` ile okunur. Kubernetes ve log toplama ajanları da aynı akışı alır, bu yüzden dosyaya yazmak log'u görünmez yapar ve container diskini doldurur.","questionMd":"Container'ın log'ları nereye yazılmalı, nasıl okunur?","answers":{"junior":"Logback ile `/app/logs/app.log` dosyasına yazarım, gerekince `docker exec` ile girip `tail -f` ile bakarım.","mid":"Dosyaya yazılan log container'ın yazılabilir katmanında kalır: container silinince gider, `docker logs` göstermez, toplama ajanı göremez ve disk dolar. Spring Boot varsayılan olarak konsola yazar, bunu korurum. Production'da JSON formatında yazarım ki log sistemi alanları ayrıştırabilsin; Spring Boot 3.4'ten beri structured logging yerleşik geliyor.","senior":"Docker'ın varsayılan `json-file` driver'ı varsayılan ayarla dosyayı döndürmez; uzun yaşayan bir sunucuda `max-size` ve `max-file` vermezsem host diski dolar. Log'u stdout'a, metrik ve trace'i ayrı kanallara veririm; correlation id ve structured logging için bkz. Kitap Bölüm 15.","interviewer":"Junior cevap container dışı dünyadaki alışkanlığı taşıyor: dosyaya yazıp içeri girip okumak. Distroless bir image'da içeri girecek shell bile olmayabilir. Mid cevap stdout ilkesini ve nedenini, structured logging'i biliyor. Senior cevap log driver'ının döndürme ayarı gibi sık atlanan bir işletme tuzağını ekliyor.\n\n**Takip sorusu:** Uygulama açılırken hata verip hemen kapanıyor. Container artık çalışmıyorken log'larını nasıl görürsün?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#10","category":"Operasyon","label":"Docker ve container'lar","level":"Başlangıç","short":"Container, ana süreci (PID 1) yaşadığı sürece yaşar; ana süreç biterse container da durur. En yaygın nedenler: uygulamanın açılışta hata verip çıkması, ana komutun iş bitirip dönmesi (ör. bir script ya da arka plana atılan süreç) ve etkileşimli bir shell'in terminal olmadan açılması. `docker ps -a` ile çıkış kodu, `docker logs` ile hata okunur.","questionMd":"Container başlar başlamaz neden kapanıyor?","answers":{"junior":"Docker bazen container'ı kapatıyor; `restart: always` eklerim, yeniden açılır. Olmazsa son satıra `tail -f /dev/null` koyarım, container ayakta kalır.","mid":"Container'ın ayrı bir yaşam süresi yok, PID 1'in yaşam süresi var. Önce `docker ps -a` ile çıkış koduna bakarım: 1 genelde uygulama hatası, 137 SIGKILL (ör. bellek limiti), 143 SIGTERM. Sonra `docker logs` ile nedeni okurum; Spring Boot'ta çoğu zaman eksik bir ortam değişkeni ya da veritabanına bağlanamamaktır. Entrypoint script'i uygulamayı `&` ile arka plana atıp bitiyorsa container da biter; süreç ön planda çalışmalı. `tail -f /dev/null` hatayı gizler, restart politikası da sadece döngüye sokar.","senior":"Çıkış kodu ve log'dan sonra gerekirse image'ı entrypoint'i ezerek açarım (`docker run --rm -it --entrypoint sh image`) ve ortamı elle incelerim. Restart politikasını bir hatayı gizlemek için değil, geçici hatalardan toparlanmak için kullanırım.","interviewer":"Junior cevap semptomu bastırıyor: `restart: always` ve `tail -f /dev/null`, nedeni bulmadan container'ı \"ayakta\" gösterir ama uygulama çalışmıyor olabilir. Mid cevap PID 1 ilişkisini, çıkış kodlarının anlamını ve ön plan süreç kuralını biliyor. Senior cevap teşhis için entrypoint'i ezmeyi ve restart politikasının doğru kullanımını ekliyor.\n\n**Takip sorusu:** Çıkış kodu 137 gördün. Bunun bellek limiti yüzünden olduğunu nasıl doğrularsın?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#11","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Her `RUN`, `COPY` ve `ADD` bir katman üretir ve BuildKit her talimat için cache'te eşleşme arar: `COPY` için kopyalanan dosyaların içerik checksum'ına, `RUN` için komut metnine bakar. Bir talimatın cache'i bozulunca sonraki tüm talimatlar yeniden çalışır. Bu yüzden az değişen adımlar (bağımlılık tanımı ve indirme) üste, sık değişenler (kaynak kod) alta konur.","questionMd":"Layer cache nasıl çalışır? Dockerfile'da talimat sırası neden önemli?","answers":{"junior":"Docker her satırı cache'ler, ikinci build hızlı olur. Sıranın önemi yok; ben `COPY . .` yapıp sonra `mvn package` çalıştırıyorum, Docker değişmeyen kısımları zaten cache'ten alır.","mid":"`COPY . .` her kod değişikliğinde cache'i bozar ve ardından gelen `mvn package` bütün bağımlılıkları yeniden indirir. Önce `pom.xml`'i kopyalayıp `dependency:go-offline` çalıştırırım, sonra `src`'yi kopyalayıp derlerim. Böylece sadece `pom.xml` değiştiğinde bağımlılık katmanı yeniden üretilir. `RUN apt-get update` ile `apt-get install`'ı aynı satırda yazarım; ayrı yazarsam `update` katmanı cache'ten gelir ve eski paket listesiyle kurulum yapılır.","senior":"Katman cache'ini iki ayrı problem olarak görürüm: talimat sırası ve araç cache'i. `go-offline` her eklentiyi önceden çekmez ve `pom.xml`'deki tek satırlık değişiklik tüm bağımlılık katmanını bozar; bunun için BuildKit cache mount'u (`RUN --mount=type=cache,target=/root/.m2`) kullanırım, Maven deposu build'ler arasında kalır ama image'a girmez. CI'da her build temiz bir makinede çalışıyorsa yerel cache yoktur; registry ya da CI tabanlı build cache'i (`--cache-from`/`--cache-to`) gerekir. Çıktı tarafında da Spring Boot'un katmanlı jar'ıyla değişen kodu küçük bir katmana ayırırım.","interviewer":"Junior cevap cache'in dosya bazında \"akıllı\" çalıştığını sanıyor; gerçekte zincirleme çalışır ve ilk bozulan adımdan sonrası tamamen yeniden çalışır. Mid cevap Java'ya özgü doğru sırayı ve `apt-get update` tuzağını biliyor. Senior cevap cache mount'u, CI'da cache'in neden kaybolduğunu ve çıktı katmanlarını ayırmayı ekliyor.\n\n**Takip sorusu:** CI'da her build 6 dakika sürüyor ve çoğu Maven indirmesi. Hangi adımlarla düşürürsün?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#12","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Multi-stage build, tek Dockerfile'da birden fazla `FROM` aşaması tanımlayıp son image'a önceki aşamalardan sadece gereken dosyaları (`COPY --from=`) almaktır. Spring Boot'ta derleme JDK ve Maven/Gradle içeren bir aşamada yapılır, son image sadece JRE ve uygulamayı içerir. Sonuç: daha küçük, daha az CVE içeren ve kaynak kodu ya da build araçlarını taşımayan bir image.","questionMd":"Multi-stage build nedir? Spring Boot için neden kullanılır?","answers":{"junior":"İki `FROM` yazarız, ilkinde build alırız, ikincisinde çalıştırırız. Böylece image küçülür. Ben genelde jar'ı bilgisayarımda `mvn package` ile üretip tek aşamalı Dockerfile'la kopyalıyorum, o da aynı şey.","mid":"Yerelde build edip kopyalamak aynı şey değil: image artık geliştiricinin makinesindeki JDK sürümüne, yerel Maven ayarlarına ve o anda hangi dosyaların derlendiğine bağlı olur. Multi-stage'de build ortamı da Dockerfile'da tanımlıdır, her yerde aynı sonucu verir. İkinci aşamada JRE kullanırım; JDK'nın derleyici ve araçları çalışma zamanında gerekmez. Spring Boot jar'ını katmanlara ayırıp her katmanı ayrı `COPY` ile alırım ki bağımlılık katmanı cache'te kalsın.","senior":"Aşamaları sorumluluğa göre ayırırım: bağımlılık çözme, derleme, katmanlara ayırma ve çalışma zamanı. Test aşamasını da ayrı bir hedef yapabilirim (`docker build --target test`). Bazı ekipler derlemeyi CI'da yapıp Dockerfile'a sadece hazır artefaktı verir; bu da kabul edilebilir, yeter ki artefakt CI'ın kontrollü ortamından gelsin, geliştirici makinesinden değil. Son aşamada minimum taban image, root olmayan kullanıcı ve exec form `ENTRYPOINT` olur.","interviewer":"Junior cevap tekniği biliyor ama asıl faydayı (tekrarlanabilir build ortamı) kaçırıyor ve yerel jar'ı kopyalamayı eşdeğer sanıyor. Mid cevap bunu düzeltiyor, JDK/JRE ayrımını ve katmanlı jar'ı ekliyor. Senior cevap aşamaları sorumluluğa göre kurguluyor, `--target` kullanımını ve CI'da derleme alternatifinin hangi koşulda doğru olduğunu söylüyor.\n\n**Takip sorusu:** Final image'da `jcmd` gibi JDK araçları olmadığında production'da heap dump ya da thread dump nasıl alırsın?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#13","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"`ENTRYPOINT` container'ın çalıştıracağı sabit programı, `CMD` ise ona verilen varsayılan argümanları tanımlar. `docker run image arg1 arg2` yazıldığında `CMD` ezilir, `ENTRYPOINT` kalır ve argümanlar ona eklenir; `ENTRYPOINT`'i değiştirmek için `--entrypoint` gerekir. Sadece `CMD` varsa `docker run`'a verilen komut onun yerine geçer. İkisi de exec form (JSON dizi) ile yazılmalıdır.","questionMd":"ENTRYPOINT ile CMD arasındaki fark nedir?","answers":{"junior":"İkisi de aynı işi yapar, container açılınca çalışacak komutu belirler. Ben `CMD java -jar app.jar` yazıyorum, çalışıyor.","mid":"İkisi birlikte kullanılınca `ENTRYPOINT` + `CMD` birleşir: `ENTRYPOINT [\"java\", \"-jar\", \"app.jar\"]` ve `CMD [\"--spring.profiles.active=prod\"]` ise varsayılan çalıştırma bu ikisinin toplamıdır, `docker run image --server.port=9090` dersem `CMD` değişir. Ayrıca `CMD java -jar app.jar` shell form'dur: komut `/bin/sh -c` altında çalışır, PID 1 shell olur ve sinyaller Java'ya ulaşmaz. Exec form yazarım.","senior":"Kuralım: image bir uygulamayı paketliyorsa `ENTRYPOINT` exec form, değiştirilebilir argümanlar `CMD`'de. Ön hazırlık gerekiyorsa entrypoint script'i yazarım ve son satırı `exec java ... \"$@\"` olur; `exec` shell'i Java ile değiştirir, PID 1 Java olur ve `CMD` argümanları `\"$@\"` ile geçer. JVM ayarlarını `JAVA_TOOL_OPTIONS` ortam değişkeninden veririm ki image'ı yeniden build etmeden değiştirilebilsin.","interviewer":"Junior cevap iki talimatı eşdeğer sanıyor ve fark ettirmeden shell form kullanıyor; bu, bir sonraki sorudaki graceful shutdown probleminin kaynağıdır. Mid cevap birleşme kuralını ve shell form tuzağını biliyor. Senior cevap pratik bir kural, `exec` ve `\"$@\"` ile doğru script yazımı ve JVM ayarlarının dışarıdan verilmesini ekliyor.\n\n**Takip sorusu:** Entrypoint script'inde `exec` unutulursa `docker stop` sırasında tam olarak ne olur?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#14","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Multi-stage kurarım: ilk aşamada JDK ile, önce `pom.xml` ve bağımlılıklar sonra kaynak kod olacak şekilde derlerim ve jar'ı `java -Djarmode=tools -jar app.jar extract --layers` ile katmanlara ayırırım. Son aşamada JRE taban image'ına katmanları ayrı `COPY`'lerle alır, root olmayan kullanıcıya geçer ve exec form `ENTRYPOINT` ile başlatırım. Bellek ayarını `MaxRAMPercentage` ile veririm. Dockerfile yazmak istemezsem `spring-boot:build-image`/`bootBuildImage` ile buildpacks kullanırım.","questionMd":"Spring Boot uygulaması için iyi bir Dockerfile nasıl yazarsın?","answers":{"junior":"`FROM openjdk`, `COPY target/app.jar app.jar`, `ENTRYPOINT java -jar app.jar`. Bellek için `-Xmx` değerini container limitine eşit veririm ki JVM tüm belleği kullanabilsin.","mid":"`openjdk` resmi image'ı artık güncellenmiyor, Temurin gibi bakımı süren bir dağıtım kullanırım. Fat jar'ı tek katman olarak kopyalamak her kod değişikliğinde 100 MB'lık katmanı yeniden üretir; jar'ı katmanlara ayırırım. Spring Boot 3.3'ten beri bunun yolu `jarmode=tools` ve `extract --layers`; daha eski sürümlerde `jarmode=layertools` ve `JarLauncher` ile başlatma vardı. `-Xmx`'i limite eşitlemem, heap dışı bellek de var; `MaxRAMPercentage=70` gibi bir yüzde veririm. Exec form `ENTRYPOINT` ve root olmayan kullanıcı kullanırım.","senior":"Yukarıdakilere ek olarak: taban image'ı sürümle, production'da digest'le sabitlerim; build'de Maven cache mount kullanırım; uygulama dosyalarını root'a ait bırakıp süreci sayısal UID ile çalıştırırım ki uygulama kendi kodunu değiştiremesin ve Kubernetes `runAsNonRoot`'u doğrulayabilsin. `.dockerignore` ile context'i küçültürüm. Ekipte onlarca servis varsa her birine Dockerfile yazdırmak yerine buildpacks ya da Jib ile tek tip image üretmeyi tartışırım: güvenlik yaması ve JVM ayarı tek yerden yönetilir, bedeli image üzerinde daha az kontroldür. Java 25 kullanılıyorsa Spring Boot dokümanındaki AOT cache ile açılış süresini kısaltmayı da değerlendiririm.","interviewer":"Junior cevap kısa bir Dockerfile'a üç sorun sığdırıyor: bakımı bitmiş taban image, shell form `ENTRYPOINT` ve `-Xmx`'in limite eşitlenmesi (OOMKilled'ın klasik nedeni, bkz. Kitap Bölüm 3). Mid cevap üçünü de düzeltiyor ve katmanlı jar'ın sürüm farkını doğru anlatıyor. Senior cevap tedarik zinciri (digest), build hızı (cache mount), çalışma zamanı güvenliği (salt okunur dosyalar, sayısal UID) ve ekip ölçeğinde standartlaşma (buildpacks/Jib) boyutlarını ekliyor.\n\n**Takip sorusu:** Katmanlı jar ile tek fat jar arasındaki farkı registry'ye push süresi ve node'daki pull süresi açısından sayısal olarak nasıl gösterirsin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#15","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Build context, `docker build` komutuna verilen dizindir (genelde `.`); Dockerfile'daki `COPY` sadece bu dizinden dosya alabilir ve context builder'a gönderilir. `.dockerignore`, context'ten hariç tutulacak dosyaları tanımlar. Olmazsa `.git`, `target/`, IDE dosyaları ve `.env` gibi secret dosyaları da gönderilir: build yavaşlar, `COPY . .` cache'i gereksiz yere bozulur ve secret image'a girebilir.","questionMd":"Build context nedir? .dockerignore neden gerekir?","answers":{"junior":"`.dockerignore` sadece build'i biraz hızlandırmak için var, `.gitignore` gibi. Zaten Dockerfile'da hangi dosyaları kopyaladığımı ben seçiyorum, gerek yok.","mid":"Dosyaları tek tek `COPY` ediyorsam image'a girmeyebilirler, ama context yine builder'a gönderilir; `.git` dizini büyükse her build onu taşır. `COPY . .` kullanılıyorsa `.git` ya da `target/` değişikliği cache'i bozar, `.env` dosyası image'a girer. `.dockerignore`'a `.git`, `target/`, `build/`, `.idea`, `.env` eklerim. `.gitignore` ile aynı dosya değil; Docker onu okumaz.","senior":"`.dockerignore`'u güvenlik kontrolü olarak da görürüm: secret içerebilecek dosyalar context'e hiç girmemeli. Çok servisli monorepo'da context'i kökten değil servis dizininden verir, gerekiyorsa her Dockerfile için ayrı ignore dosyası (`Dockerfile.dockerignore`) kullanırım.","interviewer":"Junior cevap context kavramını bilmiyor, `.dockerignore`'u sadece hız optimizasyonu sanıyor. Mid cevap context'in gönderildiğini, cache ve secret etkisini, `.gitignore`'un okunmadığını biliyor. Senior cevap güvenlik açısını ve monorepo düzenini ekliyor.\n\n**Takip sorusu:** Image'ın içinde beklemediğin bir dosya olup olmadığını nasıl kontrol edersin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#16","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Varsayılan olarak container süreci root olarak çalışır ve user namespace kullanılmıyorsa bu, host'taki root ile aynı UID 0'dır. Uygulamada bir açık bulunursa saldırgan container içinde her şeyi yapabilir; bir container kaçış açığıyla birleşince host'u ele geçirebilir. Dockerfile'da bir kullanıcı oluşturup `USER` ile ona geçmek, saldırının etkisini küçültür ve çoğu kurumsal Kubernetes politikası bunu zorunlu tutar.","questionMd":"Container neden root kullanıcıyla çalışmamalı?","answers":{"junior":"Container zaten izole, içinde root olması sorun değil. Root olmazsam dosya izinleriyle uğraşırım, 80 port'unu da dinleyemem.","mid":"İzolasyon bir kernel sınırı ve kernel açıkları oluyor; root olarak çalışan bir süreç bu açıkları kullanmak için en iyi konumdadır. `useradd` ile bir sistem kullanıcısı oluşturup `USER` ile geçerim. Spring Boot 8080'i dinlediği için 1024 altı port sorunu yok. Uygulamanın yazması gereken dizinleri (ör. geçici dosyalar) o kullanıcıya veririm, kodun kendisini değil.","senior":"`USER`'ı sayısal veririm (`USER 10001:10001`), çünkü Kubernetes `runAsNonRoot: true` kontrolü kullanıcı adından UID'yi çözemez. Kubernetes tarafında da `readOnlyRootFilesystem`, `allowPrivilegeEscalation: false` ve capability'leri düşürmeyi eklerim; yazılması gereken yer için `emptyDir` bağlarım. Root olmamak tek başına yetmez, katmanlı savunmanın bir parçasıdır.","interviewer":"Junior cevap container izolasyonunu mutlak sanıyor ve root'un gerekçesi olarak geçerli olmayan nedenler sayıyor (Spring Boot zaten 8080'de). Mid cevap riskin kaynağını, nasıl yapılacağını ve yazılabilir dizin ayrımını biliyor. Senior cevap sayısal UID detayını ve Kubernetes `securityContext` ile katmanlı savunmayı ekliyor.\n\n**Takip sorusu:** Root olmayan kullanıcıyla çalışan uygulama bir volume'a yazmaya çalışınca \"permission denied\" alıyor. Nedeni ne olabilir, nasıl çözersin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#17","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"`depends_on`'un kısa hali sadece başlatma sırasını garanti eder, bağımlılığın hazır olmasını değil. Postgres'e `pg_isready` ile bir `healthcheck` tanımlayıp uygulamada `depends_on: { postgres: { condition: service_healthy } }` kullanırım; compose uygulamayı Postgres sağlıklı olana kadar başlatmaz. Buna ek olarak uygulama da bağlantı hatasına dayanıklı olmalıdır, çünkü bağımlılık sonradan da gidebilir.","questionMd":"Uygulama veritabanından önce açılıp bağlantı hatasıyla çöküyor. depends_on ve healthcheck ile nasıl çözersin?","answers":{"junior":"`depends_on: [postgres]` ekledim ama yine olmuyor. Uygulamanın başına `sleep 20` koyarım, Postgres o sürede açılır.","mid":"`sleep` makineye göre ya fazla ya az gelir. Postgres'e `healthcheck` ekleyip `condition: service_healthy` kullanırım; Redis için `redis-cli ping` yeterli. Healthcheck'te `interval`, `timeout`, `retries` ve ilk açılışa pay bırakan `start_period` veririm. `CMD-SHELL` ile ortam değişkeni kullanacaksam `$$` yazarım ki compose değişkeni kendisi genişletmesin.","senior":"Compose tarafında doğru bekleme bir kolaylıktır, dayanıklılığın yerine geçmez: production'da Kubernetes başlatma sırası garantisi vermez ve veritabanı her an yeniden başlayabilir. Uygulamada Hikari'nin bağlantı havuzu bağlantıyı yeniden kurar; açılışta Flyway gibi zorunlu bir adım varsa readiness'ı ona bağlarım. Uygulamanın kendi healthcheck'ini Dockerfile'a koymam: Kubernetes onu kullanmaz, probe'lar kullanır, ayrıca minimal image'da `curl` olmayabilir. `depends_on` altında `restart: true` ile bağımlılık compose tarafından yeniden başlatıldığında uygulamayı da yeniden başlatmak mümkün.","interviewer":"Junior cevap zamanlamaya dayalı bir çözüm öneriyor; yavaş bir CI makinesinde kırılır. Mid cevap healthcheck ve `service_healthy`'yi parametreleriyle ve `$$` detayıyla doğru kuruyor. Senior cevap compose'daki çözümün production'a taşınmadığını, asıl dayanıklılığın uygulamada olduğunu ve Docker `HEALTHCHECK` ile Kubernetes probe'u arasındaki ilişkiyi biliyor.\n\n**Takip sorusu:** Bir migration servisinin bitmesini bekleyip ondan sonra uygulamayı başlatmak istiyorsun. Hangi `condition`'ı kullanırsın?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#18","category":"Operasyon","label":"Docker ve container'lar","level":"Orta","short":"Multi-stage ile build araçlarını son image'dan çıkarırım, JDK yerine JRE kullanırım, `.dockerignore` ile gereksiz dosyaları dışarıda bırakırım ve aynı `RUN` içinde paket cache'ini temizlerim. Daha ileri gitmek için alpine (musl tabanlı, küçük) ya da distroless (shell ve paket yöneticisi yok) taban image ya da `jlink` ile özel bir runtime kullanırım. Seçim boyut, güvenlik, uyumluluk ve hata ayıklama kolaylığı arasında bir trade-off'tur.","questionMd":"Image boyutunu nasıl küçültürsün? Alpine ve distroless arasında nasıl seçersin?","answers":{"junior":"Alpine kullanırım, en küçük image o. Bir de `RUN rm -rf` ile gereksiz dosyaları sonradan silerim.","mid":"Ayrı bir `RUN` ile silmek boyutu düşürmez: dosya önceki katmanda durur, yeni katman sadece \"silindi\" işareti ekler. Silme aynı `RUN` içinde olmalı ya da multi-stage ile o dosyalar hiç son aşamaya gelmemeli. Alpine küçüktür ama glibc yerine musl kullanır; JNI kullanan bazı kütüphaneler ve native transport'lar sorun çıkarabilir, DNS davranışı da farklıdır. JRE image'ı ve katmanlı jar çoğu durumda yeterli kazancı verir.","senior":"Boyutun üç maliyeti var: pull süresi (soğuk node'da açılış), depolama ve saldırı yüzeyi. Java'da asıl boyut çoğunlukla bağımlılıklardır; katmanlı jar sayesinde onlar nadiren yeniden çekilir, bu yüzden taban image'dan birkaç on MB kazanmak çoğu zaman ikincil kalır. Distroless'ı güvenlik için seçersem hata ayıklamayı önceden tasarlarım: `kubectl debug` ile ephemeral container, JFR ve Actuator heap dump endpoint'i. Kararı bir taramanın CVE sayısı ve ölçülen pull süresiyle veririm, \"en küçük\" sloganıyla değil.","interviewer":"Junior cevap katman modelini bilmiyor: sonradan silmenin image'ı küçültmediğini ve alpine'in uyumluluk bedelini atlıyor. Mid cevap ikisini de düzeltiyor. Senior cevap boyutun neden önemli olduğunu ölçülebilir maliyetlere bağlıyor, Java'da boyutun asıl nerede olduğunu biliyor ve distroless'ın getirdiği teşhis sorununa çözüm sunuyor.\n\n**Takip sorusu:** Bir image'ın hangi katmanının ne kadar yer kapladığını ve neyi içerdiğini nasıl görürsün?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#19","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","short":"`docker stop` PID 1'e SIGTERM gönderir, varsayılan 10 saniye içinde süreç çıkmazsa SIGKILL gönderir. `ENTRYPOINT java -jar app.jar` gibi shell form ya da `exec` kullanmayan bir script ile PID 1 Java değil shell olur; shell sinyali Java'ya iletmez, Java SIGKILL ile ölür ve çıkış kodu 137 olur. Çözüm exec form `ENTRYPOINT`, script'te `exec java ...` ve Spring'in kapanış süresini karşılayan bir stop timeout'tur.","questionMd":"docker stop sonrası uygulama 10 saniye bekleyip ölüyor, graceful shutdown çalışmıyor. Neden?","answers":{"junior":"Spring Boot'ta `server.shutdown=graceful` açık, yani graceful shutdown var. Docker'ın 10 saniyesi az geliyordur, kapanmayı hızlandırmak için uygulamaya `@PreDestroy` eklerim.","mid":"Graceful shutdown ayarı ancak JVM SIGTERM alırsa çalışır. Shell form'da PID 1 `/bin/sh` olur ve shell SIGTERM'i çocuk sürece iletmez; Java hiçbir şey duymaz, 10 saniye sonra SIGKILL gelir, ne shutdown hook ne `@PreDestroy` çalışır. Bunu çıkış kodundan anlarım: SIGTERM ile düzgün kapanan JVM 143, SIGKILL ile ölen 137 döner. Exec form'a geçerim; script gerekiyorsa son satırı `exec java ...` yaparım. Container içinde `ps` ile PID 1'in ne olduğuna bakarak da doğrularım.","senior":"Önce zinciri kurarım: sinyal kime gidiyor (PID 1), PID 1 kim (shell mi Java mı), süre yetiyor mu. Bazı shell'ler `sh -c`'de tek komutu doğrudan exec ederek sorunu tesadüfen önler; buna güvenmem, ortam değişkeni genişletme ya da `&&` zinciri eklenince bozulur. Süre tarafında bir uyumsuzluk var: Spring'in kapanış fazı varsayılan 30 saniye, Docker'ın stop süresi 10 saniye; uzun isteği olan bir serviste `docker stop -t`, compose'da `stop_grace_period`, Kubernetes'te `terminationGracePeriodSeconds` ile hizalarım (preStop dahil, bkz. Kitap Bölüm 15). Uygulama alt süreç başlatıyorsa zombi süreçleri toplamak için `docker run --init` (tini) eklerim; Java tek süreçse buna genelde gerek kalmaz.","interviewer":"Junior cevap sorunu yanlış yerde arıyor: graceful shutdown konfigürasyonu doğru ama sinyal JVM'e hiç ulaşmıyor; `@PreDestroy` eklemek de işe yaramaz çünkü SIGKILL'de hiçbir kod çalışmaz. Mid cevap PID 1 ve shell form mekanizmasını, 137/143 ayrımını ve doğrulama yolunu biliyor. Senior cevap süre uyumsuzluğunu (Spring 30 sn ve Docker 10 sn), shell davranışına güvenmemeyi ve init sürecinin ne zaman gerektiğini ekliyor.\n\n**Takip sorusu:** Kubernetes'te exec form ve graceful shutdown doğru olmasına rağmen deploy sırasında birkaç 502 görüyorsun. Sebep ne olabilir?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#20","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","short":"JDK 10'dan (ve 8u191'den) beri JVM, cgroup üzerinden container'ın bellek limitini okur ve `-Xmx` verilmezse heap'i bu limitin varsayılan %25'i olarak ayarlar. Container'ın toplam belleği (heap + metaspace + thread stack'leri + code cache + direct memory + GC yapıları) limiti aşarsa kernel süreci SIGKILL ile öldürür: çıkış kodu 137 ve `OOMKilled` görülür, Java exception'ı yoktur. Heap'i `-XX:MaxRAMPercentage` ile limitin bir yüzdesi olarak verip heap dışına pay bırakmak gerekir.","questionMd":"JVM container'da bellek limitini nasıl görür? Container neden OOMKilled oluyor?","answers":{"junior":"Container'a `-m 1g` verirsem JVM'e de `-Xmx1g` veririm, böylece belleği tam kullanır. OOM olursa heap dump'a bakarım.","mid":"`-Xmx`'i limite eşitlemek OOMKilled'ı garanti eder, çünkü JVM heap dışında da yüzlerce MB kullanabilir. `MaxRAMPercentage=70` gibi bir yüzde veririm. OOMKilled bir Java `OutOfMemoryError` değildir; kernel süreci öldürür, heap dump alınmaz. `docker inspect` çıktısında `State.OOMKilled` alanı ve 137 çıkış koduyla doğrularım. JVM'in limiti gördüğünü `java -XX:+PrintFlagsFinal -version` ile `MaxHeapSize`'a bakarak kontrol ederim.","senior":"Belleği bir bütçe olarak hesaplarım ve yüzdeyi container boyutuna göre seçerim: küçük container'da heap dışı payı büyüktür. Yük altında NMT ve RSS ile doğrularım. CPU tarafı da önemli: JVM işlemci sayısını CPU limitinden hesaplar ve küçük container'da JDK 27 öncesinde sessizce SerialGC seçebilir; GC'yi açıkça seçip `jcmd VM.flags` ile kontrol ederim. Ayrıntılar için bkz. Kitap Bölüm 3. Image tarafında bu ayarları `JAVA_TOOL_OPTIONS` ile veririm ki ortam başına değiştirilebilsin; buildpacks kullanılıyorsa bellek hesaplayıcısının bunu kendisi yaptığını bilirim.","interviewer":"Junior cevap iki temel yanlışı birleştiriyor: heap'i limite eşitlemek ve OOMKilled'ı heap dump ile incelenebilir sanmak. Mid cevap mekanizmayı, doğru yüzde yaklaşımını ve doğrulama komutlarını biliyor. Senior cevap bütçe düşüncesini, ölçümü ve CPU/GC seçimi gibi aynı kökten gelen ikinci tuzağı ekliyor; konunun derinliği kitapta, burada beklenen mekanizmayı doğru kurmak.\n\n**Takip sorusu:** CPU limiti verilmemiş bir container'da `Runtime.availableProcessors()` ne döner ve bu hangi thread havuzlarını etkiler?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#21","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","short":"`ARG` ve `ENV` ile verilen değerler image metadata'sında ve build geçmişinde kalır; bir dosyayı kopyalayıp sonraki katmanda silmek de işe yaramaz, dosya önceki katmanda durur. Doğru yol BuildKit secret mount'tur: `docker build --secret id=maven,src=$HOME/.m2/settings.xml .` ve Dockerfile'da `RUN --mount=type=secret,id=maven,target=/root/.m2/settings.xml ./mvnw package`. Secret sadece o `RUN` süresince bağlanır, hiçbir katmana yazılmaz. Çalışma zamanı secret'ları ise image'a değil ortama (Kubernetes Secret, Vault) aittir.","questionMd":"Build sırasında özel bir Maven deposuna token gerekiyor. Secret'ı image'a sızdırmadan nasıl verirsin?","answers":{"junior":"Token'ı `ARG MAVEN_TOKEN` ile alırım, CI'da `--build-arg` ile veririm. Image'a girmez çünkü `ENV` değil `ARG` kullandım. Ya da `settings.xml`'i kopyalar, build'den sonra silerim.","mid":"`ARG` değerleri, onları kullanan `RUN` talimatlarıyla birlikte `docker history` çıktısında ve image metadata'sında görünebilir; Docker'ın kendi dokümanı build arg ve env'in secret için uygun olmadığını söyler. Kopyalayıp silmek de katman modelinde işe yaramaz. BuildKit secret mount kullanırım: secret build'e dosya ya da ortam değişkeni olarak sadece ilgili `RUN` için bağlanır. Multi-stage'de token'ı sadece build aşamasında kullanmak da riski azaltır ama build aşamasının cache'i ve katmanları CI makinesinde ya da registry cache'inde kalabilir, bu yüzden tek başına yeterli değil.","senior":"Secret'ları üç zamana ayırırım: build, deploy ve çalışma. Build secret'ı için secret mount, mümkünse kısa ömürlü bir token (CI'ın OIDC kimliğiyle alınan) kullanırım. Image'da secret olup olmadığını CI'da bir secret tarayıcısıyla (ör. Trivy'nin secret taraması) kontrol ederim. Çalışma zamanı secret'ları Kubernetes Secret ya da harici bir secret manager'dan gelir; image ortamdan bağımsız kalır ve aynı image her ortama gider. Sızdığından şüphelendiğim bir token'ı image'ı silerek değil, token'ı iptal ederek kapatırım: image bir kez push edildiyse kimin çektiğini bilemem.","interviewer":"Junior cevaptaki \"ARG image'a girmez\" inancı ve \"kopyala sonra sil\" yaklaşımı gerçek sızıntıların en yaygın iki kaynağıdır. Mid cevap ikisini de düzeltiyor, secret mount'u doğru anlatıyor ve multi-stage'in neden tek başına yetmediğini biliyor. Senior cevap secret'ları yaşam döngüsüne göre ayırıyor, kısa ömürlü token, tarama ve sızıntı sonrası doğru aksiyonu (iptal) ekliyor.\n\n**Takip sorusu:** Bir geliştirici yanlışlıkla `.env` dosyasını içeren bir image'ı public registry'ye push etti. İlk bir saatte ne yaparsın?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#22","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","short":"Docker build ettiği image'ı OCI standardında bir image olarak üretir; container'ı da altta containerd ve runc ile çalıştırır. Kubernetes 1.24'te kaldırılan şey Docker Engine'e bağlanan ara katman (dockershim) oldu; kubelet artık CRI üzerinden doğrudan containerd ya da CRI-O ile konuşur. Image formatı standart olduğu için Docker'la üretilen image her OCI uyumlu runtime'da çalışır.","questionMd":"Kubernetes artık Docker kullanmıyor deniyor. Docker ile build ettiğin image Kubernetes'te nasıl çalışıyor?","answers":{"junior":"Kubernetes Docker'ı bıraktığı için artık Dockerfile kullanamayız, image'ları başka bir araçla üretmemiz gerekiyor.","mid":"Kaldırılan şey Docker'ın runtime olarak kullanılması. Docker Engine'in içinde zaten containerd var, container'ı runc başlatıyor. Kubernetes araya giren Docker katmanını atladı, containerd'yi doğrudan kullanıyor. Image formatı OCI standardı olduğu için build tarafında hiçbir şey değişmiyor; Dockerfile ve `docker build` kullanmaya devam ederim. Değişen, node'da `docker ps` ile container göremem; `crictl` kullanılır.","senior":"Katmanları adlandırarak anlatırım: build aracı (Docker/BuildKit, buildpacks, Jib, Kaniko), image formatı ve dağıtımı (OCI image ve distribution spec, registry), yüksek seviye runtime (containerd, CRI-O), düşük seviye runtime (runc, OCI runtime spec). Standartlar sayesinde bu katmanlar bağımsız değişebiliyor. Pratik etkileri: CI'da Docker daemon'u olmadan image üretmek mümkün; node'da Docker socket'ini pod'lara bağlayan eski CI kurulumları (Docker-in-Docker hileleri) kırıldı; multi-arch image'larda (amd64/arm64) manifest listesi sayesinde node kendi mimarisine uygun image'ı çeker.","interviewer":"Junior cevap \"Docker kaldırıldı\" haberini build tarafına da genelliyor; bu, katmanları ayırt edemediğini gösterir. Mid cevap dockershim, containerd ve OCI ilişkisini doğru kuruyor ve operasyonel farkı (`crictl`) biliyor. Senior cevap tüm zinciri standartlarıyla adlandırıyor ve gerçek etkileri (daemon'suz build, kırılan socket kullanımı, multi-arch) sayıyor.\n\n**Takip sorusu:** Apple Silicon bir Mac'te build ettiğin image amd64 node'larda `exec format error` veriyor. Neden ve nasıl düzeltirsin?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/docker#23","category":"Operasyon","label":"Docker ve container'lar","level":"İleri","short":"CI'da image'ı Trivy, Grype ya da Docker Scout gibi bir araçla tarar, belirli bir önem seviyesinin üstündeki ve düzeltmesi olan açıklarda build'i kırarım. Taban image'ı ve bağımlılıkları sürümle sabitler, düzenli güncellemeyi otomatikleştiririm. Image'a değişmez tag (sürüm ve git SHA) verir, deploy'da digest kullanırım; staging'de test edilen digest'in aynısı production'a gider. SBOM üretip image'ı imzalamak tedarik zincirini izlenebilir yapar.","questionMd":"CI'da image güvenliğini nasıl sağlarsın? Tarama, tag'leme ve tekrarlanabilir build","answers":{"junior":"Image'ı `latest` ile push ederiz, production'da da onu çekeriz. Güvenlik için taban image olarak resmi image kullanmak yeterli.","mid":"Resmi image da açık içerir ve zamanla yeni CVE'ler çıkar; bu yüzden her build'de tarama yaparım ve registry'deki image'ları da periyodik tararım. Tag olarak `1.4.3` ve `1.4.3-` kullanırım, `latest`'i production'da kullanmam. Taramada sadece \"kritik ve düzeltmesi var\" olanlarda build'i kırarım, yoksa ekip sonucu görmezden gelmeye başlar. Image'ı her ortam için yeniden build etmem; aynı image farklı konfigürasyonla deploy edilir.","senior":"Hedefim, production'da çalışan her container için \"bu hangi commit'ten, hangi bağımlılıklarla, kim tarafından üretildi\" sorusuna cevap verebilmek. Bunun için: taban image digest'e sabit ve Renovate/Dependabot ile güncelleniyor; build tekrarlanabilir (sabit taban, kilitli bağımlılık sürümleri, jar'da sabit zaman damgası; buildpacks image oluşturma tarihini sabitleyerek aynı girdiden aynı digest'i üretmeye çalışır); SBOM image'la birlikte saklanıyor ve yeni bir CVE çıktığında hangi servislerin etkilendiğini bulmak için kullanılıyor; image imzalanıyor (ör. cosign) ve küme sadece imzalı, taranmış digest'leri kabul ediyor. Tarama sonucunu bir kapı olarak kullanırken istisna sürecini de tanımlarım; düzeltmesi olmayan bir CVE yüzünden acil bir yamanın bekletilmesi de bir risktir.","interviewer":"Junior cevap \"resmi image güvenlidir\" varsayımına ve `latest`'e dayanıyor; ne hangi kodun çalıştığı ne de açıkların ne zaman ortaya çıktığı izlenebilir. Mid cevap taramayı, değişmez tag'leri, gürültü yönetimini ve build once deploy many'yi doğru kuruyor. Senior cevap konuyu izlenebilirlik hedefine bağlıyor: digest, tekrarlanabilir build, SBOM, imza ve küme tarafında politika; tarama kapısının istisna ihtiyacını da görüyor.\n\n**Takip sorusu:** Log4Shell gibi bir açık bugün duyuruldu. Elinde 40 servis var. Hangilerinin etkilendiğini bir saat içinde nasıl bulursun?"},"href":"/sorular/docker/"},{"kind":"open","id":"sorular/git#1","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"Git dağıtık bir sürüm kontrol sistemidir: her clone, tüm geçmişi ve nesneleri içeren tam bir repository'dir. Merkezi sistemlerde (SVN) geçmiş sunucudadır, commit sunucuya yazmak demektir ve sunucu olmadan log, diff, branch gibi işlemler yapılamaz. Git'te commit, branch, merge, log tamamen yereldir ve hızlıdır; paylaşım `push`/`fetch` ile ayrı bir adımdır. Ayrıca Git branch'i ucuz bir işaretçi olarak modellediği için branch'li çalışma doğal hale gelir.","questionMd":"Git nedir ve SVN gibi merkezi sürüm kontrol sistemlerinden farkı nedir?","answers":{"junior":"Git bir versiyon kontrol sistemi, kodu GitHub'a yüklemek için kullanıyoruz. SVN eski bir sistem, Git daha yeni ve daha hızlı. Git'te commit atıp push ediyoruz.","mid":"Git dağıtık bir sistem; clone'ladığımda geçmişin tamamı bende oluyor. Bu yüzden commit, log, branch, diff gibi işlemler ağ olmadan çalışıyor. SVN'de merkezi bir sunucu var ve commit doğrudan oraya gidiyor. Git'te commit yereldir, push ile paylaşırım. GitHub ise Git'in kendisi değil, Git repository'lerini barındıran ve PR, review gibi özellikler ekleyen bir platform.","senior":"Git dağıtık bir içerik deposu: her clone tam bir repository, yani tüm nesneler ve geçmiş yerelde. Commit yerel bir işlem; paylaşmak `push`/`fetch` ile ayrı ve bilinçli bir adım. Bunun sonuçları: çevrimdışı çalışma, hızlı log/diff/blame, ucuz branch (sadece bir işaretçi) ve her clone'un doğal bir yedek olması. Merkezi modelde sunucu tek doğru kaynak ve tek hata noktası. Pratikte biz de GitHub/GitLab'ı \"merkez\" gibi kullanıyoruz, ama bu teknik bir zorunluluk değil, iş akışı kararı.","interviewer":"Junior'ın tipik yanlışı Git ile GitHub'ı aynı şey sanmak ve farkı \"daha yeni, daha hızlı\" diye geçiştirmek. Duymak istenen anahtar kavram: her clone tam bir repository, commit yerel bir işlem, paylaşım ayrı bir adım. Mid bunu ve Git/GitHub ayrımını veriyor; senior sonuçlarını (çevrimdışı, ucuz branch, her clone bir yedek) ve \"merkez\"in bir iş akışı tercihi olduğunu ekliyor.\n\n**Takip sorusu:** GitHub bir gün erişilemez olsa ekip olarak ne kaybedersiniz, neyi kaybetmezsiniz?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#2","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"Working tree diskte düzenlediğin dosyalar, index (staging area) bir sonraki commit'in taslağı, repository ise commit'lenmiş nesnelerdir. `git add` değişikliği index'e alır, `git commit` index'in o anki halinden bir snapshot üretip geçmişe ekler. Staging sayesinde aynı dosyadaki değişikliklerin sadece bir kısmını (`git add -p`) commit'leyip atomik commit'ler kurabilirsin.","questionMd":"Working tree, staging area (index) ve repository nedir; commit ne yapar?","answers":{"junior":"Değişiklik yapınca `git add .` ile ekliyorum, sonra `git commit` ile kaydediyorum. Staging bir ara adım, aslında pek gerek yok, IDE'de direkt commit ediyorum. Commit, değişikliklerin (diff'in) kaydedilmesidir.","mid":"Üç alan var: working tree, index ve repository. `git add` dosyanın o anki içeriğini index'e koyar; sonra dosyayı tekrar değiştirirsem bu yeni değişiklik `git add` yapana kadar commit'e girmez. `git status` iki farkı gösterir: index ile HEAD arası (staged) ve working tree ile index arası (unstaged). Staging'i, bir dosyada iki farklı iş yaptıysam `git add -p` ile ayırıp iki ayrı commit atmak için kullanırım.","senior":"Index bir sonraki commit'in tree'sinin taslağı; `git add` içeriği blob olarak yazar ve index'e kaydeder, commit bu index'ten bir tree üretip parent'a bağlar. Commit kavramsal olarak diff değil tam snapshot'tır; diff iki snapshot karşılaştırılarak hesaplanır. Staging'i atomik commit için kullanırım: refactor ile davranış değişikliğini `add -p` ile ayırırım (bkz. Kitap Bölüm 20).","interviewer":"Junior iki yaygın yanlış yapıyor: staging'i gereksiz görmek ve commit'i \"diff kaydı\" sanmak. Git her commit'te tüm projenin tree'sini işaret eder; diff, iki snapshot'tan türetilir (diskte delta sıkıştırma bir depolama ayrıntısıdır). Staging'in değeri `add -p` ile atomik commit kurabilmektir. Mid bunu ve \"add'den sonra yapılan değişiklik commit'e girmez\" inceliğini biliyor.\n\n**Takip sorusu:** `git add Foo.java` yaptıktan sonra dosyayı tekrar değiştirip `git commit` dersen commit'e hangi hali girer? `git diff` ile `git diff --staged` neyi gösterir?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#3","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"Branch, bir commit'e işaret eden hareketli bir isimdir; `.git/refs/heads/` altında tek bir hash tutan küçük bir dosyadır. Branch açmak dosyaları kopyalamaz, sadece yeni bir işaretçi oluşturur; bu yüzden anlıktır. Aktif branch'te commit attığında işaretçi yeni commit'e ilerler. HEAD ise hangi branch'te olduğunu gösteren işaretçidir.","questionMd":"Branch nedir? Git'te branch açmak neden ucuzdur?","answers":{"junior":"Branch, kodun bir kopyası. `main`'den bir branch açınca kodun ayrı bir kopyası oluşuyor, orada çalışıp sonra main'e merge ediyorum.","mid":"Branch kopya değil, bir commit'e işaret eden pointer. `git switch -c feature/x` dediğimde mevcut commit'e işaret eden yeni bir ref oluşur, HEAD de ona işaret eder. Yeni commit attığımda `feature/x` ilerler, `main` olduğu yerde kalır. Branch silmek de sadece işaretçiyi silmektir; commit'ler başka bir yerden ulaşılabiliyorsa durmaya devam eder.","senior":"Branch 41 baytlık bir dosya: bir commit hash'i. HEAD normalde branch'e işaret eden sembolik ref; commit attığımda HEAD'in gösterdiği branch ilerler. Bu modelden üç sonuç çıkar: branch açmak ve silmek O(1), \"branch'in içeriği\" aslında o commit'ten parent'lara doğru ulaşılabilen geçmiştir, ve silinen bir branch'in commit'leri reflog'dan bulunabilir.","interviewer":"Junior'ın yanlışı branch'i \"kodun kopyası\" sanmak; bu yanlış model rebase, reset ve reflog'u anlamayı imkansız kılar. Doğru model: branch bir commit'e işaret eden hareketli bir isimdir, commit'ler ise parent zinciriyle birbirine bağlıdır. Mid HEAD ile branch ilişkisini doğru kuruyor; senior modelden pratik sonuçlar çıkarıyor.\n\n**Takip sorusu:** `git branch -d feature/x` ile branch'i sildin. Commit'lerine ne olur, onları nasıl geri getirirsin?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#4","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"`git fetch` remote'taki yeni commit'leri indirir ve sadece `origin/main` gibi remote-tracking ref'leri günceller; senin branch'ine ve dosyalarına dokunmaz. `git pull` ise `fetch` + entegrasyondur: indirdiği değişikliği aktif branch'ine merge eder (ya da yapılandırmaya göre rebase eder). Önce `fetch` edip `git log main..origin/main` ile gelenleri görmek daha kontrollüdür.","questionMd":"git fetch ile git pull arasındaki fark nedir?","answers":{"junior":"Fetch değişiklikleri kontrol ediyor, pull ise indiriyor. Ben hep pull kullanıyorum, fetch'e gerek kalmıyor.","mid":"Fetch de indirir; fark entegrasyonda. Fetch sadece `origin/*` ref'lerini günceller, benim `main`'im yerinde kalır. Pull ise fetch'ten sonra merge yapar. Yerelde commit'im varsa ve remote da ilerlediyse bu bir merge commit üretir ya da güncel Git'te yapılandırma yoksa \"divergent branches\" hatasıyla durur. Ben `pull.rebase true` kullanıyorum; yerel commit'lerim remote'un üzerine taşınıyor ve gereksiz merge commit'leri oluşmuyor.","senior":"Fetch güvenli ve yan etkisizdir, pull ise iki adımı birleştiren bir kısayol. Ayrışma varsa merge mi rebase mi yapılacağı bir ekip kararıdır; bunu `pull.rebase` ya da `pull.ff only` ile açık yaparım. Rebase ederken conflict çıkarsa sırada kendi commit'lerim olduğunu bilirim.","interviewer":"Junior'ın yanlışı \"fetch sadece kontrol eder, indirmez\" demek. Fetch nesneleri gerçekten indirir; fark, yerel branch'e ve working tree'ye dokunmamasıdır. Mid divergent branch durumunu ve `pull --rebase` tercihini anlatıyor; bu, gündelik kullanımda \"Merge branch 'main' of ...\" kirliliğini neden gördüğümüzü açıklar.\n\n**Takip sorusu:** `git status` \"ahead 2, behind 3\" diyor. Bu ne demek ve `git pull` ile `git pull --rebase` geçmişi nasıl farklı bırakır?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#5","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"İki branch aynı dosyanın aynı bölgesini farklı şekilde değiştirdiyse Git hangisinin doğru olduğuna karar veremez ve conflict verir. Dosyaya `<<<<<<<`, `=======`, `>>>>>>>` işaretleri koyar; işaretleri kaldırıp doğru birleşik hali yazarsın, derleyip testleri çalıştırırsın, `git add` ile çözüldü olarak işaretleyip merge'ü `git commit` (rebase'de `git rebase --continue`) ile bitirirsin. Emin değilsen `git merge --abort` ile başa dönersin.","questionMd":"Merge conflict nedir ve nasıl çözülür?","answers":{"junior":"Conflict çıkınca IDE'de \"accept mine\" ya da \"accept theirs\" diyorum, hangisi doğruysa onu seçiyorum. Sonra commit edip push ediyorum.","mid":"Önce `git status` ile hangi dosyaların conflict'te olduğuna bakarım. Her conflict için iki tarafın niyetini anlarım: biri timeout'u değiştirdi, diğeri yeni parametre ekledi gibi. Çoğu zaman doğru cevap ikisinin birleşimidir, birini seçmek değil. Çözdükten sonra derleyip testleri çalıştırırım, çünkü metin olarak çakışmayan değişiklikler de semantik olarak çakışabilir. Sonra `git add` ve `git commit`.","senior":"`merge.conflictStyle=zdiff3` açarım; ortak atanın halini de gördüğüm için hangi tarafın neyi değiştirdiği netleşir. Çözümü \"taraf seçmek\" değil iki niyeti birleştirmek olarak ele alırım ve mutlaka build + test koşarım. Rebase sırasında `--ours` ve `--theirs`'ün yer değiştirdiğini bilirim: \"ours\" üzerine taşındığım taban, \"theirs\" benim commit'imdir. Conflict sıklığı küçük, kısa ömürlü branch'lerle azalır.","interviewer":"Junior'ın yanlışı conflict'i \"hangisi doğru, onu seç\" diye çözmek ve çözdükten sonra test etmeden push etmek; bu, diğer tarafın değişikliğini sessizce kaybetmenin en yaygın yolu. Duyulması gerekenler: iki tarafın niyetini anlamak, çoğu zaman birleştirmek, ve conflict olmayan semantik çakışmalar için derleyip test koşmak. Senior'ın `zdiff3` ve rebase'de ours/theirs inceliği gündelik kullanımda gerçek fark yaratır.\n\n**Takip sorusu:** Merge'te hiç conflict çıkmadı ama main kırıldı. Bu nasıl olabilir?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#6","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"`git commit --amend -m \"yeni mesaj\"` son commit'in mesajını değiştirir; unuttuğun dosyayı önce `git add` edip `git commit --amend --no-edit` dersen içeriğe eklenir. Amend mevcut commit'i değiştirmez, onun yerine yeni hash'li yeni bir commit üretir. Commit henüz push edilmediyse sorun yok; push edildiyse remote'u güncellemek force push gerektirir, ortak branch'te bunu yapmazsın.","questionMd":"Son commit'in mesajını ya da içeriğini nasıl değiştirirsin?","answers":{"junior":"`git commit --amend` ile değiştiriyorum, sonra push ediyorum. Push hata verirse `git push -f` yapıyorum.","mid":"Amend son commit'i yeniden yazar: yeni bir commit oluşur, branch ona işaret eder, eski commit reflog'da kalır. Push etmediysem rahatça kullanırım. Kendi feature branch'imde push ettiysem ve kimse üzerine çalışmıyorsa `--force-with-lease` ile güncellerim. `main` gibi paylaşılan bir branch'te push edilmiş commit'i amend etmem; mesaj hatalıysa öyle kalır ya da düzeltme yeni commit'le gelir.","senior":"Amend, tek commit'lik bir rebase'dir: yeni SHA, eski commit reflog'da. Kural geçmişi yeniden yazan tüm komutlarla aynı: paylaşılmamışsa serbest, kendi PR branch'imde `--force-with-lease`, paylaşılan branch'te asla. Daha eski bir commit'i düzeltmem gerekiyorsa `--fixup` + `rebase -i --autosquash` kullanırım.","interviewer":"Junior'ın yanlışı amend'i \"commit'i yerinde düzeltmek\" sanması ve push reddedilince refleks olarak `-f` kullanması. Amend yeni bir commit üretir; push edilmiş bir commit için bu geçmişi yeniden yazmak demektir. Duyulması gereken ayrım: kendi branch'im (`--force-with-lease` kabul edilebilir) ile paylaşılan branch (yeniden yazılmaz).\n\n**Takip sorusu:** Son commit'i değil, üç commit önceki bir commit'in içeriğini düzeltmen gerekiyor. Nasıl yaparsın?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#7","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"`git stash` commit'lenmemiş değişiklikleri (staged ve unstaged) bir yığına kaldırır ve working tree'yi temiz hale getirir; `git stash pop` geri uygular ve kaydı siler, `apply` kaydı tutar. Acil bir hotfix için branch değiştirmen gerektiğinde ya da pull öncesi işini geçici olarak kenara almak için kullanılır. İzlenmeyen (yeni) dosyalar varsayılan olarak stash'lenmez; `-u` gerekir.","questionMd":"git stash ne işe yarar, ne zaman kullanırsın?","answers":{"junior":"Değişikliklerimi kaydetmeden başka branch'e geçmek istediğimde `git stash` yapıyorum, her şeyi saklıyor. Sonra `git stash pop` ile geri alıyorum.","mid":"Stash geçici bir rafa kaldırma. Dikkat ettiğim iki şey: yeni oluşturduğum dosyalar `-u` olmadan stash'e girmez, working tree'de kalır; ve `pop` sırasında conflict çıkarsa stash kaydı silinmez, çözüp `git stash drop` yapmam gerekir. Uzun süreli işler için stash yerine WIP commit'i tercih ederim; stash'ler birikip unutuluyor. `git stash push -m \"açıklama\"` ile isim veririm.","senior":"Stash'i dakikalar mertebesindeki kesintiler için kullanırım; daha uzunsa bir branch'e WIP commit atarım, çünkü commit görünür, push edilebilir ve yedeklenir. Paralel iki işi sürekli taşıyorsam `git worktree` daha iyi çözüm.","interviewer":"Junior'ın yanlışı stash'in \"her şeyi\" sakladığını düşünmek. İzlenmeyen dosyalar `-u` olmadan stash'e girmez ve diğer branch'e taşınır; bu da şaşırtıcı hatalara yol açar. Mid bunu ve pop'ta conflict olunca kaydın kaldığını biliyor; senior stash'in uzun süreli saklama aracı olmadığını vurguluyor.\n\n**Takip sorusu:** Yanlışlıkla `git stash drop` ile bir stash'i sildin. Geri getirmek mümkün mü?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#8","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"`.gitignore` içindeki desenler Git'in **izlenmeyen** dosyaları `git status`'ta göstermemesini ve `git add .` ile eklememesini sağlar. Zaten takip edilen bir dosya ignore'a eklense bile takip edilmeye devam eder. Takipten çıkarmak için `git rm --cached ` ile index'ten silip commit atarsın; dosya diskte kalır. Java projesinde `target/`, `build/`, `*.log`, `.idea/`, `.env` gibi dosyalar ignore edilir.","questionMd":".gitignore nasıl çalışır? Daha önce commit'lenmiş bir dosyayı neden ignore etmiyor?","answers":{"junior":"`.gitignore`'a yazdığım dosyalar Git'e gitmez. `application.log` dosyasını ekledim ama hâlâ değişiklik olarak görünüyor, sanırım bir hata var.","mid":"Ignore sadece izlenmeyen dosyalar için geçerli. Log dosyası önceden commit'lenmişse Git onu izlemeye devam eder. `git rm --cached application.log` yapıp commit atarım, artık ignore kuralı devreye girer. Neden bir dosyanın ignore edildiğini görmek için `git check-ignore -v ` kullanırım. Proje kuralları repodaki `.gitignore`'a, IDE ve işletim sistemine özel olanlar global ignore'a (`core.excludesFile`) gider.","senior":"Ignore bir \"eklenmesin\" filtresidir, bir \"silinsin\" kuralı değil. Takipten çıkarmak geçmişteki kopyaları silmez; dosya secret içeriyorsa sorun ignore ile çözülmez, rotate ve geçmiş temizliği gerekir. Repo seviyesinde sadece projeye ait kurallar, kişisel IDE dosyaları global ignore'da.","interviewer":"Junior'ın yanlışı ignore'un takip edilen dosyaları da etkilediğini sanmak. Ignore yalnızca izlenmeyen dosyalara uygulanır; takip edilen dosya `git rm --cached` ile çıkarılmalıdır. Senior'ın kritik eklemesi: ignore'a eklemek geçmişteki secret'ı silmez.\n\n**Takip sorusu:** `.env` dosyası altı ay önce commit'lenmiş ve içinde veritabanı şifresi var. `.gitignore`'a eklemek yeterli mi? Ne yaparsın?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#9","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"Tag, belirli bir commit'e verilen ve branch gibi ilerlemeyen bir isimdir; genelde sürümleri işaretlemek için kullanılır (`v1.4.0`). Lightweight tag sadece bir ref'tir; annotated tag (`git tag -a v1.4.0 -m \"...\"`) ise kendi nesnesi olan, tag'leyeni, tarihi, mesajı ve isteğe bağlı imzayı taşıyan bir tag'dir. Sürümler için annotated tag tercih edilir. `git push` tag'leri varsayılan olarak göndermez; `git push origin v1.4.0` ya da `--follow-tags` gerekir.","questionMd":"Tag nedir? Lightweight ve annotated tag farkı nedir?","answers":{"junior":"Tag, release'i işaretlemek için kullanılan bir şey, branch gibi. `git tag v1.0` yapıp push ediyorum.","mid":"Tag bir commit'e sabit bir isim; branch'ten farkı ilerlememesi. Annotated tag bir nesne olarak saklanır ve kim, ne zaman, neden bilgisini taşır; release için onu kullanırım. `git push` tek başına tag göndermediği için CI'da sürüm tag'i göremeyip şaşırabiliriz; `git push origin v1.4.0` ya da `push.followTags` kullanırım. Yayınlanmış bir tag'i taşımam; yanlışsa yeni sürüm numarası veririm.","senior":"Release'i tag'den üretirim: CI annotated tag'i görünce artefaktı build eder ve sürümü tag'den alır. Yayınlanmış tag'i yeniden yazmam, çünkü başkalarının clone'unda eski hali kalır ve aynı isim iki farklı commit'i gösterir; düzeltme yeni bir patch sürümüdür.","interviewer":"Junior'ın yanlışı tag'i \"branch gibi\" görmek ve `git push`'un tag'i de gönderdiğini varsaymak. Tag ilerlemez ve push'a otomatik dahil olmaz. Mid annotated/lightweight farkını ve push davranışını biliyor; senior yayınlanmış tag'in değiştirilmemesi gerektiğini ve CI ile ilişkisini kuruyor.\n\n**Takip sorusu:** `v2.3.0` tag'ini yanlış commit'e attın ve push ettin; CI bir artefakt yayınladı bile. Ne yaparsın?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#10","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Başlangıç","short":"Atomik commit tek bir mantıksal değişiklik içerir, kendi başına derlenir ve testleri geçer; böylece tek başına revert ya da cherry-pick edilebilir ve `git bisect` çalışır. İyi mesajın kısa bir başlığı (yaklaşık 50 karakter, emir kipinde) ve gerekiyorsa boş satırdan sonra \"neden\"i anlatan bir gövdesi olur; \"ne\" zaten diff'te görünür. Conventional Commits formatı (`fix(payment): ...`, `feat: ...`) otomatik changelog ve semver üretimini besler (bkz. Kitap Bölüm 20).","questionMd":"İyi bir commit mesajı nasıl yazılır, atomik commit nedir?","answers":{"junior":"Mesaja ne yaptığımı yazıyorum: \"fix\", \"update\", \"changes\". Gün sonunda tüm değişiklikleri tek commit'te atıyorum, daha düzenli oluyor.","mid":"Her commit tek bir iş yapar: refactor ayrı, davranış değişikliği ayrı. Mesajda `fix(transfer): reject negative amount` gibi bir başlık ve gövdede neden yazarım: \"Negatif tutar validasyondan geçiyordu ve ters yönlü transfer oluşturuyordu.\" Ticket referansını footer'a eklerim (`Refs: ACC-142`). Her commit'in derlendiğinden emin olurum.","senior":"Commit, gelecekteki okuyucuya (altı ay sonraki `git blame`'e) yazılan bir nottur; mesaj \"neden\"i, alternatifleri ve bilinen sınırlamayı anlatır. Atomiklik ve yeşil commit bisect ve revert'ü mümkün kılar. Squash merge kullanan ekiplerde asıl kayıt PR başlığı ve açıklamasıdır; o yüzden onu da aynı özenle yazarım (bkz. Kitap Bölüm 20).","interviewer":"Junior'ın yanlışı \"fix/update\" gibi bilgi taşımayan mesajlar ve gün sonu dev commit. Bu geçmişi okunamaz yapar, kısmi geri almayı ve bisect'i imkansızlaştırır. Duyulması gerekenler: tek mantıksal değişiklik, her commit yeşil, mesajda \"neden\". Senior squash merge bağlamında PR başlığının önemini ekliyor.\n\n**Takip sorusu:** Bir commit'te hem bir refactor hem bir bug fix yaptın ve henüz push etmedin. Bunu iki commit'e nasıl bölersin?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#11","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"Merge iki geçmişi birleştirir: hedef branch ataysa fast-forward ile işaretçiyi ilerletir, ayrışma varsa ortak ata üzerinden three-way merge yapıp iki parent'lı bir merge commit üretir; mevcut commit'ler değişmez. Rebase ise commit'lerini yeni tabanın üzerine tek tek yeniden uygular, yeni SHA'lı commit'ler üretir ve doğrusal geçmiş bırakır. Kural: paylaşılmamış, kendi branch'imi güncellerken rebase; paylaşılmış geçmişi birleştirirken merge. Başkalarının üzerine iş kurduğu commit'leri rebase etmem.","questionMd":"Merge ile rebase arasındaki fark nedir? Ne zaman hangisini kullanırsın?","answers":{"junior":"Rebase daha temiz geçmiş verdiği için daha iyi, merge eski yöntem. Rebase commit'leri taşıyor, merge birleştiriyor. Her zaman rebase kullanıyorum.","mid":"Merge geçmişi olduğu gibi korur ve ayrışma varsa bir merge commit ekler. Rebase benim commit'lerimi `main`'in ucuna yeniden uygular; geçmiş doğrusal olur ama commit'lerin hash'i değişir, yani geçmiş yeniden yazılır. Feature branch'imi güncel `main`'e taşımak için rebase kullanırım; ama branch'i başka biri de kullanıyorsa rebase etmem, çünkü onun elindeki commit'ler artık benimkilerle aynı değil. Rebase'de conflict her commit için ayrı ayrı çıkabilir.","senior":"Teknik fark: merge yeni bir commit ekler ve hiçbir şeyi yeniden yazmaz; rebase commit'leri kopyalar, eskileri reflog'da kalır. Bu yüzden rebase \"yerel düzenleme\" aracıdır: PR'ı açmadan önce ya da kendi branch'imi güncellerken. Paylaşılan geçmişte merge. Geçmiş tercihini ekip kararına bağlarım: doğrusal geçmiş istiyorsak PR'lar squash ya da rebase merge ile girer ve `git log --first-parent main` zaten okunabilir. Merge commit'in avantajı: bir özelliği tek commit'le (`revert -m 1`) geri alabilmek ve entegrasyon anını görebilmek. Rebase'in bir bedeli daha var: yeniden uygulanan ara commit'ler hiç test edilmemiş kombinasyonlardır; ara commit'ler bisect için önemliyse `git rebase -x \"./mvnw -q test\"` ile her adımı test ederim.","interviewer":"Junior'ın yanlışı rebase'i \"daha iyi merge\" sanmak ve geçmişi yeniden yazdığını görmemek. Doğru cevap bir değer yargısı değil, bir mekanizma ve kural: rebase yeni SHA'lar üretir, paylaşılmış geçmişte kullanılmaz. Mid kuralı ve nedenini veriyor. Senior bunun ötesinde ara commit'lerin test edilmemiş olabileceğini, `--first-parent` ile okunabilirliği ve merge commit'in geri alma avantajını tartışıyor.\n\n**Takip sorusu:** Arkadaşın, senin rebase edip force push ettiğin branch'ten daha önce kendi branch'ini açmıştı. Onun tarafında ne olur, nasıl düzeltir?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#12","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"`git reset ` aktif branch'i o commit'e taşır: `--soft` sadece branch'i taşır (değişiklikler staged kalır), `--mixed` (varsayılan) index'i de sıfırlar (değişiklikler unstaged kalır), `--hard` working tree'yi de sıfırlar ve commit'lenmemiş değişiklikleri siler. `git revert ` ise geçmişi değiştirmez, o commit'in tersini uygulayan yeni bir commit ekler. Reset geçmişi yeniden yazdığı için yerel işte, revert paylaşılmış branch'te kullanılır. Dosya düzeyinde geri alma için `git restore` kullanılır.","questionMd":"git reset --soft, --mixed, --hard ve git revert arasındaki fark nedir?","answers":{"junior":"Reset commit'i siler, revert de geri alır, ikisi aynı şey. `--hard` en temiz olanı, ben genelde onu kullanıyorum.","mid":"Reset branch'i geriye taşır; modu index ve working tree'ye ne olacağını belirler. Son üç commit'i tek commit'te toplamak için `git reset --soft HEAD~3` yapıp tekrar commit atarım. Commit'i geri alıp değişiklikleri yeniden düzenlemek istersem `--mixed`. `--hard`'ı sadece değişiklikleri gerçekten atmak istediğimde kullanırım, çünkü commit'lenmemiş iş geri gelmez. Push edilmiş commit'i geri almak için revert: yeni bir commit ekler, kimsenin geçmişi bozulmaz.","senior":"Üç ağaç modeliyle düşünürüm: HEAD (branch), index, working tree. `--soft` sadece birincisini, `--mixed` ilk ikisini, `--hard` üçünü de hedef commit'e eşitler. Reset sonrası eski uç `ORIG_HEAD`'de ve reflog'da durur; yani commit'lenmiş iş reset ile kaybolmaz, ama `--hard` ile silinen commit'lenmemiş değişiklik reflog'da yoktur (sadece daha önce `git add` edilmişse `git fsck --lost-found` ile blob olarak bulunabilir). `--hard` öncesi `git stash` ya da `git reset --keep` daha güvenli. Revert geçmişe ekleme yapar; merge commit'te `-m 1` ister ve revert edilen merge'ü tekrar merge etmek \"Already up to date\" der, çünkü commit'ler zaten geçmiştedir; özelliği geri getirmek için revert'ü revert ederim. `restore` dosya düzeyinde: `git restore --staged` unstage eder, `git restore ` working tree değişikliğini atar.","interviewer":"Junior iki yanlış yapıyor: reset ile revert'ü aynı sanmak ve `--hard`'ı varsayılan araç olarak kullanmak. Fark geçmişin yeniden yazılıp yazılmaması; `--hard` ise geri gelmeyen tek veri kaybı noktası (commit'lenmemiş değişiklikler). Mid modları ve kullanım yerlerini doğru veriyor. Senior üç ağaç modeli, `ORIG_HEAD`, merge revert'ünün `-m` gereksinimi ve \"revert'ü revert\" tuzağıyla gerçek deneyim gösteriyor.\n\n**Takip sorusu:** `git reset --hard HEAD~2` yaptın ve yanlış olduğunu fark ettin. Commit'leri nasıl geri getirirsin? Commit'lenmemiş değişikliklerin de vardıysa onlar geri gelir mi?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#13","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"Push etmediysem: doğru branch yoksa `git branch feature/x` ile mevcut commit'te yeni branch açar, `main`'i `git reset --hard HEAD~1` ile geri alır (working tree temizse), `git switch feature/x` ile devam ederim. Doğru branch zaten varsa `git switch feature/x`, `git cherry-pick `, sonra `main`'e dönüp reset. Push ettiysem ve branch paylaşılansa reset değil `git revert` kullanırım.","questionMd":"Yanlış branch'e commit attım. Ne yaparım?","answers":{"junior":"Commit'i silip doğru branch'te değişiklikleri tekrar elle yapıyorum. Ya da `main`'e push edip sonra düzeltiyorum.","mid":"Commit'i kaybetmeden taşırım. `main`'e iki commit attıysam ve push etmediysem:\n\n```bash\ngit branch feature/ACC-142 # commit'leri tutan yeni branch\ngit reset --hard origin/main # main'i remote'taki haline döndür\ngit switch feature/ACC-142\n```\n\nBranch zaten varsa `git cherry-pick` ile commit'leri oraya alır, sonra `main`'de reset yaparım. `--hard` öncesi `git status` temiz mi bakarım.","senior":"Önce durumu sınıflandırırım: push edildi mi, başkası çekti mi? Edilmediyse sorun sadece işaretçilerin yeri: commit'ler doğru branch'e \"isimlendirilir\" (`git branch`) ve yanlış branch geri alınır; `origin/main`'e reset, kaç commit attığımı saymaktan güvenli. Paylaşılan branch'e push edildiyse revert ve doğru branch'te cherry-pick; geçmişi yeniden yazmam. Tekrarlamaması için `main`'e doğrudan push'u branch protection ile kapatırım.","interviewer":"Junior'ın yanlışı değişiklikleri elle tekrar yazmak ya da hatayı `main`'e push edip \"sonra düzeltmek\". Git'te commit'ler zaten var; sadece işaretçilerin yeri yanlış. Mid bunu `branch` + `reset` ile ve `origin/main` referansıyla doğru çözüyor. Senior push edilmiş/edilmemiş ayrımını ve süreç düzeltmesini (branch protection) ekliyor.\n\n**Takip sorusu:** `reset --hard`'dan önce commit'lenmemiş değişikliklerin de olsaydı ne olurdu? Daha güvenli bir yol var mı?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#14","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"`git revert ` ile commit'in tersini uygulayan yeni bir commit oluşturup normal şekilde push ederim. Reset + force push paylaşılan geçmişi yeniden yazar: başkalarının clone'unda eski commit'ler kalır, bir sonraki pull'da geri gelir ya da onların işi ezilir; ayrıca korumalı branch'lerde zaten engellidir. Revert geçmişi koruyarak \"neyi neden geri aldık\" bilgisini de kaydeder.","questionMd":"Push edilmiş bir commit'i nasıl geri alırsın? Neden reset + force push değil?","answers":{"junior":"`git reset --hard HEAD~1` yapıp `git push --force` ile remote'u düzeltirim, böylece hatalı commit geçmişte hiç görünmez.","mid":"Revert kullanırım: `git revert abc123` yeni bir commit oluşturur, push ederim, kimsenin geçmişi bozulmaz. Reset + force push yaparsam o commit'i çekmiş olan herkesin elindeki geçmiş remote'tan ayrışır; pull ettiklerinde commit merge ile geri gelebilir. Merge commit'ini geri alıyorsam `git revert -m 1 `; birden fazla commit için `git revert --no-commit A^..B` ile tek revert commit'i atarım.","senior":"Paylaşılan geçmiş bir sözleşmedir; revert onu korur, reset + force onu bozar. Revert'ün takip etmem gereken bir tuzağı var: merge'ü revert ettikten sonra düzeltilmiş branch'i tekrar merge etmek değişiklikleri getirmez, çünkü Git o commit'leri zaten birleştirilmiş sayar; önce revert commit'ini revert ederim, sonra düzeltmeyi eklerim. Production'da hatalı deploy'u geri almak genelde git'ten değil deploy aracından (önceki image'a rollback) yapılır; revert kalıcı düzeltmedir. Geçmişi gerçekten temizlemem gereken tek durum sızan bir secret ya da büyük binary'dir; o da koordineli yapılır.","interviewer":"Junior'ın yanlışı paylaşılan branch'te reset + force push ile \"temiz geçmiş\" hedeflemek; bu, takım arkadaşlarının işini kaybettirebilir ve CI/deploy geçmişini anlamsız hale getirir. Duyulması gereken: revert yeni bir commit ekler, geçmişi korur. Senior'ın \"revert'ü revert\" ve deploy rollback ile git revert ayrımı, gerçek production deneyimi sinyalidir.\n\n**Takip sorusu:** PR'ı merge ettin, revert ettin, bug'ı aynı branch'te düzelttin ve tekrar PR açtın. Merge sonrası değişikliklerin yarısı yok. Neden?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#15","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"`git cherry-pick ` başka bir branch'teki tek bir commit'in değişikliğini aktif branch'e yeni bir commit olarak uygular. Tipik kullanım: `main`'deki bir hotfix'i bir release branch'ine taşımak ya da yanlış branch'e atılmış commit'i doğru yere almak. Yeni commit farklı bir SHA'ya sahiptir; aynı değişiklik geçmişte iki kez görünür. Bağımlı olduğu önceki commit'ler yoksa conflict ya da derlenmeyen kod çıkabilir.","questionMd":"cherry-pick ne zaman kullanılır, riskleri nelerdir?","answers":{"junior":"Cherry-pick bir commit'i başka branch'e kopyalıyor. Bir branch'ten istediğim özellikleri seçip diğerine almak için sık kullanıyorum.","mid":"Cherry-pick commit'in diff'ini alıp yeni bir commit olarak uygular, SHA değişir. Release branch'ine hotfix taşırken `git cherry-pick -x ` kullanırım; `-x` mesaja \"(cherry picked from commit ...)\" ekler, izlenebilirlik sağlar. Commit'in bağımlılıkları da gerekiyorsa onları da almam gerekir, yoksa derlenmez. Özellik taşımak için sürekli cherry-pick yapmak, branch stratejisinde bir sorun olduğunu gösterir.","senior":"Cherry-pick'i istisna olarak görürüm: hotfix'i önce `main`'e yapıp test eder, sonra destekli release branch'lerine `-x` ile taşırım (upstream first). Böylece düzeltmenin bir sonraki sürümde kaybolması riski olmaz. Riskler: bağlam eksikliği (bağımlı commit'ler), aynı değişikliğin iki kopyası yüzünden sonraki merge'lerde kafa karıştıran conflict'ler ve \"hangi sürümde hangi düzeltme var\" takibinin zorlaşması. Sık cherry-pick ihtiyacı, uzun yaşayan branch'lerin işaretidir.","interviewer":"Junior'ın yanlışı cherry-pick'i olağan bir \"özellik seçme\" aracı olarak kullanmak. Bu, aynı değişikliğin farklı SHA'larla çoğalmasına, bağımlılık eksik derlemelere ve takibi zor bir geçmişe yol açar. Mid `-x` ve bağımlılık riskini biliyor; senior \"upstream first\" ilkesini ve sık cherry-pick'in strateji problemi olduğunu söylüyor.\n\n**Takip sorusu:** Hotfix'i doğrudan `release/2.3` branch'ine yapıp oradan deploy ettin. Bir sonraki sürümde bug tekrar ortaya çıktı. Ne oldu, süreç nasıl olmalı?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#16","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"`git rebase -i ` (örneğin `git rebase -i origin/main`) seçtiğin commit'leri bir listede açar; her satırda `pick`, `reword` (mesajı değiştir), `edit` (commit'te dur), `squash`/`fixup` (öncekiyle birleştir), `drop` (sil) seçebilir ve sırayı değiştirebilirsin. PR açmadan önce \"wip\", \"fix typo\" commit'lerini anlamlı, atomik commit'lere dönüştürmek için kullanılır. Commit'ler yeniden yazıldığı için sadece paylaşılmamış (ya da sadece senin kullandığın) commit'lerde yapılır.","questionMd":"Interactive rebase ile commit geçmişini nasıl temizlersin?","answers":{"junior":"`git rebase -i HEAD~10` yapıp hepsini squash ediyorum, tek commit kalıyor, çok temiz. Sonra `main`'e force push ediyorum.","mid":"PR'dan önce kendi branch'imde temizlik yaparım: `git rebase -i origin/main`. \"wip\" ve \"fix typo\" commit'lerini `fixup` ile asıl commit'e katarım, mesajları `reword` ile düzeltirim. Daha pratik yol: düzeltmeyi atarken `git commit --fixup=` kullanırım, sonra `git rebase -i --autosquash origin/main` bu commit'leri otomatik doğru yere taşıyıp `fixup` olarak işaretler. Sonra kendi branch'ime `--force-with-lease` ile push ederim.","senior":"Amaç her şeyi tek commit'e ezmek değil, review edilebilir ve tek tek revert edilebilir atomik commit'ler bırakmak: \"refactor: extract FeeCalculator\", \"fix: reject unknown currency\". `edit` ile bir commit'i durdurup `git reset HEAD~` ve `git add -p` ile ikiye bölebilirim. `exec` satırları ya da `git rebase -i -x \"./mvnw -q test\"` ile her commit'in yeşil kaldığını doğrularım. Üst üste binen branch'lerde (stacked PR) `--update-refs` alttaki branch işaretçilerini de taşır. Bir şey ters giderse `git rebase --abort`, bittikten sonra fark edersem reflog'dan `ORIG_HEAD`.","interviewer":"Junior iki yanlış yapıyor: tüm geçmişi refleks olarak tek commit'e ezmek ve paylaşılan `main`'e force push etmek. Temizliğin amacı atomik, anlamlı commit'lerdir ve sadece kendi branch'inde yapılır. Mid `--fixup` + `--autosquash` akışını biliyor; senior commit bölme, her adımda test (`-x`) ve `--update-refs` ile ileri seviye kullanım gösteriyor.\n\n**Takip sorusu:** Interactive rebase'in ortasında conflict çıktı ve ne yaptığını karıştırdın. Hangi seçeneklerin var?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#17","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"Normalde HEAD bir branch'e işaret eder; bir commit'e, tag'e ya da `origin/main`'e doğrudan checkout yaptığında HEAD doğrudan bir commit'e işaret eder: buna detached HEAD denir. Bu durumda commit atabilirsin ama hiçbir branch bu commit'leri tutmaz; başka bir branch'e geçtiğinde ulaşılamaz hale gelirler ve bir süre sonra çöp toplayıcı tarafından silinebilirler. Saklamak için `git switch -c yeni-branch` ile branch oluşturursun; geçtiysen reflog'dan bulursun.","questionMd":"Detached HEAD nedir, orada attığın commit'lere ne olur?","answers":{"junior":"Detached HEAD bir hata durumu, Git bozuldu demek. Görünce `main`'e geçip devam ediyorum.","mid":"Bir tag'i ya da eski bir commit'i incelemek için `git switch --detach v1.2.0` dediğimde HEAD branch'e değil commit'e işaret eder. Sadece bakıyorsam sorun yok. Orada commit atarsam ve sonra `main`'e geçersem Git \"you are leaving 1 commit behind\" uyarısı verir ve hash'i gösterir; `git branch kurtar ` ile saklarım. Hash'i kaçırdıysam `git reflog`'da bulurum.","senior":"HEAD normalde sembolik bir ref'tir; detached durumda doğrudan bir commit hash'i tutar. Bisect ve rebase gibi komutlar da bu modda çalışır. Commit atılabilir ama ulaşılabilirlik bir ref'e bağlıdır; ref yoksa commit sadece reflog sayesinde yaşar ve reflog süresi dolunca `gc` ile silinebilir. Deney yapacaksam baştan `git switch -c deney` derim.","interviewer":"Junior'ın yanlışı detached HEAD'i bir hata sanıp oradaki işi fark etmeden bırakmak. Detached HEAD normal bir moddur (bisect, rebase, tag inceleme); risk sadece orada atılan commit'lerin bir branch'e bağlanmamasıdır. Mid uyarıyı ve kurtarmayı biliyor; senior ulaşılabilirlik ve gc ilişkisini kuruyor.\n\n**Takip sorusu:** Detached HEAD'de iki commit attın, `main`'e geçtin ve terminali kapattın. Bir gün sonra bu commit'leri nasıl bulursun?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#18","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"Merge commit, PR'ın tüm commit'lerini olduğu gibi ve bir merge commit ile ana hatta bağlar; geçmiş tam ama dallıdır. Squash merge, PR'ın tüm değişikliğini tek bir yeni commit olarak ana hatta ekler; geçmiş doğrusal ve PR başına bir commit olur, ara commit'ler ana hatta görünmez. Rebase merge, PR'ın commit'lerini tek tek ana hattın üzerine yeniden uygular; doğrusal ama her commit korunur. Seçim, ekibin commit disiplinine ve geçmişten ne beklediğine bağlıdır.","questionMd":"Squash merge, merge commit ve rebase merge arasındaki fark nedir?","answers":{"junior":"Squash en iyisi çünkü geçmiş temiz oluyor. Merge commit geçmişi kirletiyor. Hangisini seçtiğimiz çok fark etmez.","mid":"Squash merge'de PR tek commit olur, PR başlığı commit mesajı olur; ara commit'lerin kalitesi önemsizleşir, ama büyük PR'larda bisect'in çözünürlüğü PR seviyesine düşer. Merge commit ara commit'leri korur ve özelliği `revert -m 1` ile tek seferde geri almayı sağlar. Rebase merge doğrusal ama commit'lerin her biri ana hatta girdiği için her birinin derlenmesi gerekir. Squash'ın bir yan etkisi: lokal branch \"not fully merged\" görünür, çünkü yeni commit'in parent'ı branch'in commit'leri değildir; üzerine açılmış ikinci branch'te de conflict çıkarabilir.","senior":"Kararı commit disiplinine göre veririm. Ekip atomik commit'ler yazmıyorsa squash merge + Conventional Commits formatında PR başlığı en pratik yol: ana hatta PR başına bir anlamlı commit, otomatik changelog. Ekip temiz commit'ler yazıyorsa rebase merge ya da merge commit ince taneli geçmişi korur. GitHub'ın rebase merge'ü commit'leri her zaman yeniden yazar (yeni SHA), yani yerel branch'le hash'ler eşleşmez. Stacked PR kullanılıyorsa squash, alttaki PR merge edildiğinde üstteki branch'in rebase edilmesini gerektirir (`git rebase --onto`). Her durumda branch protection ile tek bir yöntemi zorunlu kılarım ki geçmiş tutarlı olsun.","interviewer":"Junior'ın yanlışı birini \"en iyi\" ilan edip bedellerini görmemek. Her yöntemin bedeli var: squash ara commit'leri ve bisect çözünürlüğünü kaybettirir, merge commit dallı geçmiş bırakır, rebase merge her commit'in yeşil olmasını ister. Mid squash'ın yerel yan etkisini biliyor; senior kararı ekip disiplinine bağlıyor ve stacked PR etkisini anlatıyor.\n\n**Takip sorusu:** Squash merge kullanan bir ekipte `feature/a` merge edildi; `feature/a` üzerine açılmış `feature/b`'yi `main`'e nasıl taşırsın?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#19","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"Orta","short":"Git Flow `main` ve `develop` adlı iki uzun ömürlü branch ile `feature/*`, `release/*`, `hotfix/*` branch'lerini kullanır; planlı sürümleri ve birden fazla desteklenen versiyonu olan ürünlere uyar ama ağırdır. GitHub Flow'da tek uzun ömürlü branch (`main`, her zaman deploy edilebilir) vardır; kısa feature branch açılır, PR ile review edilir, merge edilip deploy edilir. Trunk-based development'ta herkes çok kısa ömürlü branch'lerle (ya da doğrudan) günde en az bir kez trunk'a entegre olur; bitmemiş iş feature flag ile gizlenir. Sürekli teslimat yapan servislerde GitHub Flow ya da trunk-based tercih edilir.","questionMd":"Git Flow, GitHub Flow ve trunk-based development arasındaki fark nedir? Hangisini ne zaman seçersin?","answers":{"junior":"Biz Git Flow kullanıyoruz, en profesyonel yöntem o. `develop`'tan feature branch açıp iş bitince merge ediyoruz. Trunk-based'de herkes `main`'e push ediyor, bu riskli.","mid":"Git Flow sürüm döngüsü olan, birden fazla sürümü paralel destekleyen ürünler için tasarlandı; mobil uygulama ya da müşteriye kurulan yazılım gibi. Sürekli deploy edilen bir mikroservis için `develop` ve `release` branch'leri gecikme ve merge conflict üretir. GitHub Flow'da `main` deploy edilebilir kalır, iş kısa branch'ler ve PR'larla gelir. Trunk-based'de branch'ler bir iki günden uzun yaşamaz, bitmemiş özellik feature flag arkasında kapalıdır; bu da sürekli entegrasyonun gerçek anlamı.","senior":"Seçimi teslimat modeli belirler. Günde birkaç kez deploy edilen servislerde trunk-based ya da GitHub Flow: küçük PR, zorunlu CI ve review, feature flag, `main` her an deploy edilebilir. Uzun yaşayan branch, ertelenmiş entegrasyon riskidir ve conflict'ler büyüdükçe pahalılaşır. Git Flow'u birden fazla sürümü paralel desteklemem gerektiğinde (on-prem kurulumlar, mobil) seçerim; orada bile `develop` yerine `main` + gerekirse `release/x.y` dalları daha sadedir. Git Flow'un yazarı da 2020'de eklediği notta sürekli teslim edilen yazılımlar için GitHub Flow gibi daha basit bir akışı önerir. Bankacılık gibi regüle ortamlarda denetim izi branch'ten değil PR onayı, CI kaydı ve tag'li release'ten gelir (trunk-based ve flag'ler için bkz. Kitap Bölüm 20).","interviewer":"Junior'ın yanlışı Git Flow'u \"en profesyonel\" saymak ve trunk-based'i \"herkesin kontrolsüzce main'e push etmesi\" sanmak. Trunk-based küçük ve sık entegrasyon, zorunlu CI ve feature flag disiplinidir; kontrolsüzlük değildir. Doğru cevap stratejiyi teslimat modeline bağlar. Senior bunu, regüle ortamda denetim izinin nereden geldiğiyle birlikte anlatıyor.\n\n**Takip sorusu:** Ekibin feature branch'leri ortalama üç hafta yaşıyor ve her merge yarım gün conflict çözümü gerektiriyor. Neyi değiştirirsin?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#20","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","short":"Git içeriğe göre adreslenen bir nesne veritabanıdır: blob (dosya içeriği), tree (dizin: isim, mod ve blob/tree hash'leri), commit (kök tree, parent'lar, author, committer, mesaj) ve annotated tag. Her nesnenin adı, tür ve boyut başlığıyla birlikte içeriğinin hash'idir (varsayılan SHA-1). Commit bir diff değil, kök tree'ye işaret eden bir snapshot'tır; parent hash'ini içerdiği için geçmişteki her değişiklik sonraki tüm hash'leri değiştirir. Branch ve HEAD bu nesnelere işaret eden isimlerdir.","questionMd":"Git'in iç modeli: bir commit neyi işaret eder, SHA nasıl oluşur?","answers":{"junior":"Commit, o commit'teki değişiklikleri (diff'i) tutar. SHA rastgele üretilen benzersiz bir id'dir.","mid":"Commit bir tree'ye işaret eder; tree dizinin snapshot'ı, blob'lar dosya içerikleri. Commit ayrıca parent commit'in hash'ini, yazar ve mesajı tutar. SHA içerikten hesaplanır, rastgele değildir: aynı içerik her zaman aynı hash'i verir. Bu yüzden aynı içerikli iki dosya tek blob olarak saklanır. `git cat-file -p HEAD` ile commit'in içini görebilirim.","senior":"Dört nesne türü var; hepsi `\" \\0\" + içerik` üzerinden hash'lenir ve zlib ile sıkıştırılıp saklanır, sonra `gc` ile packfile'larda delta'lanır. Commit = kök tree + parent'lar + author/committer (zaman damgasıyla) + mesaj. Bundan çıkan sonuçlar mülakatta asıl anlatılması gerekenler: (1) içerik aynıysa nesne aynı, dolayısıyla deduplication ücretsiz; (2) commit hash'i tüm geçmişe bağlı, bu yüzden amend, rebase ve cherry-pick (parent ya da zaman değiştiği için) her zaman yeni SHA üretir; (3) branch ve tag sadece isim, \"silme\" bir işaretçiyi kaldırmak, asıl nesneler ancak hiçbir ref ve reflog'dan ulaşılamaz olduğunda `gc` ile gider; (4) dosya adı blob'da değil tree'de, bu yüzden Git rename'i saklamaz, benzerlikten çıkarır; (5) boş dizin takip edilmez. SHA-1'e karşı çakışma saldırıları bilindiği için Git çakışma tespiti yapan sertleştirilmiş SHA-1 kullanır ve SHA-256 formatını da destekler.","interviewer":"Junior'ın iki yanlışı: commit'i diff sanmak ve SHA'yı rastgele bir id sanmak. Commit snapshot'tır ve SHA içerikten (parent dahil) türetilir; bu iki gerçek rebase, amend, reflog ve gc davranışının tamamını açıklar. Mid modeli doğru kuruyor. Senior modelden davranış sonuçları çıkarıyor (deduplication, SHA değişimi, rename tespiti, ulaşılabilirlik); bu, ezber değil anlayış sinyali.\n\n**Takip sorusu:** İki geliştirici aynı commit'i aynı içerik ve mesajla iki farklı makinede cherry-pick etse aynı SHA'yı mı elde ederler? Neden?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#21","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","short":"`--force` remote branch'te ne varsa ezip senin yerel halini yazar; arada başkası push ettiyse onun commit'leri kaybolur. `--force-with-lease`, remote ref'in hâlâ senin bildiğin değerde (remote-tracking ref'indeki değerde) olmasını şart koşar; değiştiyse \"stale info\" ile reddeder. Ama arada bir `git fetch` yaptıysan remote-tracking ref güncellenir ve lease yine geçer; buna karşı `--force-if-includes` remote ucunun yerel geçmişine entegre edildiğini de kontrol eder.","questionMd":"git push --force ile --force-with-lease arasındaki fark nedir?","answers":{"junior":"Push reddedilince `--force` kullanıyorum. `--force-with-lease` daha güvenli versiyonu, onu kullanınca hiçbir şey kaybolmaz.","mid":"`--force-with-lease` remote'taki branch'i, benim son fetch'imde gördüğüm değerle karşılaştırır. Ben rebase yaparken arkadaşım aynı branch'e push ettiyse lease tutmaz ve push reddedilir, onun commit'i ezilmez. Ama IDE arka planda fetch yaptıysa `origin/feature` onun commit'ini gösterir ve lease geçer; o commit'i görmeden ezmiş olurum. Bu yüzden `--force-with-lease --force-if-includes` kullanırım. Force push'u sadece kendi feature branch'imde yaparım.","senior":"`--force-with-lease` bir compare-and-swap: \"remote ref X ise Y yap\". Beklenen değeri açıkça vermezsem X, remote-tracking ref'imdir; herhangi bir fetch bu beklentiyi sessizce günceller. Güvenli kullanım: `--force-with-lease=feature/x:` ya da `--force-if-includes` ile birlikte; ikincisi remote-tracking ucunun benim branch'imin reflog'unda/geçmişinde yer almasını şart koşar. `git config --global alias.pushf \"push --force-with-lease --force-if-includes\"` gibi bir alias kullanırım. Organizasyon düzeyinde `main` ve release branch'lerinde force push'u branch protection ile tamamen kapatırım; lease bir istemci tarafı güvenlik kemeridir, sunucu tarafı politika değil.","interviewer":"Junior'ın yanlışı `--force-with-lease`'in \"hiçbir şey kaybolmaz\" garantisi verdiğini sanmak. Lease, son fetch'teki değere göre kontrol eder; arka planda fetch yapılmışsa görmediğin commit'i yine ezebilirsin. Mid bu tuzağı ve `--force-if-includes`'u biliyor. Senior bunu compare-and-swap olarak modelliyor ve istemci tarafı güvenlik ile sunucu tarafı politika (branch protection) ayrımını yapıyor.\n\n**Takip sorusu:** Force push ile bir takım arkadaşının commit'ini ezdin ve onun lokal kopyası yok. Remote'ta kaybolan commit'i nasıl geri getirmeye çalışırsın?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#22","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","short":"Reflog, HEAD'in ve her branch'in yerel hareket günlüğüdür; commit, reset, rebase, amend, checkout her adımda bir kayıt bırakır. `git reflog` ile kaybettiğin commit'in hash'ini (ya da `HEAD@{n}`) bulup `git branch kurtar ` veya `git reset --hard HEAD@{n}` ile geri getirirsin. Reflog yereldir ve push edilmez; varsayılan olarak ulaşılamayan girdiler 30, diğerleri 90 gün sonra temizlenebilir. Hiç commit'lenmemiş değişiklikler reflog'da yoktur.","questionMd":"Kaybolan bir commit'i reflog ile nasıl kurtarırsın?","answers":{"junior":"Reset ya da rebase ile kaybolan commit geri gelmez, o yüzden yedek alıyorum. Ya da remote'tan tekrar clone'luyorum.","mid":"Reset veya rebase commit'leri silmez, sadece branch işaretçisini taşır; eski commit'ler reflog'da durur.\n\n```bash\ngit reflog # 3b0f123 HEAD@{1}: commit: add fee validation\ngit branch rescue 3b0f123 # ya da: git reset --hard HEAD@{1}\n```\n\nRebase'i geri almak için `ORIG_HEAD` de işe yarar: `git reset --hard ORIG_HEAD`. Silinen bir branch'in son hash'i `git branch -D` çıktısında ve reflog'da görünür.","senior":"Kurtarma hiyerarşisini bilirim. Commit'lenmiş iş: reflog (`git reflog`, `git reflog show feature/x`) ve `ORIG_HEAD`. Reflog'dan da düşmüş ama henüz `gc` ile silinmemiş commit'ler: `git fsck --unreachable` ya da `--lost-found`. Sadece `git add` edilmiş ama commit'lenmemiş içerik: index'e yazıldığı için dangling blob olarak `fsck` ile bulunabilir (dosya adı olmadan). Hiç stage edilmemiş değişiklik: Git'te yok; IDE'nin local history'si tek umut. Reflog yerel olduğu için remote'ta force push ile kaybolan commit'i başkasının clone'unda ya da barındırma platformunun olay kaydında/PR ref'lerinde ararım. Bu yüzden riskli işlemlerden önce `git branch backup` açmak bedavadır.","interviewer":"Junior'ın yanlışı reset/rebase ile commit'lerin kalıcı silindiğini sanmak. Commit'ler ulaşılamaz hale gelir ama reflog süresi dolup `gc` çalışana kadar durur. Mid reflog ve `ORIG_HEAD`'i doğru kullanıyor. Senior commit'lenmiş, stage edilmiş ve hiç stage edilmemiş değişiklik arasındaki kurtarılabilirlik farkını ve reflog'un yerel olduğunu biliyor.\n\n**Takip sorusu:** `git reset --hard` ile hem son commit'i hem de `git add` edilmiş ama commit'lenmemiş bir dosyayı kaybettin. Hangisini, nasıl kurtarabilirsin?"},"href":"/sorular/git/"},{"kind":"open","id":"sorular/git#23","category":"Zanaat","label":"Git ve sürüm kontrolü","level":"İleri","short":"`git bisect` iyi olduğu bilinen bir commit ile kötü olduğu bilinen bir commit arasında ikili arama yapar: Git ortadaki commit'e geçer, sen `git bisect good` ya da `bad` dersin, aralık her adımda yarıya iner; 1.000 commit yaklaşık 10 adımda taranır. `git bisect run

Soru türleri

Konular

Seviye

Soru sayısı