Backend geliştirici: API'nin arkasındaki kuyruk, veritabanı ve sunucu

Backend'de ne yapıyorum

Ortak noktaları kullanıcının gördüğü ekranın arkasında kalmaları: sözleşme, kuyruk, veritabanı ve sunucu.

• API sözleşmesi

  Yanıt biçimi, hata sözleşmesi ve sürümleme kararı kod yazılmadan önce netleşiyor. Aksi hâlde istemci tarafındaki her ekip kendi varsayımını yazıyor ve o varsayım altı ay sonra sizin sorununuz oluyor.

• Asenkron teslim hattı

  Kuyruk, consumer ve outbox relay'i; senkron beklemeyi kullanıcının önünden alan yapı. Aynı disiplinin ikinci yarısı idempotency: bir isteğin yan etkisiz olarak tekrar edilebilmesi.

• Veritabanı kararları

  Index ve plan davranışı sezgiyle değil ölçümle seçiliyor; sezgi burada özellikle kötü çalışıyor. Ölçümün kendisi bu sayfada değil, yöntemi ve ortamıyla birlikte research defterinde duruyor.

• Arama ve sunucu katmanı

  İlişkiselin yetmediği sınırda Elasticsearch; ortam Docker ile, deploy hattı GitHub Actions ile, önde nginx. Kapsam uygulama seviyesinde kalıyor.

Kuyruk teslim garantisi vermez

Sık gördüğüm yanılgı, iş kuyruğa taşındığında dayanıklı hâle geldiğinin sanılması. Zincir sırayla okunur; her adım bir öncekinin açık bıraktığı yeri kapatıyor.

01 Yazma ile publish iki ayrı sistem

Veritabanına INSERT ile kuyruğa publish arasında atomiklik yok. Yazma başarılı olup publish ağ takılmasıyla düşerse veritabanında kayıt vardır ve event hiç yola çıkmamıştır.

02 Mesaj aynı transaction'a yazılır

Mesaj kuyruğa doğrudan basılmıyor; aynı transaction içinde bir outbox tablosuna satır olarak yazılıyor. Kayıt ile mesajın kaderi böylece tek bir işleme bağlanıyor.

03 Relay satırları yayımlar

Ayrı bir relay o satırları okuyup kuyruğa veriyor. Mesajın kaybolmadığı yer burası — ama garantinin tamamlandığı yer değil.

04 Garantiyi idempotent tüketici tamamlar

Outbox at-least-once verir: mesaj kaybolmaz, tekrar edebilir. İşlenen her event id'si aynı transaction içinde processed_messages tablosuna yazılınca tekrar zararsızlaşıyor.

Veri ve sunucu tarafında kapsamım

Veritabanı kararlarını sezgiyle vermiyorum; sunucu tarafında ise kapsam uygulama seviyesinde kalıyor.

• Ölçülmüş index kararları

  Index tercihleri, sorgu planları ve tablo büyüdükçe değişen davranış ölçülerek seçiliyor. Ölçüm olmadan verilen karar, bugün hızlandırdığı sorguyu yarın yavaşlatabiliyor.

• Tam metin arama katmanı

  İlişkisel deponun yetmediği yerde devreye giriyor. Kök bulma, eş anlamlı genişletme ve alakalılık sıralaması ilişkiselde de var; ayrı bir katmanı getiren şey bu işlerin varlığı değil, ölçekte ve çok dilli metinde nereye kadar taşıdığı.

• Uygulama seviyesinde sunucu

  Çalışma ortamının paketlenmesi, test ve dağıtım hattının kurulması, uygulamanın önündeki katmanın yapılandırılması.

Değişikliği güvenli kılan sıra

Arka uçta asıl zorluk yeni bir özelliği yazmak değil, çalışan bir sistemi bozmadan değiştirmek.

01 Şemayı eski ve yeni kodun aynı anda ayakta olduğu pencereye göre planlamak

Eski ve yeni kod bir süre birlikte çalışıyor; şema değişikliği o pencereyi hesaba katmadan yazıldığında kırılan taraf her zaman çalışan sistem oluyor.

02 Veri taşımasını geri alınabilir adımlara bölmek

Tek seferde yürüyen bir taşımanın geri dönüşü yok. Adımlara bölünmüş bir taşıma, yanlış giden adımda durabiliyor.

03 Test yüzeyini üç yerde ayrı tutmak

İş kuralının doğrudan sınandığı yer, dış sınırın taklit edildiği yer ve akışın uçtan uca yürütüldüğü yer. Değişikliğin bedeli, getirdiği rahatlıktan küçük kalmalı.

Altyapıyı mimari konu olarak burada yazmıyorum

Gözlemlenebilirlik, IaC ve rollback stratejisi gibi başlıklar bu sayfada kendi başlarına durmuyor; buradaki kapsamım uygulama seviyesinde kalıyor. Altyapıyı bir mimari konu olarak yazdığım yer sade.dev.