Challenge 1: Add a Cancellation Path — Possible Solution
====================================================================

const session = client.startSession();

try {
  await session.withTransaction(async () => {
    const order = await orders.findOne({ _id: orderId }, { session });

    await orders.updateOne(
      { _id: orderId },
      { $set: { status: "cancelled" } },
      { session }
    );

    for (const item of order.items) {
      await products.updateOne(
        { _id: item.product_id },
        { $inc: { stock: item.qty } },
        { session }
      );
    }

    await customers.updateOne(
      { _id: order.customer_id },
      { $inc: { lifetime_spend: -order.total } },
      { session }
    );
  });
} finally {
  session.endSession();
}

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the exact same shape as Step 3's order-placing transaction, just
with each $inc reversed: stock goes back UP by the quantity that was
originally taken, and lifetime_spend goes DOWN by the order's total,
undoing what placing the order originally did.

All three writes — the status change, the stock restoration, and the
spend decrement — go through withTransaction() for the same reason as
Step 3: they touch three separate documents, and it would be a real
data-consistency bug for some of them to succeed while others failed
(an order marked "cancelled" whose stock was never actually restored,
for example, would silently under-count real available inventory
forever).

Reading the order first (findOne, inside the same session) is
necessary because the cancellation needs to know WHICH products and
HOW MUCH was originally paid — that data already lives on the order
document itself, per Step 1's embedded-snapshot schema design, so no
extra lookup elsewhere is needed.