Bir şirket, sigorta tekliflerini işlemek için AWS üzerinde bir web uygulaması tasarlıyor. Kullanıcılar teklif talebinde bulunuyor. Teklifler teklif türüne göre ayrılmalı, 24 saat içinde yanıtlanmalı ve kaybolmamalıdır. Çözüm, operasyonel verimliliği en üst düzeye çıkarmalı ve bakımı en aza indirmelidir. Hangi çözüm bu gereksinimleri karşılar?

Bu çözüm, gereksinimleri en iyi şekilde karşılar çünkü Amazon SNS ve SQS'in birleşimini kullanarak mesajların kaybolmamasını, 24 saat içinde işlenmesini ve teklif türüne göre ayrılmasını sağlar. SNS mesaj filtrelemesi, farklı teklif türlerini ilgili SQS kuyruklarına yönlendirerek operasyonel verimliliği artırır ve bakım maliyetini düşürür. SQS, mesajların kalıcı olarak depolanmasını ve asenkron olarak işlenmesini garanti eder, bu da 24 saatlik yanıt süresi gereksinimini karşılar. Diğer seçenekler neden doğru değil: Kinesis Data Streams, gerçek zamanlı veri akışı için uygundur ancak her teklif türü için ayrı bir stream oluşturmak ve KCL ile manuel olarak yoklamak, daha fazla yönetim yükü getirir ve SQS'in sağladığı otomatik mesaj yönetimi ve hata toleransını sunmaz. Her teklif türü için ayrı bir Lambda işlevi ve SNS konusu oluşturmak, çözümün karmaşıklığını ve bakım maliyetini artırır. Ayrıca, Lambda'nın doğrudan SNS'e abone olması, mesajların kalıcı olarak depolanması ve yeniden deneme mekanizmaları açısından SQS kadar sağlam değildir. Kinesis Data Firehose ve OpenSearch Service, genellikle log analizi ve arama iş yükleri için kullanılır. Bu senaryoda mesajların işlenmesi ve kuyruğa alınması için aşırı karmaşık ve maliyetli bir çözümdür. Ayrıca, OpenSearch, mesajların kalıcı olarak işlenmesini garanti etmek için bir kuyruk hizmeti değildir.