Bir şirketin sipariş uygulaması, müşteri verilerini Amazon RDS for MySQL'de depolamaktadır. Mesai saatleri içinde, çalışanlar tek seferlik raporlama sorguları çalıştırır ve bu sorgular uzun süreli okumalara neden olarak sipariş işleme sırasında zaman aşımlarına yol açar. Şirket, zaman aşımlarını ortadan kaldırmalı ancak yine de çalışanların sorguları çalıştırmasına izin vermelidir. Bir çözümler mimarı bu gereksinimleri karşılamak için ne yapmalıdır?

Doğru cevap, bir read replica oluşturup raporlama sorgularını bu kopyaya yönlendirmektir. Amazon RDS read replica'ları, birincil veritabanının yükünü azaltarak okuma yoğunluklu iş yüklerini ayrı bir veritabanı örneğine aktarır. Bu sayede, sipariş işleme gibi kritik işlemler birincil veritabanında kesintisiz devam ederken, raporlama sorguları read replica üzerinde çalıştırılabilir ve zaman aşımları önlenir. Diğer seçenekler neden yanlış: "Bir read replica oluşturun. Sipariş uygulamasını birincil DB instance'a ve read replica'ya dağıtın." seçeneği, sipariş uygulamasının hem birincil hem de read replica'ya dağıtılması, yazma işlemlerinin hala birincil veritabanında yoğunlaşmasına neden olacağı için sorunu çözmez. Read replica'lar sadece okuma işlemleri içindir. "Sipariş uygulamasını on-demand kapasiteli Amazon DynamoDB'ye geçirin." seçeneği, mevcut RDS for MySQL mimarisini tamamen değiştiren, daha kapsamlı ve maliyetli bir çözümdür. Sorun sadece raporlama sorgularının neden olduğu okuma yükü olduğundan, bu kadar radikal bir değişiklik gereksizdir. "Raporlama sorgularını yoğun olmayan saatler için planlayın." seçeneği, çalışanların mesai saatleri içinde sorgu çalıştırma ihtiyacını karşılamaz ve operasyonel esnekliği kısıtlar.