Bir şirket, Amazon API Gateway API tarafından çağrılan AWS Lambda işlevlerinde bir uygulama barındırıyor. Lambda işlevleri müşteri verilerini bir Amazon Aurora MySQL veritabanına kaydeder. Şirket veritabanını her yükselttiğinde, yükseltme tamamlanana kadar Lambda işlevleri veritabanı bağlantıları kuramıyor ve bu da bazı olaylar için müşteri verilerinin kaybolmasına neden oluyor. Bir çözümler mimarının, veritabanı yükseltmeleri sırasında oluşturulan müşteri verilerini depolayan bir çözüm tasarlaması gerekiyor. Hangi çözüm bu gereksinimleri karşılar?

Doğru cevap, müşteri verilerini bir Amazon SQS FIFO kuyruğunda depolamak ve bu kuyruğu yoklayan bir Lambda işlevi oluşturmaktır. Bu yaklaşım, veritabanı yükseltmeleri sırasında bile veri kaybını önler çünkü Lambda işlevleri verileri doğrudan veritabanına yazmak yerine SQS kuyruğuna gönderir. Kuyruk, veritabanı tekrar erişilebilir olduğunda işlenecek verileri güvenli bir şekilde tutar. FIFO (First-In, First-Out) kuyruğu, mesajların gönderildiği sırayla işlenmesini sağlayarak veri bütünlüğünü korur. Diğer seçenekler neden uygun değil: Amazon RDS Proxy sağlamak, bağlantı havuzlaması ve daha hızlı bağlantı kurma gibi faydalar sunsa da, veritabanı yükseltme sırasında veritabanı erişilemez olduğunda veri kaybını doğrudan engellemez. Lambda işlevlerinin çalışma süresini artırmak ve yeniden deneme mekanizması eklemek, geçici kesintiler için faydalı olabilir ancak uzun süreli veritabanı yükseltmelerinde yine de veri kaybına yol açabilir veya Lambda'nın maksimum çalışma süresini aşabilir. Müşteri verilerini Lambda yerel depolama alanına kalıcı olarak kaydetmek mümkün değildir; Lambda işlevleri durum bilgisizdir ve yerel depolama, işlev çağrıları arasında kalıcı değildir. Ayrıca, bu depolama boyutu sınırlıdır ve kalıcı veri depolama için tasarlanmamıştır.