Asenkron işlemeye geçiş
Yan etkileri kritik yanıt yolundan ayırmak — dayanıklı, izlenebilir ve mükerrer işlemleri önleyen (idempotent) biçimde.
Bu nedir? · Uygulama kılavuzu
Sürekli karşılaşılan bir problem için standart bir süreç — durum, adımlar, karar kriterleri ve validasyon. Neden uyguladığımız değil, nasıl uyguladığımız. Genel bakışa git
Bu kılavuz ne zaman geçerli?
İşlemler yavaş veya güvenilmez yan etkiler tetikler: bildirimler, dışa aktarımlar, üçüncü taraf sistem çağrıları. Senkron tutulduklarında yanıt süresini ve başarıyı dahil olan en yavaş sisteme bağlarlar.
Hedefler
- Yanıt süresi yavaş yan etkilerden ayrışmıştır.
- Yan etkiler hatalara ve yeniden denemelere karşı dayanıklıdır.
- İşletim izlenebilir kalır.
Tipik riskler
- At-least-once teslimat nedeniyle mükerrer etkiler.
- Yeniden deneme veya teslimat kanıtı olmadan kaybolan job'lar (fire-and-forget).
- Canlı ortamda görünmeyen kuyruklar ve worker'lar.
- Kullanıcı arayüzünün dikkate almadığı eventual consistency.
Geliştirmeye başlamadan önce.
- Kritik yanıt yolunu, dışarı alınabilecek yan etkilerden ayırmak.
- Teslimat semantiğini ve idempotency stratejisini belirlemek.
- Kuyruk, worker'lar ve başarısız job'lar için izlemeyi planlamak.
Nasıl ilerliyoruz?
Yalnızca kritik yolun dışında
Yanıt için kritik olan her şey senkron kalır. Kuyruğa yalnızca ayrıştırılabilen yan etkiler taşınır.
Idempotency zorunludur
Her job mükerrer işlemleri önleyen (idempotent)tir: Bir idempotency anahtarı, etkiyle aynı transaction içinde kontrol edilir ve kalıcı hâle getirilir. Böylece at-least-once teslimat mükerrer etkiler üretmez.
Baştan itibaren görünürlük
İş hacmi, çalışma süreleri ve başarısız job'lar görünürdür. Yeniden denemeler ve dead-letter yönetimi açıkça tanımlanmıştır.
Eventual consistency'yi bilinçli ele almak
Kullanıcı arayüzü, anında tutarlılık varmış gibi davranmak yerine bir etkinin işlenmekte olduğunu bildirir (örneğin 202 Accepted ile).
Yanıt bekleyen sorular.
İşlem gerçekten kritik yanıt yolunun dışında mı?
Job mükerrer işlemleri önleyen (idempotent) mi?
Yeniden deneme ve hata yolları tanımlı mı?
Kullanıcı arayüzü eventual consistency'yi dikkate alıyor mu?
Doğrulama
- Mükerrer teslimatın mükerrer bir etki üretmediği kanıtlanmıştır.
- Başarısız job'lar görünürdür ve yeniden çalıştırılabilir.
- Kritik yolun gecikmesi ayrıştırılmış ve ölçülmüştür.
Sık yapılan hatalar
- Kritik mantığı asenkron yapıp tutarlılığı kaybetmek.
- Yeniden deneme ve teslimat kanıtı olmadan fire-and-forget.
- Idempotency'yi unutmak — mükerrer kayıtlar, mükerrer e-postalar.
- Kuyrukları ve worker'ları izleme olmadan işletmek.
Ne zaman bilinçli olarak farklı ilerliyoruz?
- Bir işlem küçük, hızlı ve yanıt için kritikse senkron kalır — asenkronluk gereksiz bir karmaşıklık olurdu.
- Çok basit ve seyrek görevler için zamanlanmış bir batch işi, kuyruktan daha ekonomik olabilir.
İlgili Engineering Method aşamaları
Mühendislik yolculuğunuza devam edin.
Bağlantılı kavramlar, stratejik kararlar, rehberler ve yaklaşımlar — bir link yığını olarak değil, tutarlı bir akış halinde.
Mühendislik kararları
Bakış açıları
Benzer bir zorlukla mı karşı karşıyasınız?
Uygulama kılavuzları nasıl düşündüğümüzü gösterir. Somut projeniz için yönetimimizle görüşün: teknik düzeyde, satış konuşması olmadan.
