4 ms·
> If you're a using a message queue (...) Events and messages are entirely different things. They might look similar, but their responsibilities are completely
by chipdart 2y ago
> If you're a using a message queue (...)
Events and messages are entirely different things. They might look similar, but their responsibilities are completely different. The scenario you're describing matches the usecases for messages, not events.
- hcarvalhoalves 2y agoThe situation of messages vs events is analogous to append-only database vs update-in-place database. You get exposed to the same issues at scale if you rely on the later. Being notified only _when_ something happened isn't always useful the world is changing underneath you (it _can be_ useful in particular situations, when you know state is final, but not as a general architecture principle).
- chipdart 2y ago> The situation of messages vs events is analogous to append-only database vs update-in-place database. You get exposed to the same issues at scale if you rely on the later. Not really. Messages vs events is a foundational design trait whose discussion involves topics such as adopting distinct messaging patterns such as message queues or pub-sub. They have completely different responsibilities and solve completely different problems.
- hcarvalhoalves 2y agoI don't see how using pub-sub or not changes how you model the data. It should be orthogonal. Do you have a good example?