How to design your messages: Patterns and tradeoffs in Event Driven Architectures

- "Our domain code is clean, but we can't trace message flows in production and debug issues."
- "Our event structure helps observability but the domain concepts are buried in boilerplate code that handles metadata."
- "Other teams keep subscribing to our internal messages or are constantly asking for changes to our public message schemas."

Sound familiar?
When designing distributed systems, we often make quick decisions on the structure of the messages we publish and consume, without evaluating critical trade-offs between domain purity and operational requirements that can impact us in the long run. The same can happen with schema versioning and evolution, broker topology, and separation of internal vs public events.

This session showcases the practical implications of such decisions through real-world examples and lessons learned the hard way.
We'll examine how different approaches affect not just the code but also the team's ability to reason about, evolve, and operate the system. Rather than prescribing a single "correct" answer, we'll provide a framework for making informed decisions in a given context.