The Dual Nature of Events in Event-Driven Architecture

Re:The Dual Nature of Events in Event-Driven Architecture by jwarden on Friday November 01, 2024 @02:40PM (#42020185)

Another architecture might be that the service responsible for Seat Selection emits a `SeatSelected` event, and another service responsible for updating bookings emits a `BookingUpdated(Reason: SeatSelected)` "fat" event. Same for `PaymentReceived` and `TicketIssued`.

Both events would "describe a space of things that occurred" as @bob1029 suggests.

The seat selection process for an actual airline probably needs to be more involved. @withinboredom recommends:

  - SeatTimeLimitedReserved {41A, 15m}
  - SeatAssignedTo {UserA}
  - SeatBooked {41A}

In which case, only SeatBooked would trigger a BookingUpdated event.

[ Parent | on HN ]

Re:The Dual Nature of Events in Event-Driven Architecture by lutzh on Friday November 01, 2024 @05:12PM (#42021603)

Thanks for your feedback. I realize I should have elaborated the example a bit more, it's too vague. So, as I wrote in some other reply as well, please don't over-interpret it. The point was only to say that in order to differentiate the events, we don't necessarily need distinct types (which would result in multiple schemas on a topic), but can instead encode it in one type/schema. Like mapping in ORM - instead of "table per subclass", you can use "table per class hierarchy".

[ Parent | on HN ]