🚪 Events on the inside, events on the outside

When another team needs your data, the quickest answer is to let them subscribe to the events your module uses internally. It works until you change something. They have to rebuild your process from small, detailed events, and every change you make can break them. You’ll learn to keep the two kinds of events apart, so you can change your module’s internals without breaking anyone.

The first article shows the problem: a payment team listens to shopping cart events, misses one, and charges customers too much. The fix is to treat the events you share as an API. Detailed events stay inside the module; other teams get fewer, complete events with the data they need. The second, older article asks how big an event should be. Its answer: as small as possible, but not smaller.

Start with the first. Read the second when several consumers need different data from you.