# Exercise 2 — Diagnose an Embedding-vs-Referencing Failure

## Scenario

A team built a document store (MongoDB-style) collection for blog posts. To "avoid joins," every post document embeds a full snapshot of its author:

```json
{
  "_id": "post_501",
  "title": "Why We Migrated to Microservices",
  "body": "...",
  "author": {
    "id": "user_42",
    "displayName": "Ana Petrova",
    "avatarUrl": "https://cdn.example.com/avatars/42-v1.jpg",
    "bio": "Backend engineer, likes distributed systems."
  },
  "publishedAt": "2026-01-05T10:00:00Z"
}
```

There are 40,000 posts in the collection. Ana has written 1,200 of them. Today, Ana updates her `bio` and uploads a new avatar (`avatarUrl` changes).

## Deliverables

1. **Trace the consequence.** Explain exactly what a reader sees when they view Ana's 5-year-old first post immediately after she updates her bio, under the embedded design above. Is this consistent with what the "schema-on-read, duplication over joins" trade-off in the theory file predicts, and why?
2. **Quantify the fix cost.** If the team wants every post to reflect Ana's current bio and avatar, describe exactly what write operation must happen when she edits her profile, and why its cost scales with the number of posts she's written rather than being O(1).
3. **Propose the reference-based redesign.** Rewrite the JSON shape so `author` is a reference rather than an embedded snapshot, and describe the two reads a client must now perform to render a post with its author's current bio. What did you gain, and what did you give up (be specific about request count and latency, not just "it's slower")?
4. **Find the middle ground.** Propose a hybrid: which author fields are safe to embed as a denormalized snapshot (rarely change, and staleness is harmless if wrong for a few minutes) versus which must be referenced (change often, staleness is user-visible or embarrassing). Justify each choice by field.
5. **Relate it back to relational.** In one paragraph, explain why this entire class of bug — a value duplicated in many places silently going stale — cannot happen for a foreign-key relationship in a relational schema in the same way, and what a relational engine gives up in the same scenario (be specific: what does the relational version of "render a post with its author" cost in extra work compared to the fully-embedded document version, before Ana ever edits anything?).

## Notes

- This exercise deliberately does not require running code — reasoning about the failure mode and trade-off in prose is the point, matching how this decision is actually made during schema design review.
- A short JSON snippet for your redesign in deliverable 3 is expected; a full working system is not.