Editörden

‘Veritabanına yaz, sonra kuyruğa mesaj at’ cümlesi iki ayrı sistemin tek işlemde buluşmasını varsayar ve çoğu zaman yanlış gider. Google, mesajı veritabanı işleminin içine alarak bu açığı kapatıyor. Cloudflare ise gözlemlenebilirliği tek çatıda topluyor.

Günün Kapağı
Google Cloud Blog 2 Ekim 20265 dk okuma orta

Mesaj göndermek veritabanı yazmasının parçası olunca: Spanner queues

Spanner queues provide native transactional messaging

Yapay zekâ agent’ları iade başlatmak, stok yönetmek ya da alt agent’lara iş devretmek gibi eylemler yapıyor. Bunun için durumu bir operasyonel veritabanında tutuyor, eylemleri ise ayrı bir mesajlaşma ya da olay kuyruğuna gönderiyor. İki sistemin ayrı işlem noktaları olduğu için tutarsızlık kaçınılmaz: durum güncellenir ama mesaj gitmez (agent karar verir ama eylem olmaz), ya da mesaj gider ama durum işlemi geri alınır (agent geçersiz duruma göre hareket eder). Çözüm olarak geliştiriciler outbox deseni, idempotency katmanları ve uzlaştırma işçileri yazmak zorunda kalıyor.

Google Spanner queues’u genel kullanıma açtı: mesaj oluşturmak, aynı işlemin içinde sıradan bir yazma. Durum değişikliği ve niyet edilen eylem birlikte kesinleşir ya da birlikte başarısız olur. Özellikler arasında mesajı hemen ya da ileri bir zamana planlama (geciken yeniden denemeler, SLA zamanlayıcıları), agent işçileri için akışlı SQL okuma ve kuyruk tablolarını standart SQL ile inceleyerek gözlemleme var. Garanti en az bir kez teslimat; yani tüketici tarafı yine idempotent yazılmalı.

Yazı agent senaryosuna odaklansa da kuyruğun yalnızca agent’lar için olmadığını da belirtiyor: etkinlik akışları ve canlı güncellemeler gibi klasik olay tabanlı mimarilerde de kullanılabilir.

Öne çıkanlar

  • Veritabanı ve kuyruk ayrı sistemlerse ‘ikisi birden’ garantisi yoktur.
  • Mesajı işlemin parçası yapmak, outbox desenini platform özelliğine çevirir.
  • En az bir kez teslimat tüketicinin idempotent olmasını yine gerektirir.
  • Kuyruğu SQL ile sorgulayabilmek, takılan işi bulmayı kolaylaştırır.

Neden önemli?

‘Dual write’ sorunu (iki sisteme ayrı yazmak) dağıtık sistemlerin klasik hatasıdır. Çözümü ya veritabanının içine kuyruk almak ya da outbox deseni uygulamaktır; her iki yaklaşım da aynı fikri paylaşır.

Sende karşılığı

Bunu Spring Boot’ta bugün transactional outbox ile uygulayabilirsin: iş verisini ve gönderilecek mesajı aynı Postgres işleminde outbox tablosuna yaz, ayrı bir işçi bu tabloyu okuyup mesajı gönderip satırı işaretlesin. Mobit’te bir doküman yüklendiğinde ‘indeksle’ işini bu yolla tetiklersen, yükleme kaydedilip indeksleme isteği kaybolmaz. Tüketici tarafında aynı mesajın iki kez gelme ihtimaline karşı bir message_id ile tekrarı yok say. Bu, mülakatlarda sık sorulan bir soru.

Sözlük

transactional outbox işlemsel gönderi kutusu
Mesajı iş verisiyle aynı işlemde bir tabloya yazıp ayrı bir süreçle iletme deseni.
dual write çift yazma
Aynı değişikliği iki ayrı sisteme ayrı ayrı yazmaya çalışmak; tutarsızlık riski taşır.
at-least-once delivery en az bir kez teslimat
Bir mesajın kaybolmaması ama ara sıra birden fazla kez iletilebilmesi.
idempotency idempotans
Aynı işlemin birden fazla kez uygulanmasının sonucu değiştirmemesi.
Orijinali oku

Kısa Kısa

Cloudflare Blog 2 Ekim 20267 dk okuma orta

Günlük, iz ve analiz tek yerde: Cloudflare Observability’de sekiz güncelleme

8 major updates to Cloudflare Observability

Cloudflare, loglarını, izlerini (trace), analizlerini, uyarılarını, panolarını ve dışa aktarmayı tek bir gözlemlenebilirlik platformunda birleştiren sekiz güncelleme duyurdu. Gerekçe şu: 5xx artışı bir Worker’dan, kaynak sunucudan ya da Cloudflare’in kaynağa bağlanamamasından gelebilir ve bugün hangi sinyalin hangi ürüne ait olduğunu bilmek gerekiyor.

Öne çıkanlar: Logs artık Workers Observability ile Log Explorer’ı birleştiriyor (HTTP, güvenlik duvarı, Workers, R2, AI Gateway gibi veri kümeleri aynı arayüzde); Cloudflare Traces açık beta’da, isteğin güvenlik kuralları, önbellek kararları, yönlendirme ve Workers adımlarını gösteriyor ve OpenTelemetry ile dışa aktarılıyor; agent’lar için birleşik bir SQL API beta’da; ve tüm kayıt ve iz saklama için yeni birleşik fiyatlandırma 1 Aralık 2026’dan itibaren geçerli olacak.

  • Sorun çözerken ‘hangi araca bakmalıyım’ sorusu azalırsa teşhis süresi kısalır.
  • İz (trace) ile günlük (log) birbirine bağlanınca tek isteğin yolculuğu izlenebilir.
  • OpenTelemetry ve W3C trace context, farklı sistemler arasında iz taşımayı standartlaştırıyor.

Sende karşılığı

Spring Boot uygulamana Micrometer Tracing ve OpenTelemetry ekleyip her isteğe bir trace id ver, log satırlarına da bu kimliği yaz. Bir hata olduğunda tek bir kimlikle o isteğin tüm adımlarını bulabilmek, gözlemlenebilirliğin en temel kazanımı.

Sözlük

distributed tracing dağıtık izleme
Bir isteğin birden çok servis boyunca izlediği yolu tek bir iz olarak kaydetme.
OpenTelemetry OpenTelemetry
Günlük, metrik ve izleri toplamak için kullanılan açık standart ve araç seti.
Orijinali oku

Önceki Sayılar

Tüm arşivi gör