Event producers and event publishing best practices
Event producers are applications that create and publish events. As you develop on AWS, you publish your events to one of your custom event buses on Amazon EventBridge. Here are some best practices for event publishers to follow:
Event publishers should be agnostic of the consumers of their events.
One of the golden rules in event-driven architecture is that event producers remain agnostic of the consumers. The event producers should not make assumptions about who or what might consume their events and tailor the data. This agnosticism lets you keep applications decoupled—one of the main benefits of EDA.
In its pure form, consumer agnosticism suggests the use of a publish-and-forget model. However, the reality, as you developgranular microservices in serverless, can be different. There will be situations (still within the loosely coupled services con‐ struct) where a publisher may want to know the outcome of the handling of an event by a downstream consumer so that it can update its status for recordkeeping, trigger an action, etc. The event types listed in “Differentiating event categories from event types” on page 146 can be indicators for this purpose.
Every event should carry a clear identification of its origin.
The details of the domain, service, function, etc., are important information to identify the origin of an event. Not all events need to follow a strict pattern of the hierarchy of their origin, but it benefits cross-domain consumers to set the event filters as part of consumption.
In a secured and regulated environment, teams apply event encryption measures to protect data privacy. Often, third-party systems sign the event payload, and consumers perform IP address checks to validate the event origin before con‐ sumption.
Treat domain events as data contracts that conform to event schemas.
With distributed services, event producers should conform the events to the published schema definitions, treating them as the equivalent of API contracts.
Versioning your events is essential to avoid introducing breaking changes.
Event producers should adhere to an agreed structure for uniformity across the organization.
As discussed earlier, uniformity in the event structure at the organizational, domain, or department level helps make the development process smoother in many ways.
It may be challenging to create a standard format for your events at the outset. You can evolve it as you gain experience and learn from others. Allow flexibility within the overall design to enable teams that need to accommodate information specific to them to do so.
An event should carry just the required data to denote the occurrence of the event. Often it takes time to decide on the content of an event. If you follow the struc‐ ture shown earlier, with metadata and data sections, start with the metadata, as you may already have clarity on most of those fields.
Begin from the context of when and where the event occurred, and build from there. It’s a good practice to include a minimal set of shareable data that is just enough to understand the event as an entity.
Event producers should add a unique tracing identifier for each event.
Including a unique identifier that can travel with the event to its consumers improves your application’s tracing capabilities and observability.
Be aware of the event payload size limit and service quota.
The maximum payload size of an event in Amazon EventBridge is 256 KB (at the time of writing). In high-volume event publishing use cases, consider the limit on how many events you can send to EventBridge per second, and have measures in place to avoid losing critical events if you exceed this limit.
When you publish events with sensitive data, you can add a meta‐ data attribute—say, severity—to indicate the level of severity of the risk of this data being exposed, with values like RED, AMBER, and GREEN. You can then implement logic to prevent certain subscribers from receiving high-severity events, for example. The gatekeeper event bus pattern described in Chapter 5 can make use of the severity classification of events to consider encryption measures when sharing events outside of its domain.