Challenge 2: Extend the Dashboard Pipeline — Possible Solution
====================================================================

db.orders.aggregate([
  { $match: { status: "completed" } },
  { $unwind: "$items" },
  { $facet: {
      revenueByCategory: [
        { $group: { _id: "$items.category", revenue: { $sum: "$items.price_paid" } } },
        { $sort: { revenue: -1 } }
      ],
      topProducts: [
        { $group: { _id: "$items.name", unitsSold: { $sum: "$items.qty" } } },
        { $sort: { unitsSold: -1 } },
        { $limit: 5 }
      ],
      ordersPerDay: [
        { $group: {
            _id: { $dateToString: { format: "%Y-%m-%d", date: "$createdAt" } },
            count: { $sum: 1 }
        } },
        { $sort: { _id: 1 } }
      ]
  } }
])

WHY THIS WORKS AS AN ANSWER
------------------------------
The new ordersPerDay facet is added as a third key inside the existing
$facet stage, completely independent of revenueByCategory and
topProducts — exactly the point of $facet, per Chapter 2: each named
sub-pipeline runs against the same $match/$unwind input without
affecting the others.

One subtlety worth noting: ordersPerDay groups by createdAt (a
field on the ORDER itself), while the other two facets group by
fields inside items (which only exist per-item after $unwind). Since
$unwind already ran once before $facet, every "row" reaching
ordersPerDay is actually one item-per-order rather than one row per
order — this would over-count orders that contain multiple items,
since each item from the same order becomes a separate document to
group by day. A more precise version would run $group on createdAt
BEFORE $unwind, in its own dedicated pipeline that doesn't share the
unwound input — a genuine limitation of using one shared $match/$unwind
prefix for facets whose ideal input shape isn't actually identical,
worth flagging even in an otherwise reasonable-looking pipeline.