Database And Compute Performance Scaling — AWS Solutions Architect (SAA-C03)
Read replicas and caching solve different bottlenecks
"Read-heavy workload" points toward read replicas or DAX. "Latency for repeated identical queries" points toward ElastiCache. "Write bottleneck on a single instance" points toward Aurora's writer endpoint or sharding, not adding replicas. Candidates treat all database performance problems as signals to add more instances. The exam distinguishes between read distribution, query result caching, connection pooling via RDS Proxy, and write scaling — each solved by a different architectural layer with different cost and consistency implications.
What This Pattern Tests
The exam describes a performance bottleneck and tests the right scaling technique. Read replicas (RDS, Aurora up to 15 replicas) handle read-heavy workloads by distributing SELECT queries. ElastiCache Redis/Memcached handles repeated queries by serving results from memory (microsecond reads vs. millisecond database reads). DynamoDB DAX provides microsecond reads for DynamoDB-specific workloads. Write scaling requires partitioning/sharding (DynamoDB handles this automatically with partition keys). The trap is adding read replicas for a write-bottleneck (replicas only handle reads) or caching for data that changes every second (cache invalidation becomes the bottleneck).
Decision Axis
Bottleneck type determines technique: read-heavy = replicas, repeated queries = cache, write-heavy = partitioning, compute-heavy = scale out.
Associated Traps
Decision Rules
Whether gp3's independently configurable IOPS ceiling — up to 16,000 IOPS decoupled from volume size — fully satisfies the stated workload requirement, making io2's provisioned-IOPS pricing model unnecessary and more expensive.
Whether the access pattern shape — pure key-value lookup with no JOINs at extreme horizontal RPS — disqualifies relational read-replica scaling and mandates migration to a natively partitioned key-value store.
Whether to convert data to a columnar format (Parquet) and add date-based S3 prefix partitioning catalogued in AWS Glue to enable partition pruning and columnar predicate pushdown—versus applying query-level or engine-level changes that leave the full-table scan intact.
Whether to switch DynamoDB from on-demand to provisioned capacity with Auto Scaling when the workload's RCU/WCU volume is stable enough that provisioned pricing plus reserved capacity is materially cheaper than on-demand per-request pricing.
Domain Coverage
Difficulty Breakdown