# Exercise 2: Failover, Restore and Read-Your-Writes Scenarios

`orders-db` is the instance from Exercise 1 (Multi-AZ primary + one read replica). The application uses two endpoints: the **cluster/instance endpoint** for writes and the **replica endpoint** for some reads.

Answer each scenario using `aws_rds_theory.md` (sections 2–5 and 8). Be specific about what happens to DNS, connections, and data.

## Scenario A — AZ outage

The AZ hosting the primary loses power at 10:03:00.

1. What does RDS do, and roughly how long until writes succeed again?
2. What must the application do for its connection pool to recover? (Think about DNS TTL and existing TCP connections.)
3. Is any committed data lost? Why or why not?

## Scenario B — "My order disappeared"

A customer places an order (written to the primary) and is immediately redirected to "My orders", which reads from the replica. The order isn't there; after a refresh it appears.

4. Explain the cause and the metric you'd check.
5. Propose two fixes with different trade-offs.

## Scenario C — Bad migration

At 14:20 a migration accidentally runs `UPDATE orders SET status = 'cancelled'` without a `WHERE` clause. It's noticed at 14:35.

6. Why doesn't Multi-AZ or the read replica help here?
7. Write the CLI command to restore the database to 14:19:30 (point-in-time restore). What does the restore produce, and how do you get the correct `status` values back into production with minimal downtime?
8. What retention/backup settings determine whether this is possible, and what's the RPO of PITR?

## Scenario D — Scaling reads

Reporting queries saturate the primary's CPU every morning.

9. Compare: (a) send reports to the existing replica, (b) add a second replica, (c) scale the primary up. Include cost, lag and operational considerations.

## Requirements Checklist

- [ ] A: automatic failover to the synchronous standby in ~60–120 s; the endpoint's DNS record is repointed; apps must reconnect (short DNS TTL honored, pools that validate/recycle connections, retries); no committed data lost because the standby was synchronous.
- [ ] B: asynchronous replica lag (`ReplicaLag` metric); fixes: read-your-writes from the primary for that user/session for a short window, or wait/check replica LSN — vs sending everything to the primary.
- [ ] C: replication faithfully copies the bad UPDATE; restore with `aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier orders-db --target-db-instance-identifier orders-db-restore --restore-time 2025-…T14:19:30Z`; it creates a **new instance**; repair by copying the affected rows back (or switching endpoints).
- [ ] PITR depends on backup retention > 0 and transaction-log backups (RPO ≈ up to 5 minutes).
- [ ] D: weighs replica lag and eventual consistency for reports vs cost of a larger primary; mentions isolating reporting load from the primary.