Tag

#architecture

23 yazı: Note, System, Journal.

← Tüm etiketler

  1. Serverless'a Geçiş Kararı: Cold-Start ve 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ığı.

  2. 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.

  3. Senkron mu, Asenkron mu? HTTP ile Kuyruk Arasındaki Sınır

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

  4. Transactional Outbox: Dual-Write, At-Least-Once ve İdempotent Tüketim

    Veritabanına yazıp event'i kuyruğa düşürememe: dual-write'ı outbox'la kapatmak, doğan at-least-once tekrarını idempotent tüketimle bastırmak ve alanı şifrelemek.

  5. Event-Driven Mimari: Ne Zaman Kurtarır, Ne Zaman Karmaşıklaştırır?

    Event'lerle gevşek bağ kurmanın bedeli: kazandırdığı esneklik ile sistem akışını takip edilemez hale getirme riski arasındaki denge.

  6. Çok Kümeli GitOps’ta Sıfır Statik Yetki

    Uzun ömürlü kubeconfig ya da token olmadan çok kümeli GitOps. SPIFFE ID’ler, SPIRE’ın bastığı kısa ömürlü SVID’ler, trust-domain federasyonu — kurma sırası ve her adımın maliyeti.

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

    Kesinti sırasında DLQ doldu, geri istiyorsun. Naif replay kuyruğu yeniden zehirler ya da yan etkileri ikinci kez tetikler. Güvenli şekil: reset, dry-run, önce sandbox, select.

  8. Polyglot Bir Kuyrukta Dağıtık İzleme

    Bir mesaj PHP, Go ve Python arasında donmuş bir envelope üzerinden geçiyor. Yolculuğunu tek bir OpenTelemetry trace’ine çevirmek — yeni alan ve çekirdek bağımlılığı olmadan — ve dürüst sınırı.

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

    Bir mesajın data'sı, kuyruğun kontrol etmeyeceği tipsiz bir sözleşmedir. Onu kenarda doğrula — üretici tarafında yayınlamadan önce, tüketici tarafında güvenlik ağı olarak.

  10. Mimari Kararların Çürüyor Çünkü Onları Hiçbir Şey Çalıştırmıyor

    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

  11. 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

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

    Bir mesajın data şekli, servisler arası bir sözleşmedir ve onu atomik değiştiremezsin. Kural: additive güvenli, kırıcı değişiklik yeni bir kimlik ister — ve önce tüketiciler yükseltir

  13. 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.

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

    Vibe coding bir ilk sürümün maliyetini düşürür, yanlış olmanın maliyetini değil. O fatura build'de değil, production'da çıkar — ve onu kimin elinde çıkardığına bağlıdır.

  15. "İ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.

  16. Ardışık Numara Üretiminde Race Condition ve Gap: JIT Rezervasyon

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

  17. 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.

  18. 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.

  19. 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ü ve ayrı veri katmanı — sıralı kırılma noktaları ve her birinin maliyeti.

  20. Neden Boring Architecture'ı Tercih Ediyorum

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

  21. Shared Redis Kullanırken Namespace İzolasyonu

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

  22. Tek VPS Üzerinde Çoklu Proje Mimarisi

    Bir VPS, birden fazla bağımsız uygulama. Kubernetes yerine bilinçli minimalizm: kullanıcı izolasyonu, ayrı PHP-FPM pool, paylaşılan PostgreSQL/Redis, sade deploy.

  23. Laravel Production Stack

    Nginx + PHP-FPM + Redis + PostgreSQL + Supervisor + Horizon ile production-grade bir Laravel kurulumu. Her bileşenin işi ve değiştirildiğinde ne kaybedileceği.