# Exercise 1: Design a Replication Topology

## Scenario

`LedgerBox`, a small-business invoicing product, runs a single PostgreSQL instance today and is hitting read capacity limits — its dashboard (read-heavy, mostly report queries) and its write path (creating/updating invoices) share the same instance, and dashboard load now regularly makes invoice-creation writes slow during business hours.

Requirements from the team:
- Invoice writes must **never be lost** once a user sees "Invoice saved" — this is a financial record-keeping product, and the team is explicit that a small amount of extra write latency is an acceptable trade for a hard durability guarantee on that specific path.
- The dashboard can tolerate a "few seconds" of staleness — a report that's 5 seconds behind is a non-issue.
- One specific flow is sensitive: after a user edits an invoice, the very next screen re-displays that same invoice, and it must show the edit that was just made — showing stale data here has caused real support tickets in the current single-instance setup's caching layer (unrelated to this replication decision, but the team wants this replication topology to not introduce a *new* version of the same bug).

## Deliverables

1. **Propose a leader-follower topology** — how many followers, and state explicitly which are synchronous and which are asynchronous, justified against the "writes must never be lost" requirement using theory section 3.
2. **Explain where dashboard reads should be routed**, justified against the "few seconds of staleness is fine" tolerance and theory section 4.
3. **Explain specifically how you prevent the edit-then-immediately-reread problem** from theory section 4's read-your-own-writes scenario, for the invoice-edit flow — name the specific mitigation approach you'd use and why it fits this flow better than the alternatives mentioned in the theory file.
4. **State what happens to write latency** under your proposed topology compared to today's single-instance setup, and whether that's consistent with what the team said they're willing to accept.

## Constraints

- Your topology must name a concrete number of followers and their sync/async role each — "some followers" is not sufficient.
- Do not route the invoice-edit re-read to a follower under any staleness-tolerance argument — the scenario states this specific flow has zero staleness tolerance regardless of how small the lag typically is.