Challenge 1: Model Polymorphic Notifications — Possible Solution
====================================================================

{ user_id: "U1", type: "friend_request", timestamp: ISODate("2026-07-06"),
  from_user_id: "U2", status: "pending" }

{ user_id: "U1", type: "comment_reply", timestamp: ISODate("2026-07-06"),
  post_id: "P88", replying_user_id: "U3", excerpt: "Great point about..." }

{ user_id: "U1", type: "system_announcement", timestamp: ISODate("2026-07-06"),
  title: "Scheduled maintenance", body: "The site will be down..." }

WHY THIS WORKS AS AN ANSWER
------------------------------
Every document shares three fields regardless of type: user_id (who
the notification is for), type (the discriminator), and timestamp —
these are the fields any query like "get all notifications for this
user, newest first" needs, and they mean the exact same thing no
matter which kind of notification it is.

Everything else is type-specific, matching what each notification kind
actually needs to be useful:
  - friend_request needs to know WHO sent it and its current status
    (so it can be accepted/declined)
  - comment_reply needs to know WHICH post and WHO replied, plus enough
    of the reply to preview it without a separate lookup
  - system_announcement has no "other user" at all — it needs a title
    and body instead, fields the other two types don't have

A query for "just this user's pending friend requests" would filter on
{ user_id: "U1", type: "friend_request", status: "pending" } — the
status field only being meaningful (and only being queried) in the
context of that one type is exactly the trade-off the chapter's
"every reader needs to branch on the discriminator" line was warning
about.