Exercise 3: What "Your Points Will Update Shortly" Is Actually Doing — Possible Solution
====================================================================

WHAT THE MESSAGE IS HONESTLY COMMUNICATING
------------------------------
This chapter verified a real, measurable gap using AsyncEventBus: right
after order_service.place_order() returns, user_service.users is still
{} - genuinely empty, not just "not yet displayed." The points don't
exist anywhere in the system yet; they only appear once
bus.process_queue() actually runs. A message like "Order placed! Your
loyalty points will update shortly" is the user-facing acknowledgment
of EXACTLY this verified gap - it's telling the truth about the
system's own actual state (the order is confirmed; the points
genuinely are not there yet), rather than implying something that
hasn't happened yet has already happened.

WHY CHAPTER 5'S DIRECT-CALL VERSION NEVER NEEDED THIS MESSAGE
------------------------------
Chapter 5's original update_user_loyalty_points() was called directly,
synchronously, as part of processing the order - by the time that
function call returned, the points genuinely already existed in
user['points']. There was no gap to communicate, because there was no
gap: consistency was immediate, verified by the fact that Chapter 5's
own code never needed to distinguish "the order is placed" from "the
points are updated" as two separate moments in time - they happened at
the same instant, inside the same function call.

THE UNDERLYING TRADE THIS MESSAGE MAKES VISIBLE
------------------------------
This chapter's own warn-box named the trade directly: OrderService's
genuine ignorance of UserService (verified via inspect.getsource())
is what creates the processing gap this message has to account for.
A UI message like this is a small, honest cost of that architecture
choice, made visible to the user rather than hidden - the alternative,
silently showing an out-of-date points total with no explanation,
would be worse: it would let the user believe the system was simply
wrong, rather than correctly informing them the update is genuinely
still in flight.

WHY THIS WORKS AS AN ANSWER
------------------------------
The message's own meaning is grounded directly in this chapter's own
verified before/after state (user_service.users empty, then populated
after process_queue()), and the explanation of why Chapter 5 never
needed an equivalent message traces back to that chapter's own
synchronous, single-function-call design rather than asserting the
difference abstractly.