9 · Database & Caching Performance¶

Domain 3 — Design High-Performing Architectures · 24%

Two judgments dominate: relational (RDS/Aurora) vs NoSQL (DynamoDB) for the primary datastore, and which cache to bolt on for read performance — ElastiCache (and Redis vs Memcached), DAX, or CloudFront. The exam picks winners by matching the data model and the thing being cached.

Core concept¶

Pick the database by data model and scale, then add a cache to cut latency and offload reads:

Relational (RDS, Aurora) — structured data, joins, complex queries, transactions (ACID), fixed schema. The default when the scenario says "SQL", "joins", "transactions", or migrating an existing relational DB.
NoSQL (DynamoDB) — key-value / document, massive scale, predictable single-digit-millisecond latency, serverless, flexible schema. The default for "millions of requests", "key-value", "serverless", "any scale without managing servers".

Then layer caching where it helps most — in front of the database, or at the edge in front of the app.

Relational vs NoSQL¶

Need	Choose
Complex queries, joins, transactions, existing SQL app	RDS (or Aurora for cloud-native scale/resilience)
Massive scale, key-value/document, single-digit-ms, serverless	DynamoDB
Cloud-native relational with high resilience + auto-scaling storage	Aurora (6 copies/3 AZ — see Topic 5)

For read scaling on RDS, add read replicas; for serverless connection storms (e.g. many Lambda functions exhausting DB connections), put RDS Proxy in front to pool connections.

Which cache? (the exam's real question)¶

Cache	Sits in front of	Use when
ElastiCache (Redis/Memcached)	RDS / relational (or general app cache, session store)	Offload repeated reads from a relational DB; store sessions to make the app stateless
DynamoDB Accelerator (DAX)	DynamoDB	Read-heavy DynamoDB needing microsecond reads; DynamoDB-API-compatible (minimal code change)
CloudFront	Static/dynamic web content at the edge	Cache content near global users, cut latency, offload the origin

Key reflex: DAX caches DynamoDB; ElastiCache caches a relational DB; CloudFront caches web content at the edge. Swapping these is a classic distractor (e.g. "ElastiCache for DynamoDB microsecond reads" is wrong — that's DAX).

Redis vs Memcached (ElastiCache)¶

	Redis	Memcached
Data types	Rich (lists, sets, sorted sets, pub/sub)	Simple key-value
Replication / HA	Yes — Multi-AZ, automatic failover, backups	No replication, no persistence
Persistence / backup	Yes	No
Scaling	Cluster mode (sharding) + replicas	Multi-threaded, simple horizontal sharding
Choose when	HA, durability, sorted-set/leaderboard, session store	Simple, ephemeral cache; pure horizontal scale-out

Reflex: need HA / persistence / advanced structures → Redis; simple, multi-threaded, throwaway cache → Memcached.

Caching strategies & session stores¶

Lazy loading (cache-aside) — read cache first; on a miss, read the DB and populate the cache. Only requested data is cached, but a miss pays a DB round-trip and data can go stale.
Write-through — write to the cache and DB together, so the cache is always current, at the cost of writing data that may never be read.
Session store — keep user session state in ElastiCache (or DynamoDB) so any instance can serve any user → the app tier becomes stateless, which is what lets an ASG/ELB scale cleanly (ties back to Topic 4).

Worked example — three "caches" for three different layers¶

An application has: (1) a DynamoDB table serving a read-heavy leaderboard that now needs microsecond reads; (2) a relational reporting query hitting RDS repeatedly with the same results; and (3) images served slowly to users worldwide. A teammate says "just put ElastiCache in front of all three."

What's actually right for each?

Answer

Three different tools:

DynamoDB microsecond reads → DAX, not ElastiCache. DAX is purpose-built for DynamoDB and is API-compatible, so it needs minimal code change.
Repeated relational query results → ElastiCache in front of RDS (lazy-loading the query results). (Redis if you want HA/persistence.)
Slow global image delivery → CloudFront, caching the images at edge locations near users.

Using ElastiCache for all three is the trap — each caching layer targets a different backend.

Exam traps¶

DAX = DynamoDB cache (microseconds); ElastiCache = relational/app cache; CloudFront = edge content cache. Don't swap them.
"Microsecond reads for DynamoDB" → DAX, never ElastiCache.
Redis for HA/persistence/advanced data types; Memcached for simple multi-threaded ephemeral cache.
Relational (joins/transactions/SQL) → RDS/Aurora; key-value at massive scale → DynamoDB.
Session state → ElastiCache/DynamoDB to make the app stateless (enables clean scaling).
Read replicas scale reads; a cache offloads repeated reads — different tools, sometimes both.
Serverless connection exhaustion on RDS → RDS Proxy (connection pooling).

Practice questions¶

Q1. A read-heavy application on DynamoDB requires microsecond read latency for hot items, with minimal changes to its existing DynamoDB API calls. What should be added?

A. Amazon ElastiCache for Redis
B. DynamoDB Accelerator (DAX)
C. Amazon CloudFront
D. An RDS read replica

Answer: B

B. DAX is a managed in-memory cache purpose-built for DynamoDB, delivering microsecond reads and API compatibility (minimal code change). ElastiCache (A) would require custom cache logic and isn't DynamoDB-native. CloudFront (C) caches web content. Read replicas (D) apply to relational RDS, not DynamoDB.

Q2. A relational application repeatedly runs the same expensive query against RDS, and the team wants to reduce database load while also needing a highly available cache with automatic failover. Which should they use?

A. ElastiCache for Memcached
B. ElastiCache for Redis
C. DAX
D. A larger RDS instance

Answer: B

B. ElastiCache for Redis offloads repeated reads and provides replication, Multi-AZ, and automatic failover. Memcached (A) has no replication/HA. DAX (C) is only for DynamoDB. A bigger RDS instance (D) doesn't cache and scales cost, not the read pattern.

Q3. Which data store best fits a workload that must handle millions of requests per second with consistent single-digit-millisecond latency, a simple key-value access pattern, and no servers to manage?

A. Amazon RDS for MySQL
B. Amazon DynamoDB
C. Amazon Redshift
D. Amazon Aurora

Answer: B

B. DynamoDB is serverless NoSQL built for massive scale and single-digit-ms latency on key-value access. RDS/Aurora (A, D) are relational and don't scale to that request volume as effortlessly. Redshift (C) is a data warehouse for analytics, not high-concurrency key-value serving.

Q4. A web application must serve the same images and videos to a global audience with low latency while reducing load on the origin. Which service?

A. ElastiCache
B. DAX
C. Amazon CloudFront
D. Read replicas

Answer: C

C. CloudFront caches content at edge locations worldwide, cutting latency and offloading the origin — the right layer for global content delivery. ElastiCache (A) and DAX (B) are database caches, not edge/content caches. Read replicas (D) scale database reads, not content delivery.

Q5. After moving a web tier behind a load balancer and Auto Scaling group, users are logged out whenever they hit a different instance. The team wants a scalable fix that keeps the app stateless. What should they do?

A. Enable sticky sessions permanently and store sessions on each instance.
B. Store session state in ElastiCache (or DynamoDB) so any instance can serve any user.
C. Reduce the Auto Scaling group to one instance.
D. Use a larger instance type.

Answer: B

B. Externalizing session state to ElastiCache/DynamoDB makes the app stateless, so any instance can serve any user and the ASG scales cleanly. Sticky sessions (A) is a workaround that keeps state on instances; shrinking to one instance (C) kills availability/scaling; a bigger instance (D) doesn't solve the session-affinity problem.

Next: 10 · Networking Performance → · Revise — DB & Caching Performance