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.
A common challenge in event-driven architectures is the potential for unintentionally triggering downstream consumers when running end-to-end tests.
Ephemeral environments can help, but not when you must publish events to a shared event bus.
In such cases, you can conditionally create a local copy of the event bus as part of the ephemeral environment so your test events will not trigger downstream event consumers.
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.
~~~~~~~~~ UPDATE 02/08/2023: EventBridge Schedule now supports automated deletion upon completion. So the problem and solution discussed in this post is no longer relevant. Please see the announcement here. ~~~~~~~~~ The launch of EventBridge Scheduler was one of the highlights for me for re:Invent 2022. Finally, we have a scalable service that lets us …
The biggest problem with EventBridge Scheduler and how to fix it Read More »
Many software engineering concepts appear in different contexts. Modularity, the single-responsibility principle and separation of concerns are just a few examples that come to mind. They apply equally to how we write code, architect our systems and organize our teams. In this post, let’s discuss three ways we can control the concurrency of a serverless …
3 ways to control concurrency in serverless applications Read More »
re:Invent is almost upon us. Judging by the things that had been announced ahead of re:Invent, one can’t help but be excited about the main event itself! Here is a list of the serverless-related announcements so far that you should know about. Payload-based message filtering for Amazon SNS Here’s the official announcement. This is arguably the …
The biggest preinvent serverless announcements you may have missed Read More »
Choreography and Orchestration are two modes of interaction in a microservices architecture. In orchestration, there is a controller (the ‘orchestrator’) that controls the interaction between services. It dictates the control flow of the business logic and is responsible for making sure that everything happens on cue. This follows the request-response paradigm. In choreography, every service …
Choreography vs Orchestration in the land of serverless Read More »
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.