Yazılım mimarı: teslim garantisinin karar garantisi olmadığı sistemler

Bu sayfanın kapsadığı üç konu

Üçü de sitedeki bir yazıya, kayda ya da deneyime dayanıyor; derinlik değil kimlik ve kanıt düzeyinde duruyor.

• Software Architecture

  Mikroservis sınırlarını, kritik tasarım kararlarını ve bunların ekibe aktarılmasını kapsıyor. Senior Software Developer, ardından Staff Engineer rollerinde mimariyi domain-driven design ve test-odaklı geliştirmeyle birlikte yürüttüm; sınırları wiki'de bırakmayıp koda yazıp CI'da denetleyen yaklaşım da bu başlığın parçası.

• System Design

  Bir sistemin ölçeklenme, erişilebilirlik ve yük dağılımı kararlarını kapsıyor. Senkron bir fatura akışını ortak bir kuyruğa ve ayrı bir consumer servisine taşıdım. Bunun temeli, mimari sorumluluk üstlenmemden önce bir arama altyapısında atıldı; MySQL ile Redis'i birlikte kullanan bir önbellek katmanı ve böldüğüm veritabanı ile cache kümeleri.

• Event-Driven Architecture

  Teslim, tekrar ve determinizm sorularını kapsıyor. Transactional outbox, idempotent tüketici ve at-least-once teslim bu başlığın pratiği; teslim edilen bir mesajın aynı sonucu üreteceğinin ayrı bir garanti gerektirdiği de.

Bir kararın bedeli

E-fatura numarası üretiminde yasal bir kısıt tasarımın asıl kuvveti oldu. Zincir sırayla okunur.

01 Numarayı geç üretmek race doğurdu

Gönderim anında MAX değerine bir ekleyen yöntem tek worker'la çalışıyordu; paralel worker'lar aynı numarayı üretip dış API'ye aynı numarayla gitti.

02 Numarayı erken üretmek boşluk doğurdu

Numara kuyruğa atılırken üretilirse, düşen ya da iptal edilen fatura seride açıklanamayan bir boşluk bırakıyor. Yasal seride atlanan numara olamaz.

03 Yasal kısıt çözüm kümesini daralttı

Çakışmayı tek başına çözen çok yöntem var; boşluksuzluk eklenince çözüm kümesi bir anda daraldı. Gereksinimi iş kuralı diye kenara almadan önce mimariyi nasıl kısıtladığına bakmak gerekiyor.

04 Numara, dış çağrıdan hemen önce rezerve edildi

Rezerve edilen numara çağrı başarısız olsa da faturanın üstünde kalıyor ve aynı numarayla yeniden deneniyor. Dış çağrı transaction'ın dışında tutuldu; aksi hâlde sistem bir bottleneck'e dönüşürdü.

Teslim garantisi karar garantisi değildir

Her garanti bir maliyetle geliyor; bir deseni çözmek bir sonrakini açıyor.

01 Outbox mesajın kaybolmamasını sağlar

Mesaj, kayıtla aynı transaction içinde bir outbox satırı olarak yazılıyor ve bir relay onu yayımlıyor. Dual-write problemi böylece kapanıyor.

02 At-least-once tekrar getirir

Mesaj kaybolmuyor ama tekrar edebiliyor. Tüketicinin idempotent olması, tekrarı yan etkisiz hâle getiriyor.

03 Teslim edilen mesaj aynı kararı vermeyebilir

Aynı önek listesi iki ayrı serviste tutulduğunda, birinin güncellenmesi, birkaç saat arayla gelen aynı biçimdeki iki mesajdan birini geçirip ötekini reddettirdi. Mesaj, kararın girdisinin tamamı değil.

04 Bağlamı üretim anında dondurmak gerekiyor

Karar için gereken bilgiyi tüketici kendi çözmemeli; olay kendi bağlamını taşımalı. Retry, karar anını değiştirmemeli.

Mimariyi nasıl yürütüyorum

Üç alışkanlık, hepsi ekibin aynı kararı aynı biçimde okuyabilmesine dönük.

• Kararın bedelini yazmak

  Bir kararın neyi kapattığını ve yerine ne koyduğunu yazmadan onu mimari saymıyorum. Yukarıdaki iki zincir bu alışkanlığın çıktısı.

• Sınırı koda yazmak

  Katmanları ve izinli bağımlılıkları tek bir dosyada beyan edip her commit'te CI'da denetlemek, bir mimari kararın iki yıl sonra çürümesini önlüyor.

• Bilgiyi ekibe aktarmak

  Ekibe TDD ve DDD mentörlüğü verdim ve bir code-review rehberi hazırladım; mimarinin yaşadığı yer belge değil, ekibin her gün verdiği küçük kararlar.

Derinlik burada değil

Bu sayfa kimlik ve kanıt düzeyinde kalıyor. Desen anlatısını, mimari kararların neden çürüdüğünü ve outbox ile numara rezervasyonunun ayrıntılarını sade.dev'de yazıyorum.