Bir şirket yemek dağıtım hizmeti işletmektedir. Son zamanlardaki büyüme nedeniyle, şirketin sipariş işleme sistemi yoğun trafik saatlerinde ölçeklendirme sorunları yaşamaktadır. Mevcut mimari, bir uygulamadan siparişleri toplayan bir Auto Scaling grubundaki Amazon EC2 örneklerini içerir. İkinci bir Auto Scaling grubundaki EC2 örnekleri siparişleri yerine getirir. Sipariş toplama süreci hızlı gerçekleşirken, sipariş karşılama süreci daha uzun sürebilir. Ölçeklendirme olayları nedeniyle veri kaybı yaşanmamalıdır. Bir çözümler mimarı, hem sipariş toplama sürecinin hem de sipariş karşılama sürecinin yoğun trafik saatlerinde yeterince ölçeklenebilmesini sağlamalıdır. Bu gereksinimleri hangi çözüm karşılar?

Doğru cevap, iki Amazon SQS kuyruğu kullanmayı ve Auto Scaling gruplarını her kuyruktaki mesaj sayısına göre ölçeklendirmeyi önerir. Bu yaklaşım, sipariş toplama ve sipariş karşılama süreçleri arasındaki hız farkını etkili bir şekilde yönetir. SQS, siparişlerin güvenli bir şekilde depolanmasını sağlayarak veri kaybını önler ve asenkron işleme için bir arabellek görevi görür. Auto Scaling gruplarının kuyruktaki mesaj sayısına göre ölçeklenmesi, sistemin yoğun trafik saatlerinde talebe göre dinamik olarak ölçeklenmesine olanak tanır, böylece performans sorunları önlenir. Diğer seçenekler neden yanlış: CPUUtilization metriğini izlemek ve minimum kapasiteyi en yüksek iş yüküne ayarlamak, sürekli olarak yüksek maliyetlere yol açar ve dinamik ölçeklendirme sağlamaz. SNS konusu aracılığıyla ek Auto Scaling grupları oluşturmak, karmaşık bir çözümdür ve SQS'in sağladığı arabellekleme ve veri kaybı önleme avantajlarını sunmaz. Auto Scaling gruplarını kuyrukların gönderdiği bildirimlere göre ölçeklendirmek, SQS'in doğrudan kuyruk derinliğine göre ölçeklendirme yeteneğini kullanmaz ve daha az verimli olabilir.