sade.dev
TREN

Son yazılar — Sayfa 2

46

Notlar, sistem yazıları ve günlük — tek akışta, tarih sırasıyla.

  1. Note5 bölüm

    Dead-Letter Kuyruğunu Daha Kötü Yapmadan Replay Etmek

    Naif replay kuyruğu yeniden zehirler ya da yan etkileri ikinci kez tetikler. Güvenli şekil: reset, dry-run, önce sandbox, select.

    #queue#dead-letter-queue#reliability#operations#architecture
  2. System5 bölüm

    Polyglot Bir Kuyrukta Dağıtık İzleme

    Donmuş bir envelope üzerinden PHP, Go ve Python'a geçen bir mesajı tek bir OpenTelemetry trace'ine çevirmek — yeni alan, yeni bağımlılık yok.

    #opentelemetry#observability#distributed-tracing#messaging#architecture
  3. Note4 bölüm

    Şemayı Kuyruğun Kenarında Doğrulamak

    Bir mesajın data'sı, kuyruğun kontrol etmediği tipsiz bir sözleşmedir. Kenarda doğrula: üretici yayınlamadan önce, tüketici güvenlik ağı olarak.

    #queue#schema#reliability#architecture
  4. Journal4 bölüm

    Mimari Kararlar Çürür Çünkü Onları Kimse Çalıştırmaz

    Bir wiki'ye yazılmış mimari karar bir dilektir. Zorlayamadığın sınırlar sessizce aşınır — diyagram kodla örtüşmeyi bırakana dek. Kuralı çalıştırılabilir yap.

    #architecture#governance#opinion
  5. Note7 bölüm

    Idempotency: Aynı Mesaj İki Kez Geldiğinde

    At-least-once teslimat, bir handler'ın aynı mesajı iki kez göreceği anlamına gelir. Idempotency anahtarı, nereden geldiği ve çökmeden sağ çıkan dedupe.

    #queue#reliability#architecture#async
  6. Journal5 bölüm

    AI Darboğazı Kaldırmadı, Yerini Değiştirdi

    Ucuz kod üretimi, review/entegrasyon/doğrulama yetişemiyorsa çıktıyı artırmaz. Darboğaz yalnızca aşağı kayar — ve asıl iş artık orada

    #ai-workflow#productivity#opinion
  7. Journal6 bölüm

    Kararsız Testler: Retry Çözüm Değil

    AI test yazmayı neredeyse bedava yaptı, kararsız süitler patladı. Retry ve quarantine neden bir koşu bandı ve kararsızlığı deterministik olarak ne yakalar

    #testing#ci#ai#quality
  8. Journal5 bölüm

    Şema Evrimi: Sözleşmeyi Kırmadan Değiştirmek

    Servisler arası bir sözleşmeyi atomik değiştiremezsin. Kural: additive güvenli, kırıcı değişiklik yeni bir kimlik ister — ve önce tüketiciler yükseltir

    #architecture#schema#queue#opinion
  9. Journal5 bölüm

    Katmanlı Mimari mi, Clean Architecture mı?

    Klasik katmanlı yapı çoğu projeye yeterken neden soyutlama katmanlarında boğuluyoruz; Clean Architecture gerçekten ne zaman değer katar?

    #architecture#clean-architecture#simplicity#opinion
  10. Journal4 bölüm

    Vibe Coding ile Production'a Çıkılır mı?

    Vibe coding ilk sürümün maliyetini düşürür, yanlış olmanın maliyetini değil. O fatura build'de değil, production'da çıkar.

    #ai-workflow#vibe-coding#production#architecture#opinion
  11. Journal5 bölüm

    "İleride Lazım Olur" Kodunun Production Faturası

    YAGNI'yi pratikte uygulamak: bugün gerekmeyen esnekliği eklemenin bakım, okunabilirlik ve hata yüzeyi olarak geri ödenen bedeli.

    #architecture#simplicity#decisions#opinion
  12. System10 bölüm

    Ardışık Numara Üretiminde Race Condition ve Gap

    Yasal olarak ardışık ve boşluksuz numaraları paralel worker'larla üretmek: race condition ile gap'i birlikte çözen JIT rezervasyon kalıbı.

    #architecture#production#concurrency#queue#idempotency
  13. Journal5 bölüm

    Mikroservise Ne Zaman Geçerim?

    Monolitten dağıtık mimariye geçişi haklı çıkaran ölçülmüş sinyaller — ve geçiş için henüz erken olduğunu söyleyen yaygın yanlış gerekçeler.

    #architecture#microservices#decisions#opinion
  14. Journal8 bölüm

    Gitflow mu, GitHub Flow mu? Neye Göre Seçiyorum?

    Branch stratejisi seçimini ürün modeli, sürüm sayısı ve deploy ritmine göre yapmanın pratik kriterleri — ve iki modelin yanlış yerde nasıl kırıldığı.

    #git#workflow#branching#decisions#opinion
  15. Journal5 bölüm

    Projelere Neden Modüler Monolit ile Başlıyorum?

    Mikroservislere atlamadan önce tek deploy edilebilir bir uygulamada net modül sınırları kurmanın gerekçesi — ve bu kararı ne zaman bıraktığım.

    #architecture#modular-monolith#decisions#opinion
  16. Journal8 bölüm

    Trunk-Based Development'a Ne Zaman Geçiyorum?

    Yüksek frekanslı deploy yapan ekiplerde release branch'lerinin neden kırıldığı ve trunk-based'in ne kadarının disiplin olduğu — geçtiğim ve geçmediğim eşikler.

    #git#workflow#deploy#decisions#opinion
  17. System9 bölüm

    Veri Yoğunluklu Sistemlerde Ölçek Kırılma Noktaları

    Veri yükü arttıkça boring mimari nerede kırılır? Working set, read replica, partitioning, yazma yükü, ayrı veri katmanı — sırayla ve maliyetleriyle.

    #postgresql#architecture#production#scaling#replication
  18. Journal7 bölüm

    Neden Boring Architecture'ı Tercih Ediyorum

    Yeni teknoloji peşinde koşmak yerine kanıtlanmış araçları seçmenin pragmatik gerekçesi. Bu bir korkaklık değil, bir bütçe kararı.

    #architecture#decisions#opinion
  19. Note5 bölüm

    Shared Redis Kullanırken Namespace İzolasyonu

    Tek bir Redis instance birden çok proje arasında paylaşılırken key collision ve yanlışlıkla silme kazalarından korunmak için kullandığım örüntü.

    #redis#production#architecture
  20. Journal8 bölüm

    AI-Assisted Engineering Workflow'um

    Claude Code ve benzeri ajanları üretim kodunda güvenle kullanmak için takip ettiğim yedi kural — alaycı bir yazı değil, bir disiplin manifestosu.

    #ai-workflow#productivity#opinion

Ara

Yazmaya başlayın. Notlar, sistem yazıları, günlük, araçlar ve sayfalar.

↑↓gez↵açesckapat