sade.dev
TREN

Backend ve sistem mühendisliği üzerine bir not defteri.

Her yazının iskeleti

  1. 01Durum
  2. 02Kısıt
  3. 03Yaklaşım
  4. 04Tuzaklar
  5. 05Geçerlilik

Öne çıkan

SystemTransactional Outbox: Dual-Write, İdempotent TüketimDual-write'ı outbox'la kapatmak, doğan at-least-once tekrarını idempotent tüketimle bastırmak, event'in içindeki kişisel veriyi alanda şifrelemek./10 bölüm

Son yazılar49

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

  1. Journal5 bölüm

    Upgrade'i Ertelemenin Maliyeti

    PHP 7.1 → 8.2 upgrade'i "çalışıyor ya" diye ertelendi. Fatura sonra geldi: bağımlılık kilidi, toplu breaking change ve aylara yayılan bug'lar.

    #technical-debt#decisions#dependencies#opinion
  2. Journal5 bölüm

    %100 Coverage Peşinde İşlevsiz Test Yazmak

    Test coverage bir hedef değil, bir yan üründür. Sayıyı yükseltmek için yazılan, hiçbir hatayı yakalamayan testlerin maliyeti.

    #testing#quality#opinion
  3. devrazziGürültüyü geçin, sinyali okuyunYazılımcılar için seçilmiş teknoloji haberleri ve sentezi. İçerik AI agent'ları tarafından üretiliyor; her yazı kaynağına bağlanıyor.
  4. Journal5 bölüm

    Her Şey İçin Bir Paket Kurmanın Bedeli

    Küçük bir fonksiyon için bağımlılık eklemenin güvenlik, bakım ve supply-chain maliyeti — ve ne zaman kendiniz yazmanın daha ucuz olduğu.

    #dependencies#security#simplicity#opinion
  5. Note6 bölüm

    CQRS: Ne Zaman Gerekli, Ne Zaman Gereksiz Yük?

    Okuma ve yazma modellerini ayırmak: CQRS'in karmaşık domain'de kazandırdığı netlik ve basit CRUD'da yarattığı gereksiz yük.

    #architecture#cqrs#patterns
  6. Note6 bölüm

    Arşivleme Stratejisi: Eski Veriyi Yavaşlatmadan Ayırma

    Canlı tabloyu şişiren eski kayıtları ayırmak: partition'lama, soğuk depolama ve arşivlerken sorgu erişimini koruma yöntemleri.

    #postgresql#database#performance#production
  7. Journal5 bölüm

    Verin Gerçekten Büyük mü, Yoksa Kötü mü Modellenmiş?

    Çoğu büyük veri problemi aslında kötü modelleme veya eksik indekstir. Dağıtık sisteme geçmeden önce verinin gerçekten büyük olup olmadığını sorgulamak.

    #database#scaling#architecture#opinion
  8. Note7 bölüm

    PostgreSQL Kuyruk Tablosunu Canlı Kümeye Göre Kurmak

    Kuyruk tablosunda tabloyla büyüyen index ve autovacuum eşiği yanlış ölçeklenir; ikisini bekleyen işlere göre kurmanın ölçülmüş gerekçesi

    #postgresql#queue#performance#indexing#production
  9. Journal5 bölüm

    ORM mi, Native SQL mi?

    ORM bizi tembelleştiriyor mu yoksa gerçekten koruyor mu? İki yaklaşımın güvenlik, okunabilirlik ve performans dengesi.

    #database#orm#sql#opinion
  10. Note6 bölüm

    İndeksler: Eksik Yavaşlatır, Fazlası Yazmayı Öldürür

    Eksik indeks sorguyu yavaşlatır, gereğinden fazla indeks her yazma işlemini pahalılaştırır. Doğru dengeyi tahminle değil ölçümle kurmak.

    #postgresql#database#performance#indexing
  11. Note4 bölüm

    Canlıda Sıfır Kesintiyle Şema Değiştirmek

    Production'da kesinti yaratmadan migration almak: geri uyumlu adımlar, çok aşamalı kolon değişiklikleri ve tablo kilitlenmesini önleme.

    #postgresql#database#migrations#production
  12. Note7 bölüm

    Read/Write Splitting: Okuma ve Yazma Yükünü Ayırmak

    Veritabanını büyütmeden önce: okuma trafiğini replica'lara taşımak, replication lag'in yarattığı tuzaklar ve ne zaman gerçekten gerektiği.

    #postgresql#database#scaling#performance
  13. Note6 bölüm

    Redis Koymadan Önce: Doğru Cache Stratejisi

    Cache eklemeden önce sorulması gereken sorular, cache invalidation'ın neden zor olduğu ve TTL ile tutarlılık arasındaki seçim.

    #caching#redis#performance#production
  14. Journal5 bölüm

    NoSQL Tuzağı: "Şeması Yok" Diye Başlamak

    Şemasız başlamanın verdiği rahatlıkla NoSQL'e geçen projelerin er geç çarptığı tutarlılık ve veri bütünlüğü krizleri.

    #nosql#database#architecture#opinion
  15. Journal4 bölüm

    PostgreSQL Her Şeye Yeter mi?

    Ayrı arama motoru, kuyruk veya doküman DB'si eklemeden önce: PostgreSQL'in tek başına nereye kadar yettiği ve sınırının nerede başladığı.

    #postgresql#database#architecture#opinion
  16. Journal4 bölüm

    Gereğinden Karmaşık Bir Sistemin Verdiği Sinyaller

    Kodun veya mimarinin gereksiz karmaşıklaştığını ele veren somut kırmızı çizgiler — ve sadeleştirmeye nereden başlanacağı.

    #architecture#simplicity#decisions#opinion
  17. Note6 bölüm

    Dış Servis Entegrasyonlarında Circuit Breaker

    Kritik bir sistemi dış API'lere bağlarken: timeout, retry ve circuit breaker ile bir servisin çöküşünün tüm sistemi düşürmesini engellemek.

    #resilience#architecture#api#production
  18. Note7 bölüm

    Serverless'a Geçiş Kararı: Cold-Start, Vendor Lock-in

    FaaS'a geçmeden önce: cold-start gecikmesinin gerçek maliyeti, vendor lock-in riski ve serverless'ın hangi iş yüklerinde kazandırdığı.

    #serverless#architecture#cloud
  19. Note6 bölüm

    BFF Pattern: Mobil ve Web İçin Ayrı API Katmanı

    Mobil ve web için ayrı API katmanları: tek API'yi her istemciye uydurmanın gizli maliyeti ve BFF'in ne zaman gerçekten gerektiği.

    #architecture#api#bff
  20. Note7 bölüm

    Senkron mu Asenkron mu? HTTP ve Kuyruk Arasında Karar

    Bir işi HTTP isteğiyle anında mı yapmalı, kuyruğa mı atmalı? Yanıt süresi ve hata toleransı üzerinden karar çizgisi.

    #architecture#queue#async#api
  21. System10 bölüm

    Transactional Outbox: Dual-Write, İdempotent Tüketim

    Dual-write'ı outbox'la kapatmak, doğan at-least-once tekrarını idempotent tüketimle bastırmak, event'in içindeki kişisel veriyi alanda şifrelemek.

    #architecture#messaging#idempotency#reliability#security

Ara

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

↑↓gez↵açesckapat