Bir şirket, herkese açık film verilerini depolamak için bir Amazon RDS Single-AZ DB instance üzerinde çalışan bir SQL veritabanı kullanıyor. Her gün rastgele aralıklarla çalışan bir betik, eklenen yeni film sayısını kaydediyor. Betiğin mesai saatleri içinde nihai bir toplam raporlaması gerekiyor. Geliştirme ekibi, betik çalışırken veritabanı performansının geliştirme görevleri için yetersiz olduğunu fark ediyor. Bir çözümler mimarı, EN AZ operasyonel yük ile bir çözüm önermelidir. Bu gereksinimi hangi çözüm karşılar?

Doğru cevap, veritabanının bir read replica'sını oluşturmak ve betiği yalnızca read replica'yı sorgulayacak şekilde yapılandırmaktır. Bunun nedeni, okuma çoğaltmalarının (read replicas) ana veritabanının performansını etkilemeden okuma yoğunluklu iş yüklerini boşaltmasıdır. Betik, ana veritabanı yerine çoğaltmadan okuma işlemleri yaparak, geliştirme ekibinin ana veritabanını kullanırken performans düşüşü yaşamasını engeller. Bu, operasyonel yükü en aza indirir çünkü mevcut mimariye minimal değişiklikler getirir ve otomatik olarak yönetilir. DB instance'ı Multi-AZ dağıtımına dönüştürmek, felaket kurtarma ve yüksek erişilebilirlik için tasarlanmıştır, okuma performansını doğrudan artırmaz. Geliştirme ekibine verileri manuel olarak dışa aktarmalarını söylemek, operasyonel yükü artırır ve otomatik bir çözüm değildir. Amazon ElastiCache kullanmak, sık sorgulanan veriler için performansı artırabilir ancak betiğin her gün rastgele aralıklarla çalışan ve muhtemelen farklı verileri sorgulayan yapısı için en uygun çözüm değildir ve daha fazla operasyonel karmaşıklık getirir.