Read replicas for performance in AWS - Step-by-Step Execution

Process Flow - Read replicas for performance

Primary Database

↓

Create Read Replica

↓

Replica Syncs Data

↓

Read Traffic Directed to Replica

↓

Primary Handles Writes

↓

Replica Improves Read Performance

The primary database creates a read-only copy called a read replica. The replica syncs data from the primary. Read requests go to the replica, reducing load on the primary and improving performance.

Execution Sample

AWS

1. Create primary DB instance
2. Create read replica from primary
3. Replica syncs data continuously
4. Application sends reads to replica
5. Application sends writes to primary

This sequence shows how a read replica is created and used to improve read performance by offloading read traffic from the primary database.

Process Table

Step	Action	State Change	Result
1	Create primary DB instance	Primary DB is active	Primary ready for reads and writes
2	Create read replica	Replica instance created	Replica starts syncing data from primary
3	Replica syncs data	Replica data updated	Replica has near real-time copy of primary data
4	Application sends read requests	Reads directed to replica	Read load on primary decreases
5	Application sends write requests	Writes go to primary only	Primary handles all writes
6	Replica continues syncing	Replica stays updated	Read performance improved
7	Stop	N/A	Process ends as replica is serving reads

💡 Replica is serving read traffic, primary handles writes, improving overall performance

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Primary DB	Not created	Active	Active	Active	Active	Active
Read Replica	Not created	Created	Syncing data	Serving reads	Serving reads	Serving reads
Read Load on Primary	High	High	High	Reduced	Reduced	Reduced
Write Load on Primary	High	High	High	High	High	High

Key Moments - 3 Insights

Why does the read load on the primary database decrease after creating a read replica?

Because read requests are redirected to the replica (see execution_table step 4), reducing the number of reads the primary must handle.

Does the read replica handle write requests?

No, all writes go to the primary database only (see execution_table step 5). The replica is read-only.

How does the replica stay up to date with the primary database?

The replica continuously syncs data from the primary (see execution_table step 3 and 6), keeping a near real-time copy.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the read load on the primary database decrease?

A Step 2

B Step 5

C Step 4

D Step 3

💡 Hint

Check the 'Read Load on Primary' state change column in the execution_table at step 4.

According to the variable tracker, what is the state of the read replica after step 3?

A Not created

B Syncing data

C Created but not syncing

D Serving reads

💡 Hint

Look at the 'Read Replica' row and the 'After Step 3' column in variable_tracker.

If the application sends write requests to the replica instead of the primary, what would change in the execution table?

A Replica would handle writes, which is not supported

B Write load on primary would increase

C Read load on primary would increase

D Replica would stop syncing data

💡 Hint

Refer to key_moments about write handling and execution_table step 5.

Concept Snapshot

Read replicas are copies of a primary database used to handle read requests.
They sync data continuously from the primary.
Writes always go to the primary.
This setup improves read performance by reducing load on the primary.
Applications direct reads to replicas and writes to the primary.

Full Transcript

Read replicas improve database performance by creating a copy of the primary database that handles read requests. The primary database handles all write operations. The replica continuously syncs data from the primary to stay updated. This reduces the read load on the primary, improving overall performance. The process starts by creating the primary database, then creating a read replica. The replica syncs data and serves read traffic while the primary handles writes. This separation of read and write traffic optimizes database responsiveness and scalability.