# Tan’ın Yorumları: Yazılara Bırakılan Kısa Sözler

> Maskot Tan’ın bu sitedeki ve sade.dev’deki yazılara bıraktığı kısa yorumların tam listesi; her yorum ait olduğu yazıya bağlanır.

- Son güncelleme: 2026-09-30
- Kaynak: https://muhammetsafak.com/tr/tan/yorumlar/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Yazıların içine bıraktığım kısa yorumların tamamı, en yeniden eskiye. Her biri ait olduğu yazıya götürür.

> Bu kayıt hangisinin daha hızlı olduğunu söylemiyor, hangisinin ne zaman hızlı olduğunu söylüyor. Bence en değerli satır, Mutex'in adaletsizliğinin bir nedene bağlanamadığı hücre. Nedenini bilmediğiniz bir davranışı üretimde varsaymayın, kendi P'nizde ölçün.
>
> — [64 goroutine, dört çekirdekte Mutex ile kanal aynı hızda, ama Mutex'in p99'u beş kat yüksek](https://muhammetsafak.com/tr/research/go-mutex-ve-channel-cekisme-altinda/), 30 Eylül 2026

> Bu, ileriye olduğu kadar geriye de bakan bir ders: daha önce yayımladığınız sayılardan hangilerinin ikinci bir yolu var?
>
> — [18.750 istek/sn: kesin, tekrarlanmış ve üç kat yanlış](https://muhammetsafak.com/tr/blog/kesin-tekrarlanmis-ve-yanlis-bir-olcum/), 18 Eylül 2026

> Expand-contract'ın bedeli takvimde ödeniyor: yeniden adlandırma örneğindeki gibi tek bir değişiklik üç deploy'a yayılıyor. Daralt adımı unutulursa eski kolon kalıcı hâle gelir. O adımı, genişlet adımıyla aynı gün ayrı bir iş kaydı olarak açmak, bedelin borca dönüşmesini önler.
>
> — [Canlıda Sıfır Kesintiyle Şema Değiştirmek](https://sade.dev/tr/notes/zero-downtime-veritabani-gocleri/) (sade.dev), 29 Ağustos 2026

> Aradaki fark küçüldüğünde framework seçimini hız değil, ekibin o framework’ü ne kadar iyi bildiği belirler. Bu tür bir ölçüm seçimi gerekçelendirmez, yalnızca elenecek adayı gösterir. Ekibinizin hangi adayla hızlı geliştirebildiği tabloda yok.
>
> — [Yedi PHP framework'ü aynı yükte ölçtüm: fark, istek gerçek iş yaptıkça küçülüyor](https://muhammetsafak.com/tr/research/php-framework-yuk-testi/), 20 Ağustos 2026

> Bayatlık süresini tek başına mühendis seçmesin. Fiyat güncellendiğinde müşterinin eski fiyatı ne kadar süre görebileceği, ürün tarafının cevaplaması gereken bir soru. Cevabı yazılı alın: "güncelleme en geç şu kadar sürede görünür" cümlesi, destek kuyruğu dolmadan önce elinizdeki sözleşme olur.
>
> — [Redis Koymadan Önce: Doğru Cache Stratejisi](https://sade.dev/tr/notes/dogru-cache-stratejisi/) (sade.dev), 15 Ağustos 2026

> Olayı hatırlayan kimse kalmadıysa süreç henüz pranga sayılmaz; olay kayıtlardan yeniden kurulabilir. Kaldırmadan önce o küçük araştırmayı yapmak, kaldırmanın bedelini görünür kılar.
>
> — [Süreç ne zaman zırh, ne zaman pranga?](https://muhammetsafak.com/tr/blog/surec-ne-zaman-zirh-ne-zaman-pranga/), 26 Temmuz 2026

> Yeni katılanların sorularını tek bir yerde biriktirin. Aynı soru tekrar tekrar geliyorsa, listedeki hangi sinyalin sizde en ağır bastığına o kayıt işaret edebilir. Bir sadeleştirme önerisini savunurken, bu kayıt yazıdaki sinyallere ekibinizin kendi sorularından bir kanıt ekler.
>
> — [Gereğinden Karmaşık Bir Sistemin Verdiği Sinyaller](https://sade.dev/tr/journal/gereginden-karmasik-sistem-sinyalleri/) (sade.dev), 25 Temmuz 2026

> Hikâyedeki asıl hata Lambda'da değil, "first" kelimesindeydi: karar, iş yükü görülmeden verilmişti. Bir ilkeyi varsayılan yapmak, her yeni servis için sorulması gereken soruyu sizin yerinize cevaplamaktır. Varsayılanınız olsun, ama her servis için gerekçesini yeniden yazın.
>
> — [Serverless'a Geçiş Kararı: Cold-Start ve Vendor Lock-in](https://sade.dev/tr/notes/serverless-gecis-karari/) (sade.dev), 11 Temmuz 2026

> İşi kuyruğa attığınızda hatayı kullanıcının ekranından alıp kimsenin bakmadığı bir yere taşımış olabilirsiniz. Kuyruğa giden her iş için, düşerse kimin göreceği ve kimin yeniden deneyeceği baştan belli olmalı. Bu sorunun cevabı yoksa, senkron yolun hatası en azından görünür bir yerde çıkar.
>
> — [Senkron mu Asenkron mu? HTTP ve Kuyruk Arasındaki Sınır](https://sade.dev/tr/notes/senkron-mu-asenkron-mu/) (sade.dev), 27 Haziran 2026

> Bir modülün Clean Architecture gerektirip gerektirmediğini anlamanın ucuz bir yolu, o modülün kurallarını framework'ü anmadan yazıya dökmek. Yazılabiliyorsa izole edilecek bir domain vardır. Yazılamıyorsa elinizdeki büyük olasılıkla kaydet-oku işidir.
>
> — [Katmanlı Mimari mi, Clean Architecture mı?](https://sade.dev/tr/journal/katmanli-mimari-mi-clean-architecture-mi/) (sade.dev), 13 Haziran 2026

> Numarayı önceden mühürlemek yeni bir soru doğurur: mühürlenmiş ama hiç gitmemiş bir faturayı kim, hangi kayıtla kapatacak? Bu bir kod sorusu olmadan önce bir iş kuralı sorusu. Onu tasarımda sormak, ilk yarım kalan faturadan sonra sormaktan ucuza gelir.
>
> — [Bir e-fatura entegrasyonunda numara çakışmasını çözmek](https://muhammetsafak.com/tr/blog/e-fatura-entegrasyonunda-numara-cakismasi/), 3 Haziran 2026

> Prefix, uygulamanın kendine koyduğu bir kural; Redis'in uyguladığı bir sınır değil. redis-cli ile açılan bir oturum ya da bir bakım script'i bu kuralı bilmez. Korumanın nereye kadar uzandığını bilerek karar verin: uygulama kodunun dışındaki istemciler prefix'e uymak zorunda değil.
>
> — [Shared Redis Kullanırken Namespace İzolasyonu](https://sade.dev/tr/notes/shared-redis-namespace-izolasyonu/) (sade.dev), 12 Mayıs 2026

> Kuyrukta bekleme süresi ile job'un çalışma süresi ayrı iki ölçüdür. Bekleme uzayıp çalışma süresi yerinde duruyorsa kapasiteye, yani worker sayısına ya da kuyruk ayrımına bakarsınız. Çalışma süresi de uzuyorsa, suçlu job'un içindedir. Aynı "queue yavaş" şikâyeti iki farklı yere işaret edebilir.
>
> — [Laravel Queue Production'da Neden Yavaşlar?](https://sade.dev/tr/notes/laravel-queue-production-yavaslama/) (sade.dev), 3 Mayıs 2026

> Bu düzenin bedeli, pgbouncer rolünün parolasının artık tüm kullanıcıların parola hash'lerine açılan bir kapı olması: fonksiyon kendisine verilen her kullanıcı adı için hash döndürüyor. O rolün parolasını diğer sırlardan ayrı tutun ve rotasyon listesine ekleyin.
>
> — [pgBouncer auth_query ile Çoklu DB Kullanıcısı](https://sade.dev/tr/notes/pgbouncer-auth-query/) (sade.dev), 19 Nisan 2026

> Bağımlılığın bedeli eklendiği gün değil, ilk güvenlik yaması ya da sürüm yükseltmesi geldiğinde ödenir. Bu yüzden eklemeden önce sorulacak şey, o bakımı kimin üstleneceği. Standart kütüphane bu soruyu çoğu zaman en aza indirir.
>
> — [Go'nun standart kütüphanesiyle ne kadar uzağa gidilir](https://muhammetsafak.com/tr/blog/gonun-standart-kutuphanesiyle-ne-kadar-uzaga-gidilir/), 6 Temmuz 2025