# Exercise 1 — Pick a Data Model, Justify the Trade-offs

## Scenario

You're designing storage for three independent features of a social app:

1. **User profiles** — name, email, bio, a list of links. Read far more than written. Every profile has roughly the same shape, but users occasionally add custom fields (a "pronouns" field, a "pronouns visibility" flag) that product wants to ship without a coordinated migration.
2. **Order history for a marketplace** — orders reference a buyer, a seller, and a list of line items, each referencing a product. The finance team runs reports like "total revenue per seller per month, only for orders that were fully paid and not refunded" and needs the numbers to reconcile exactly, every time.
3. **Live "who's typing" presence indicators** in a chat feature — a key (`conversationId:userId`) mapped to a boolean and a timestamp, written extremely often (every keystroke pause), read only by clients currently viewing that conversation, and fine to lose entirely on a server restart.

## Deliverables

Answer directly under each heading.

1. **For each of the three features, name a data model** (relational, document, key-value, wide-column, or graph) and a real system that implements it. Justify using the concrete criteria from the theory file: access pattern (single-key vs. cross-entity), schema volatility, and whether cross-entity consistency (joins, transactions) is load-bearing for correctness.
2. **Feature 2 is the one most likely to be built on the wrong data model by a team excited about "web scale."** Explain concretely what breaks in the finance reports if orders/line-items/products are modeled as independent documents with no engine-enforced joins, and why "just query multiple collections and join in application code" does not give the finance team the exact reconciliation guarantee they need.
3. **Feature 3 is the one most likely to be over-engineered onto a relational database.** Explain what a relational engine forces you to pay for (durability guarantees, transaction log writes, index maintenance) that this feature's own requirements (fine to lose on restart) don't actually need, and name the class of store that fits instead.
4. **Quorum trade-off.** For feature 2, if you ended up replicating an order-status field across 3 nodes, would you rather configure `W=2, R=2` or `W=1, R=1`? Justify using the `W + R > N` overlap condition from the theory file and explain the concrete user-facing consequence of getting this wrong for a payment status field specifically.

## Notes

- There is no single "correct" architecture for every sub-question — the goal is to demonstrate you can apply the schema-on-write/schema-on-read and CAP/quorum framework from the theory file to real feature requirements, not just restate definitions.
- Keep answers concrete: name real fields and a real consequence of getting the choice wrong, not a generic restatement of "relational is for structured data."