An event with a full payload is a distributed join waiting to happen

A thin event carrying only an id forces every consumer to call back for the details, which is a synchronous dependency the event was meant to remove. A fat one carrying everything makes the publisher responsible for guessing what consumers need.

// thin: every consumer calls back, and the publisher is a dependency again
{ "order_id": 8841 }

// fat: the publisher now owns a shape five teams depend on
{ "order_id": 8841, "customer": { ... }, "lines": [ ... ], "totals": { ... } }

// usually right: identity, plus the facts that made this event happen
{ "order_id": 8841, "occurred_at": "...", "total_cents": 4900, "currency": "TRY" }

The middle option is the one to aim for: enough that the common consumer needs no callback, not so much that the event becomes an API. When a consumer needs more, that is information about the boundary — either the event is missing a fact, or that consumer is in the wrong context.