Give database readers their own lane — Aurora and Read replicas

Your goal

Separate reading from writing in a busy Aurora database.

Why this matters

A shop spends most of its database time showing products. You will keep writes on the writer, share suitable reads with readers, and plan for a writer failure.

Words you will use

An Aurora cluster is a group of database instances using shared storage. A writer changes data. A reader handles read requests. An endpoint is the address an app connects to.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Send a change to the writer

A customer places an order that must be saved. Your cluster has a writer and two reader instances. Choose where the write should go.

Which connection should save the order?

The cluster’s writer endpoint.

The writer handles data changes. Reader instances serve read workloads and are not interchangeable write destinations. Keep read and write connection choices clear in the app.

The order is sent through the connection that can change data.

Order insert → writer endpoint → writer instance

2. Share suitable reads

The product catalog receives many read requests. These requests can tolerate a short delay after changes. Choose a way to reduce read work on the writer.

Where could these reads go?

To a reader endpoint backed by Aurora readers.

Readers can handle suitable read workloads. The reader endpoint helps distribute connections, not every individual query inside a connection. Check consistency needs before moving a read path.

Catalog reads can use reader capacity while writes stay on the writer.

Catalog reads → reader connections
Order writes → writer

3. Prepare for a writer failure

You have readers in separate Availability Zones. The writer becomes unavailable and a reader can be promoted. Choose what the app still needs to handle.

What belongs in the recovery plan?

Reconnect through the right endpoint and safely retry failed work.

Failover changes which instance is the writer. Existing connections may fail. Reconnect and retry carefully, using safe request IDs where a repeated action could create a second order.

The app has a connection-recovery plan as well as database redundancy.

Writer fails → failover → reconnect → safe retry

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.