# Exercise 1: Pick a Multi-Region Topology for Three Products

You're the data-platform lead for a company running three unrelated products. Each currently runs on a single PostgreSQL primary in `us-east-1` with two same-region replicas. Leadership wants a regional strategy for each. Use the topologies and techniques from `dbscale_regional_partitioning_theory.md` — single-write-region with regional read replicas (section 2), active-active (section 2), data residency as the partition key (section 3), and conflict resolution (section 4).

## Product A: "Glance" — a news/content site

- 98% reads, 2% writes (editors publishing in a CMS; all 40 editors work from New York).
- Readers are 45% US, 35% EU, 20% APAC. EU/APAC readers complain about slow page loads (~250ms of DB latency on uncached pages).
- An article appearing in Singapore 2 seconds after publishing in New York is acceptable.
- No regulatory constraints on data location.

## Product B: "LedgerLite" — a small-business accounting SaaS

- Customers are businesses in the US and the EU (no APAC yet). Each business's data is only ever accessed by that business's own users.
- **Legal requirement:** EU customers' financial records must be stored and processed only in the EU (GDPR + customer contracts).
- Read/write mix is roughly 70/30; writes are invoices, payments, journal entries.
- Correctness is critical: a journal entry silently overwritten by a concurrent edit is unacceptable.

## Product C: "TapTrack" — a collaborative to-do app

- Users in every region; a shared list is often edited by people on different continents *at the same time* (a family across the US and Australia, a team spread over three continents).
- Users expect their own edits to appear instantly, even offline-then-online.
- Two people ticking items / adding items concurrently is the common case; two people renaming the same list at the same second is rare.
- No residency constraints.

## Deliverables

For **each** product:

1. **Topology**: single-write-region + regional read replicas, residency-partitioned (with a leader per residency zone), or active-active — and *why*, using the product's read/write mix, latency complaint, and constraints.
2. **What gets faster and what doesn't**: state explicitly which operations improve (reads? writes? for which regions?) and which keep the cross-region round trip.
3. **Consistency risk**: name the concrete anomaly a user could observe (e.g. read-your-own-writes violations from replica lag, or conflicting concurrent writes) and how you mitigate it.
4. For any product where you choose active-active: specify the **conflict-resolution strategy per data type** (e.g. last-write-wins for X, merge/CRDT for Y), and justify why LWW is or isn't acceptable for each.

Then answer:

5. **Product B edge case**: an EU business opens a US subsidiary whose employees must see the EU parent's invoices. Where does that data live, and does your answer still satisfy the residency requirement? What would you have to clarify with legal?
6. **Product A edge case**: an editor publishes an article and immediately clicks "view" — from a hotel in London, routed to the EU replica. What do they see, and what's the cheapest fix?

## Requirements Checklist

- [ ] Product A uses a single write region with regional read replicas (or explicitly justifies something heavier despite 98% reads and tolerance for seconds of lag).
- [ ] Product B uses residency as the partition key (section 3) with a single leader *per* zone — and avoids active-active for the same rows, since silent overwrites are unacceptable.
- [ ] Product C acknowledges that only active-active (or local-first sync) delivers instant local writes everywhere, and pairs it with merge/CRDT semantics for list items (add/remove/tick) rather than whole-list LWW.
- [ ] Each answer distinguishes read latency from write latency.
- [ ] Question 6 identifies a read-your-own-writes problem and proposes a targeted fix (e.g. route the author's reads to the leader for a short window, or use a session-level "last write LSN" check) rather than making all reads go to the leader.
- [ ] Question 5 recognizes that granting US access to EU-resident data is a *data transfer/processing* question (not just a database topology question) that needs a legal basis.