Offload the database

The fastest query is one you never send to the database. Domain 3 scenarios often describe read-heavy apps, session stores, or leaderboard spikes — your toolkit is caching, read replicas, and purpose-built data stores.

Amazon RDS and Aurora — read scaling

Read replicas

• Asynchronous replication from primary — eventual consistency on replica (typically seconds).
• Use for read-heavy workloads: reports, dashboards, read API tier.
• Promote replica for DR; cross-Region replicas for DR + local reads.
• Application must route reads to replica endpoints (not automatic on primary endpoint).

Aurora specifics

• Up to 15 Aurora Replicas in a cluster; shared storage volume — faster failover than traditional RDS.
• Aurora Serverless v2 — scales ACU for variable workloads.
• Aurora Global Database — < 1 second cross-Region replication for global reads + DR.

Exam: "Reduce load on primary DB for analytics queries" → read replica, not bigger primary only.

Amazon DynamoDB — performance design

Partition keys

• Data partitioned by partition key (and sort key if composite).
• Hot partitions — skewed access on one key throttles that partition regardless of table-wide capacity.
• Fix: high-cardinality partition keys, write sharding (suffix randomness), or DynamoDB Accelerator (DAX) for hot reads.

Capacity modes

Burst capacity — short spikes absorbed; sustained over provisioned WCU/RCU → throttling (ProvisionedThroughputExceededException).

Global tables

• Multi-Region active-active replication for low-latency local reads/writes (conflict resolution last-writer-wins).

Amazon ElastiCache

In-memory Redis or Memcached:

Common uses: session state, query result cache, rate limiting counters, leaderboards (Redis sorted sets).

Pattern: App checks cache → on miss, read DB → populate cache with TTL.

Cluster mode enabled (Redis) — shard data for scale-out memory and throughput.

DynamoDB Accelerator (DAX)

• Microsecond read latency for DynamoDB.
• In-memory cache cluster; write-through cache invalidation.
• Best for read-heavy, eventually consistent reads on DynamoDB — not a substitute for relational joins.

Exam: "Microsecond latency for DynamoDB reads" → DAX. "Cache SQL query results" → ElastiCache, not DAX.

Amazon Redshift (analytics angle)

• Columnar data warehouse — OLAP, not OLTP.
• Offload heavy reporting from OLTP RDS to Redshift via DMS, Glue, or batch ETL.

Layered architecture (typical exam answer)

Users → CloudFront (static)
     → ALB → EC2/ECS
              → ElastiCache (hot objects/sessions)
              → RDS primary (writes) + read replicas (reads)
              → DynamoDB (high-scale metadata) + optional DAX

Exam traps

• Read replica cannot accept writes (except after promotion).
• ElastiCache is not durable primary store — design for cache miss.
• DynamoDB Scan is expensive at scale — Query on key condition.
• Bigger RDS instance alone does not fix read-heavy if writes are fine — add replicas.

Official reference

SAA-C03 exam guide — high-performing database solutions.