A company runs a MySQL-compatible Amazon Aurora database for its e-commerce platform. The database experiences high write latency during peak hours. The application performs frequent INSERT and UPDATE operations on a table with 50 million rows. The DB instance is db.r5.large with 500 GB of Provisioned IOPS storage. A recent performance analysis shows that the average queue depth is consistently above 32 and write latency exceeds 50 ms. The company needs to reduce write latency without changing the application code. What should a data engineer do?
Increasing instance size provides more CPU and memory, reducing queue depth and write latency.
Why this answer
The high queue depth (consistently above 32) and write latency exceeding 50 ms indicate that the current db.r5.large instance is CPU or I/O constrained for the write workload. Resizing to a larger instance type such as db.r5.xlarge increases the available vCPUs, memory, and network bandwidth, which directly reduces queue depth and write latency by allowing more concurrent write operations to be processed. This solution does not require application code changes and addresses the root cause of insufficient compute capacity for the frequent INSERT and UPDATE operations on the 50-million-row table.
Exam trap
The trap here is that candidates confuse read scaling solutions (Auto Scaling, read replicas) with write performance improvements, or assume that Aurora Serverless v2 automatically solves all performance issues without considering that write latency is often tied to instance size and storage configuration.
How to eliminate wrong answers
Option A is wrong because Aurora Auto Scaling adds reader instances to handle read traffic, not write traffic; write operations are always handled by the writer instance, so adding readers does not reduce write latency. Option B is wrong because converting to Aurora Serverless v2 changes the scaling model but does not guarantee lower write latency; it may even introduce cold start delays or scaling cooldown periods that could worsen latency during peak hours, and it does not directly address the queue depth issue caused by insufficient instance resources. Option D is wrong because creating a read replica and offloading read queries does not affect write latency; write operations still go to the writer instance, which remains the bottleneck.