A company runs a critical e-commerce platform on Amazon Aurora MySQL. The database is 2 TB and experiences a sudden spike in write latency during flash sales. The application uses auto-generated UUIDs as primary keys. The CPU utilization on the writer instance is 80%, and the read replicas show low utilization. Write latency has increased from 5 ms to 200 ms. The company needs to reduce write latency with minimal application changes. Which course of action is MOST effective?
Sequential keys reduce index page splits, improving write performance.
Why this answer
B is correct because UUID primary keys cause random writes that fragment the B-tree index, leading to frequent page splits and high write latency. Changing to an auto-increment BIGINT allows sequential writes, which fill index pages contiguously and reduce the write amplification that drives latency from 5 ms to 200 ms. This requires no application logic changes beyond the schema migration, making it the most effective minimal-change solution.
Exam trap
The trap here is that candidates assume scaling compute or storage (Option D) is the universal fix for write latency, but the exam specifically tests the impact of primary key design on index write amplification in Aurora MySQL.
How to eliminate wrong answers
Option A is wrong because sharding across multiple Aurora clusters adds significant application complexity (e.g., distributed transactions, cross-cluster joins) and does not address the root cause of random-write overhead from UUIDs. Option C is wrong because read replicas cannot handle write traffic; they only serve read queries, so redirecting write-heavy queries to replicas is impossible and would not reduce write latency on the writer instance. Option D is wrong because upgrading the instance type with more IOPS only masks the symptom of high write latency; it does not fix the underlying index fragmentation caused by UUID primary keys, so the latency will persist after the upgrade.