When do you use event modelling?

Direct answer

What a strong answer covers

How it works

Event modelling describes a system as the facts that happen over time, such as OrderPlaced or PaymentCaptured, rather than as the current state of tables. It fits when business processes unfold in steps, when several systems need to react to the same fact, when history and audit matter, or when an integration must survive one side being down. Each event has a producer that owns its meaning, a versioned schema, consumers with their own responsibilities, and explicit rules for ordering, duplication, retention, and replay. Laying events on a timeline with the commands that cause them and the views built from them exposes gaps before code exists.

Example

Modelling a returns process as events, ReturnRequested, ReturnApproved, ItemReceived, RefundIssued, revealed that customer service, the warehouse, and finance each reacted to different events and that nothing produced ReturnApproved automatically for low-value items, which became the first automation. The refund consumer was designed to be idempotent because ItemReceived could be emitted twice by the scanner.

Common mistakes

• Modelling events as commands or as row updates rather than as facts that already happened.
• Leaving ordering and duplicate semantics unstated and discovering them in production.
• Applying event modelling to a simple CRUD screen where a table would do.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.