Zorlaşan dalın içinde genellikle bir iş kuralı vardır
Sipariş güncellemesi zaman aşımına uğrar ve akış yeniden dener. Oysa karşı sistem işlemi kabul etmiştir; akış bunu bilmiyordur. Bir düğüm daha eklemek, tekrar denemenin mükerrer kayıt üretip üretmeyeceğini açıklamaz. Bu soru, okları hangi araçla çizdiğimizden bağımsız olarak işlemin kendisine aittir.
Özel kod sınırını tuvaldeki düğüm sayısıyla belirlemiyoruz. Asıl ölçü, bir işlemin verdiği sözleri bütün akışı açmadan anlatabilmek. Hangi girdiyi kabul eder, neyi değiştirir, yeniden başlatılınca neyi hatırlar? Çağıran taraf beklemeyi bıraktığında sonuç kimin sorumluluğundadır? Servis sınırı bu sorularla ortaya çıkar.
Koordinasyon görünür kalsın
Görsel akışlar yönlendirme, bildirim, zamanlama ve sistemleri birbirine bağlama işlerinde değerlidir. Operasyon ekibi süreci izleyebilir, bir kaydın nerede durduğunu anlayabilir. Bunun yerine sahiplenilmeyen küçük servisler koymak bakımı kolaylaştırmayabilir.
Kapasite konusu ayrıca değerlendirilmelidir. n8n, Redis ve worker süreçleriyle çalışan queue mode seçeneğini belgeliyor. Daha fazla işlem çalıştırmak gerekmesi, akışın yeniden yazılması gerektiği anlamına gelmez. Güncel queue mode belgesi bu altyapı seçimini açıklıyor.
Örnek olarak bir iade akışını düşünelim. Talebi almak, sipariş bilgisini toplamak ve sonucu ilgili ekibe iletmek tuvalde kalabilir. İadenin kabul koşulları ise açık bir sorumluya ve test edilebilir bir sözleşmeye ihtiyaç duyar. Bu kararı ayırmak, akışın operasyonel değerini kaybetmeden karmaşıklığı azaltabilir.
Dağınık parçayı değil, tanımlı işlemi ayırın
İyi bir servis, akış değişkenlerinin rastgele yığınını değil, iade değerlendirme gibi anlamlı bir iş komutunu alır. Yanıtı kabul, ret veya eksik kanıt durumlarını ayırır. Gerekli alanları ve kararı üreten kural sürümünü de belli eder.
Testler anlaşmazlık yaratan örnekleri kapsamalı: kısmen geri ödenmiş sipariş, daha önce değiştirilmiş ürün veya eski bir sipariş referansı. Bunlar akış değişse de anlamını korur. Testleri düğüm adlarına bağlamak ise mevcut kırılganlığı başka bir depoya taşır.
İşin rahatsız edici tarafı sahipliktir. Servisin sürümlerini, güvenlik güncellemelerini, loglarını ve kurtarma sürecini biri yönetmelidir. Bu kişi belli değilse kod ayırmak, görünür bir sorunu görünmez bir soruna dönüştürür. Belgelenmiş kurallarla çalışan düzenli bir akış, geçiş dönemi için daha iyi olabilir.
Kalıcı durumu bilinçli bir sınırın arkasında tutun
Başka bir sistemi değiştiren işlem için gönderimden önce kalıcı bir iş referansı oluşturun. Denemeyi ve sonucunu kaydedin. Sonuç belirsizse zaman aşımını başarısızlık saymak yerine karşı sistemle karşılaştırın. İşlemin doğası uygunsa aynı isteğin tekrarı mevcut sonucu döndürsün.
Yetkileri dar tutun. Ayrılan servis veritabanına erişiyor diye akışın da sınırsız erişime ihtiyacı yoktur. Ortak bir takip referansı, destek ekibinin müşteri verisini her loga kopyalamadan kaydı iki tarafta izlemesini sağlar.
Geçişte geri dönüş yolu bulunmalı. Önce dış sistemlere yazmadan kararları karşılaştırın, farkları inceleyin ve davranış netleşince çağıranı değiştirin. Karşılaştırma sırasında eski ve yeni yol aynı dış işlemi gerçekleştirmemeli.
Bu hafta bir sınır incelemesi yapın
Kurtarma sırasında en çok belirsizlik yaratan akışı seçin. Geri alınamayan işlemleri, saklanan durumu, yeniden deneme kurallarını ve mevcut sorumluyu bir sayfaya yazın. Operasyon ekibinden biri bu sayfayla başarısız bir çalıştırmayı açıklayabilsin.
Yalnız mevcut yerinde temiz biçimde test edilemeyen veya sahiplenilemeyen kuralı ayırın. Framework seçmeden önce girdisini, sonuçlarını ve kurtarma yöntemini belirleyin. Çevresindeki akış görünür kalsın. Başarı ölçüsü küçük bir tuval değil, açıklanabilen ve güvenle devam ettirilebilen bir iştir.