Bir acente kullanıcısı kasko sorgusu başlattığında, arka planda birden fazla sigorta şirketinin servisine istek gider. Her şirketin yanıt süresi, kapasitesi ve hata davranışı farklıdır. Sabah saatlerinde, ay sonlarında veya yenileme yoğunluğunun arttığı dönemlerde bu isteklerin sayısı hızla yükselir. Bütün bu trafiği doğrudan, senkron çağrılarla yönetmeye çalışan bir sistem, en yavaş şirketin hızına mahkûm olur. Mesaj kuyruğu, bu bağımlılığı kırmanın en olgun yöntemlerinden biridir.
Senkron çağrı zincirinin sınırları
Senkron modelde kullanıcı isteği, web sunucusunda bir iş parçacığını meşgul eder ve bütün şirket yanıtları gelene kadar bekletir. Bu modelin üç temel sorunu vardır:
- Kaynak tükenmesi: Bekleyen her istek bellek ve bağlantı tüketir. Yoğun anlarda yeni kullanıcılar sisteme giremez hale gelir.
- Kırılgan zincir: Tek bir şirket servisinin yavaşlaması, bütün isteğin süresini uzatır.
- Kayıp işler: Sunucu yeniden başlatıldığında o an işlenmekte olan sorgular iz bırakmadan kaybolur.
Kuyruk tabanlı modelin bileşenleri
Kuyruk tabanlı modelde kullanıcı isteği kabul edilir, bir iş kaydı oluşturulur ve her şirket için ayrı birer mesaj kuyruğa bırakılır. Kullanıcıya hemen bir sorgu kimliği dönülür. Arka planda çalışan işçiler (worker) kuyruktan mesajları alır, ilgili şirket servisini çağırır ve sonucu kaydeder. Sonuçlar geldikçe arayüze akıtılır.
Üretici, kuyruk ve tüketici
Bu yapıda web uygulaması üretici, işçiler ise tüketici rolündedir. Aradaki kuyruk bir tampon görevi görür. Üretici ne kadar hızlı mesaj üretirse üretsin, tüketiciler kendi kapasitelerine göre işler. Ani bir yoğunlukta kuyruk büyür ama sistem çökmez; yoğunluk geçtikçe kuyruk erir.
Branş bazlı kuyruk ayrımı
Trafik, kasko ve DASK sorguları farklı veri girdileri ve farklı şirket uç noktalarıyla çalışır. Bu nedenle tek bir ortak kuyruk yerine branş bazlı kuyruklar kullanmak mantıklıdır. Böylece kasko sorgularının uzun sürdüğü bir anda trafik sorguları aynı kuyrukta sıra beklemez. Gerekirse branş başına işçi sayısı da ayrı ayrı ayarlanabilir.
Geri basınç: Kuyruğun sınırsız büyümesini önlemek
Kuyruk bir tampondur ama sonsuz değildir. Bir şirket servisi uzun süre yanıt vermezse o şirkete ait mesajlar birikir. Geri basınç (backpressure), sistemin bu durumda kendini korumasını sağlayan mekanizmaların genel adıdır:
- Şirket başına eşzamanlılık sınırı: Her şirkete aynı anda gönderilebilecek istek sayısı sınırlanır. Bu hem karşı servisi korur hem de bir şirketin bütün işçileri meşgul etmesini engeller.
- Mesaj ömrü: Teklif sorguları zamana duyarlıdır. Kullanıcı ekranı kapattıktan çok sonra işlenen bir sorgunun değeri kalmaz. Belirli bir süreyi aşan mesajlar işlenmeden düşürülür ve sonuç "zaman aşımı" olarak kaydedilir.
- Kuyruk derinliği alarmı: Kuyruktaki mesaj sayısı belirli bir eşiği aştığında operasyon ekibi uyarılır.
Mesaj tasarımında dikkat edilecekler
Kuyruğa bırakılan mesaj, işçinin işi tamamlaması için gereken her şeyi içermeli ama gereksiz veri taşımamalıdır. İyi bir mesaj; sorgu kimliğini, acente kimliğini, branşı, hedef şirketi, oluşturulma zamanını ve deneme sayısını içerir. Kimlik numarası, plaka veya adres gibi sorgu girdileri ise mümkünse mesajın içine değil, erişimi kontrollü bir kayıt alanına yazılır ve mesajda yalnızca referansı taşınır. Bu, kuyruk altyapısının loglarında kişisel veri birikmesini önler.
Mesajın en az bir kez teslim edileceği varsayılmalıdır. Yani aynı mesaj, nadiren de olsa iki kez işlenebilir. İşçiler, aynı sorgu kimliği ve aynı şirket için sonuç zaten kaydedilmişse işi tekrar yapmayacak şekilde tasarlanmalıdır.
Sonuçların kullanıcıya akışı
Kuyruk modelinde sonuçlar farklı zamanlarda gelir. Kullanıcının tüm yanıtları beklemesi yerine, her şirketin sonucu geldikçe ekranda belirmesi daha iyi bir deneyim sunar. Bu akış; kısa aralıklı sorgulama, sunucu tarafından gönderilen olaylar veya satır satır JSON akışı gibi yöntemlerle sağlanabilir. Hangi yöntem seçilirse seçilsin, arayüz her şirket için "bekleniyor", "yanıt geldi", "hata" ve "zaman aşımı" durumlarını ayrı ayrı gösterebilmelidir.
Operasyonel görünürlük
Kuyruk tabanlı bir sistemi yönetmek, birkaç temel göstergeyi sürekli izlemeyi gerektirir:
- Kuyruk başına bekleyen mesaj sayısı
- Bir mesajın kuyrukta bekleme süresi
- Şirket bazında işleme süresi ve hata oranı
- Zaman aşımına düşen mesajların oranı
Bu göstergeler, sorunun acente yazılımında mı yoksa belirli bir şirket servisinde mi olduğunu hızla ayırt etmeyi sağlar.
Öncelikli kuyruklar ve adil paylaşım
Her sorgu aynı aciliyette değildir. Müşteri karşıdayken başlatılan bir sorgu ile gece toplu olarak hazırlanan yenileme teklifleri aynı sırayı beklememelidir. Bu ayrım için iki yöntem kullanılabilir: Etkileşimli sorgular için ayrı ve önceliği yüksek bir kuyruk tanımlamak ya da toplu işlerin işçi kapasitesinin yalnızca belirli bir bölümünü kullanmasına izin vermek. Çok kiracılı bir platformda buna ek olarak tek bir acentenin çok büyük bir toplu işinin diğer acentelerin sorgularını geciktirmemesi gerekir. Acente başına eşzamanlı iş sınırı, bu adil paylaşımı sağlamanın basit bir yoludur.
İşçilerin güvenli kapatılması
Yeni sürüm yayınlanırken veya sunucu bakıma alınırken işçiler aniden durdurulmamalıdır. Güvenli kapatma sürecinde işçi yeni mesaj almayı bırakır, elindeki işi tamamlar ve ancak sonra kapanır. Mesaj, işçi tarafından açıkça onaylanana kadar kuyrukta görünmez durumda bekler; işçi beklenmedik biçimde çökerse belirli bir süre sonra yeniden görünür hale gelir ve başka bir işçi tarafından alınır. Bu onay mekanizması, kuyruk tabanlı mimarinin "kayıp iş" sorununu çözen asıl parçadır.
InsureHub'da kuyruk yaklaşımı
InsureHub, sigorta acentelerine yazılım sağlarken teklif motorunu web panelinden ayrı çalışan, uzun süren işlemleri arka planda yürüten bir yapı olarak ele alır. Bu sayede sigorta teklif programı ekranında bir şirketin gecikmesi, diğer şirketlerin sonuçlarının görüntülenmesini engellemez. Aynı yaklaşım, mobil sigorta uygulaması üzerinden başlatılan sorgular için de geçerlidir.
Yoğun dönemlerde sisteminizin nasıl davrandığını anlamak için tek bir soru yeterli olabilir: Bir şirket servisi tamamen yanıt vermediğinde, diğer şirketlerin sonuçları yine de ekrana geliyor mu? Cevap evetse, kuyruk ve geri basınç mekanizmaları büyük ölçüde doğru çalışıyordur.