Determine High-Performing Database Solutions

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.3

🎯 Determining High-Performing Database Solutions is about picking and designing databases that meet:

1 Performance goals
2 Scale requirements
3 Availability expectations
4 Operational constraints

Start with the data model + access pattern: relational vs key-value vs document, then choose the service, then add performance boosters: read replicas, caching, connection pooling.

---

Knowledge

1 | AWS Global Infrastructure

Availability Zones And Regions

• Multi-AZ deployments improve availability and can improve performance under failure.
• Multi-region designs support disaster recovery and global performance.

“Must survive AZ outage” → Multi-AZ
“Global users with low latency” → global DB patterns

---

2 | Caching Strategies And Services

Amazon ElastiCache

Caching reduces database load and improves latency.

• ElastiCache for Redis: caching + sessions + pub/sub + sorted sets
• ElastiCache for Memcached: simple, distributed cache, no persistence

“Reduce read load / hot keys / repeated queries” → ElastiCache.

---

3 | Data Access Patterns

Read-Intensive vs Write-Intensive

This is one of the most important drivers of database design:

1 Read-heavy → add caching, read replicas, or purpose-built read scaling
2 Write-heavy → consider partitioning/sharding patterns, or DynamoDB if it fits
3 Spiky traffic → serverless options or buffering with queues

4 | Database Capacity Planning

Capacity Units, Instance Types And Provisioned IOPS

1 RDS/Aurora performance depends on instance size, storage type, and sometimes Provisioned IOPS
2 DynamoDB uses RCUs/WCUs (or on-demand) and partition design affects performance
3 High-performance workloads often need correct sizing plus monitoring

5 | Database Connections And Proxies

Connection limits are a common real-world and exam bottleneck.

Amazon RDS Proxy pools connections and helps with spiky connection patterns (especially Lambda) and helps reduce failover impact and connection storms.

“Serverless app is exhausting DB connections” → RDS Proxy.

---

6 | Database Engines With Appropriate Use Cases

Homogeneous vs Heterogeneous Migrations

• Homogeneous migration: same engine to same engine (e.g., MySQL → MySQL)
• Heterogeneous migration: different engines (e.g., Oracle → PostgreSQL) _ AWS DMS is commonly used for migrations (especially minimal downtime)._

7 | Database Replication

Read Replicas

Read replicas are mainly for:
1 Scaling reads
2 Offloading reporting/analytics queries
3 Cross-region read performance (depending on engine)

Reminder:

• Read replicas are usually asynchronous
• Multi-AZ is for availability, not for read scaling

8 | Database Types And Services

Relational (SQL)

Amazon RDS: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server
Amazon Aurora MySQL/PostgreSQL-compatible, high performance, managed

Non-relational (NoSQL)

Amazon DynamoDB: key-value/document, massive scale, low latency

In-memory

ElastiCache: Redis/Memcached (cache, sessions)

Serverless Database Patterns

Aurora Serverless v2: elastic relational capacity

---

Skills

A | Configure Read Replicas To Meet Business Requirements

You Should Know When And Why

1 Add replicas to scale reads and isolate reporting workloads
2 Place replicas in other AZs or Regions if needed (engine-dependent)
3 Monitor replication lag and route read traffic appropriately

B | Design Database Architectures

Typical high-performing patterns:
1 App → (optional cache) → DB
2 Multi-AZ for HA
3 Read replicas for scaling reads
4 Shard/partition when required (more advanced, usually not primary SAA topic)
5 Offload analytics to separate systems when needed

C | Determine An Appropriate Database Engine

MySQL vs PostgreSQL, etc.

Expectation: pick based on compatibility/features/organization standards rather than arguing favorites.

1 Choose MySQL/Aurora MySQL when compatibility with MySQL ecosystem is needed.
2 Choose PostgreSQL/Aurora PostgreSQL when advanced SQL features/extensions are needed.
3 Choose commercial engines (Oracle/SQL Server) when required by licensing/app constraints.

D | Determine An Appropriate Database Type

Aurora vs DynamoDB

Fast rules:
1 Need joins/transactions/relational schema → RDS/Aurora
2 Need massive scale + low latency key-value/document → DynamoDB
3 Need sub-millisecond repeated reads → add ElastiCache

DynamoDB vs RDS is a frequent exam decision point.

E |Integrate Caching To Meet Business Requirements

Caching Options

• ElastiCache for app-side caching of hot data
• DAX (DynamoDB Accelerator) for DynamoDB read caching (in-memory, managed)

“Microsecond reads for DynamoDB queries” → DAX (if DynamoDB is the DB).

---

Cheat Sheet

---

Recap Checklist ✅

1. [ ] Database choice matches data model (relational vs non-relational)

2. [ ] Read-heavy workloads use read scaling (read replicas) and/or caching

3. [ ] Write scaling is considered (correct service + partition design if DynamoDB)

4. [ ] Connection spikes are handled (RDS Proxy when appropriate)

5. [ ] Capacity planning is understood at a high level (instance types, IOPS, RCUs/WCUs)

6. [ ] Multi-AZ is used for availability; read replicas are used for read scaling

7. [ ] Caching is integrated appropriately (ElastiCache/DAX)

---

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 3.3

You do not need to memorize them, use them to understand how to Design High-Performing Database Solutions

Core database services

1. Amazon RDS

2. Amazon Aurora

3. Aurora Serverless v2

4. Amazon DynamoDB

Read scaling, HA, and connections

1. RDS Read Replicas

2. RDS Multi-AZ (concepts)

3. Amazon RDS Proxy

Caching

1. ElastiCache (Redis/Memcached)

2. DynamoDB Accelerator (DAX)

Migration

AWS Database Migration Service (DMS)

Capacity planning references

1. DynamoDB Capacity Modes

2. RDS storage options

🚀