Learn how semantic tags can help manage schema coupling in event-driven architectures and eliminate the need for event versioning.

TheBurningMonk's blog is a platform for sharing insights and expertise in cloud computing, serverless architecture, and distributed systems design. Through articles, tutorials, and case studies, TheBurningMonk offers insights into building scalable, resilient, and cost-effective cloud-native applications using serverless technologies. Readers can learn about architectural patterns, deployment strategies, and best practices for designing serverless applications that leverage the scalability and flexibility of cloud platforms. Additionally, TheBurningMonk provides updates on the latest developments in serverless frameworks, cloud services, and event-driven architectures to help developers stay ahead of the curve and harness the full potential of serverless computing.

theburningmonk.com

The post introduces the concept of semantic coupling as an innovative method to manage schema evolution in event-driven architectures, replacing traditional schema coupling. By using semantic tags instead of versioning or altering event schemas, it allows consumers to focus on the meaning of data rather than its representation. This approach prevents breaking changes and eliminates the need for event versioning, encouraging smoother schema transitions. Tools like Orbital and Taxi can facilitate these transformations by decoupling the data representation from consumers.

Bye bye schema coupling, hello semantic coupling

Interesting idea but I think this would get push-back due to the extra layer of abstration.

Maybe I missunderstood something but… isn’t there a known convention for json and the annotation for fields…? (e.g. “<a href="http://customer.id" target="_blank" rel="noopener nofollow">customer.id</a>”)
Am I missing something here or is this just overcomplicating json…? This seems like a simple mapper between the payload and handler would do the trick… I don’t get it…
edit// maybe I am really just not getting the point… but this seems so ridiculous to me…

sounds nice, thank you for sharing

It’s a nice idea, as long as versions are easy to transform.
For example, a recent case I ran into, an Order entity has a <code>couponId</code>. Now in the next version there could be multiple coupons, so it now has couponIds. Consumers that expect a single id, have no way to consume multiple ids. You can take the first or last couponId and pass them as the single id for older consumers, but you will lose data… In such cases, there is no easy solution except evolving all consumers.

db or ai wortflow is the right place for semantic layer