Workload-Specific Database Design
Start from the access pattern, not the engine name
Every design question on this exam opens with a workload description: a product catalog with wildly varying attributes, a session store needing microsecond latency, a social graph, an append-only audit ledger, or a familiar Oracle schema being lifted. Identify the shape of the data and the query pattern first, then select the engine.
- Relational (RDS/Aurora) - multi-table joins, multi-row ACID transactions, ad-hoc reporting. Aurora adds storage that auto-grows to 128 TiB, up to 15 read replicas, sub-10-second failover and six-way replicated storage across three AZs. RDS is the answer when you need a specific engine or version Aurora does not offer (SQL Server, Oracle, Db2).
- Key-value (DynamoDB) - known access patterns with single-digit-millisecond latency at any scale; the whole design hangs on partition-key cardinality.
- Document (DocumentDB), graph (Neptune) for traversal-heavy relationship queries, in-memory (ElastiCache/MemoryDB), wide-column (Keyspaces), ledger (QLDB), time series (Timestream).
Traps that recur
"Highly available" is not "scalable reads": Multi-AZ is a failover standby that serves no traffic; only read replicas serve reads. DynamoDB capacity mode is a classic discriminator - on-demand for spiky or unknown traffic, provisioned with auto scaling for predictable load. Watch the RCU math: one RCU is one strongly consistent read of up to 4 KB per second, an eventually consistent read costs half, and transactional reads cost double. A global secondary index is always eventually consistent and consumes its own capacity. Elasticache is a cache, never a system of record.
Rule of thumb
If you can enumerate the queries ahead of time, lean DynamoDB; if you need joins you did not anticipate, lean relational. Worked example: a 20 GB catalog, about 5,000 reads/second at peak, spikiness unknown - DynamoDB on-demand, partition key productId for high cardinality, plus a GSI on categoryId for browse queries.