Design High-Performing Architectures
Purpose-Built Databases and Caching
CoreChoose data service and caching from access patterns, consistency, scale, and workload shape.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
The highest-value database decision is the data model and access pattern, not the brand name. Relational, key-value/document, document-compatible, graph, wide-column, in-memory, and warehouse services optimize different operations and impose different constraints.
Must Know
- Write the access patterns first: keys and indexes, joins, graph traversals, document queries, analytical scans, read/write ratio, consistency, latency, and growth.
- DynamoDB is a serverless key-value/document database for known access patterns at scale. Partition-key design and demand distribution determine performance.
- DocumentDB is a managed document database with MongoDB compatibility; verify feature compatibility rather than assuming it is identical to MongoDB.
- Neptune is purpose-built for graph relationships and traversals; Keyspaces is managed Cassandra-compatible wide-column storage.
- Redshift is a managed analytical data warehouse for large-scale columnar analysis, not an OLTP database.
- ElastiCache provides in-memory Redis OSS/Valkey or Memcached-compatible caching according to engine choice and reduces latency/load for reusable data.
- A cache needs an invalidation, expiration, miss, and failure strategy. It accelerates the system of record; it does not replace durability unless explicitly designed as a data store.
- Capacity planning must consider hot keys/partitions, item size, consistency mode, read/write mix, concurrency, and burst behavior.
Compare and Distinguish
- RDS/Aurora vs DynamoDB: relational joins/transactions and flexible relational queries favor RDS/Aurora; predictable key access and serverless horizontal scale favor DynamoDB.
- Time-series vs relational: measurements or events keyed primarily by time, with high ingest, time-window queries, retention/downsampling, and predictable temporal access, can fit a purpose-built time-series database better than a forced relational model.
- DynamoDB vs DocumentDB: key-oriented access and managed scale favor DynamoDB; document query compatibility may favor DocumentDB.
- DocumentDB vs Neptune vs Keyspaces: choose document model, graph traversal, or Cassandra-compatible wide-column access.
- ElastiCache vs read replica: cache wins for repeated hot data and lowest latency with cache semantics; replica wins for broader database reads with database query behavior.
- Redshift vs RDS: analytical scans and aggregation across large datasets favor Redshift; transactional application operations favor RDS/Aurora.
- Cache-aside vs scaling the record: cache-aside reduces repeated reads but adds invalidation/staleness; scale the record when reads cannot tolerate cache semantics.
Scenario examples
- Scenario: A shopping cart uses simple key access at unpredictable scale. Think: DynamoDB matches the access pattern if partition keys distribute demand.
- Scenario: Fraud analysis traverses relationships among identities and devices. Think: graph traversal points to Neptune.
- Scenario: Dashboards aggregate years of fact data. Think: Redshift fits warehouse analysis, not an OLTP replica.
- Scenario: A product page repeatedly reads the same records and accepts short staleness. Think: ElastiCache can reduce latency and database load.
Exam traps
- DynamoDB does not remove the need to design partition keys and indexes.
- A cache is not automatically strongly consistent with its source.
- DocumentDB compatibility is not identity with every MongoDB feature.
- Neptune is not selected merely because records contain relationships; traversal access must be central.
- Redshift is not a low-latency transactional database.
- Adding a cache can make correctness worse if invalidation is undefined.
Key takeaways
- Let data model and access pattern eliminate database families first.
- Use DynamoDB for key-oriented scale, Neptune for graph, Keyspaces for Cassandra compatibility, DocumentDB for compatible document workloads, and Redshift for warehousing.
- Use caches to offload repeatable reads, not to conceal a mismatched record store.
- Plan distribution and hot-key behavior before demand arrives.
How it works
- DynamoDB partitions data by key and routes operations to the responsible partitions; uneven keys can concentrate demand.
- Graph databases store vertices/edges for traversals; wide-column stores organize data for partitioned access; warehouses optimize columnar analytical processing.
- Cache clients populate or update in-memory entries according to the chosen strategy and fall back to the record store on misses.
When to use it
- Use DynamoDB for predictable key-based serverless access, DocumentDB for compatible document workloads, Neptune for graphs, Keyspaces for Cassandra compatibility, and Redshift for analytics.
- Use ElastiCache for low-latency reusable data, sessions, counters, or other compatible in-memory patterns.
- Use relational services when integrity constraints, joins, and transactional SQL are the hard requirements.
Security and governance implications
- Encrypt databases and network paths and scope application roles to required tables/clusters/resources.
- Treat cached sensitive data with the same classification and network controls as its source.
- Back up systems of record and test recovery; do not assume cache persistence is the recovery plan.
- Monitor hot keys, rejected/throttled demand, replica lag, evictions, and capacity signals.
Operational and diagnostic signals
- For DynamoDB throttling, inspect partition-key distribution and access patterns before simply raising total capacity.
- For stale cache results, inspect expiration and invalidation ownership.
- For purpose-built compatibility issues, confirm query/driver/feature requirements against the selected engine.
- For slow analytics, distinguish data layout, scan volume, concurrency, and source-system mismatch.
More detail
- Purpose-built services trade generality for managed optimization. The application accepts each service's query, consistency, and operational model.
- DynamoDB can use on-demand or provisioned capacity; the better choice depends on predictability and utilization, not a universal preference.
- Indexes and replicas consume resources and can change write cost or consistency behavior; add them for named access patterns.
- Caching shifts some load away from the record store but adds memory sizing, eviction, staleness, and availability decisions.
Ready for the quiz?
- What access pattern favors DynamoDB over Aurora?
- When does Neptune beat a relational join model?
- Why is Redshift not an RDS read replica?
- When does ElastiCache beat another database replica?
- What makes a partition key healthy?
Related objectives
- D2.1.K3
- D3.3.K2
- D3.3.K3
- D3.3.K4
- D3.3.K8
- D3.3.S4
- D3.3.S5