When we talk about event-driven architectures, we often focus on things like loose coupling, scalability and DDD. But under the hood, the way consumers receive events matters just as much. And it usually comes down to one of two models: push vs poll.
Your choice dictates what service(s) you use and how you handle errors.
So, in this article, let’s compare the two models and understand their pros & cons.
What if you don’t have to worry about event versioning or catching breaking changes anymore?
What if event consumers are no longer coupled to the schema of the event and instead, subscribe to their semantics?
I discovered an exciting new way to manage event schemas that will blow your mind!
How can you prevent accidental breaking changes from creeping into your event schemas?
You can detect and stop breaking changes:
* At runtime, when the events are ingested;
* During development, when schema changes are made;
* Or a combination of both!
In this article, let’s look at three approaches you should consider.
Event-driven architectures encourage loose coupling.
But we are still bound by lessor forms of coupling such as schema coupling. And here lies a question that many students and clients have asked me:
“How do I version my event schemas?”
In this post, let’s run through some common approaches and why they all suck to some degree and the two most important decisions you need to make.
One under-appreciated aspect of designing an Event-Driven Architecture (EDA) is how much information you should include in your events.
Do you send light events or rich events?
Or perhaps you would send both, but in different circumstances?
In this post, let’s talk about the pros & cons of each and how they fit into my mental model of DDD and EDA.
This article is about best practices for building event-driven architectures on AWS, with a focus on wrapping events in custom envelopes when using EventBridge.
While EventBridge provides metadata by default, a custom envelope allows for a standardized, consistent structure across all of your events, making it easier to manage and evolve the system over time.
By providing your own metadata, you can gain better interoperability between different services, end-to-end observability, idempotency control and versioning.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.