3 ms·
> As an event producer as long as you follow reasonable backwards-compatibility best practices then you should be pretty safe from breaking things downstream.
by majormajor 2y ago
> As an event producer as long as you follow reasonable backwards-compatibility best practices then you should be pretty safe from breaking things downstream.
That can protect you from "downstream can't even read the message anymore" but it doesn't help you with the much more common "downstream isn't doing the right thing with the message anymore" problem. Schema evolution is kinda like schema'd RPC calls vs plain JSON: it will protect you from "oops, we sent eventId instead of event_id" type of errors, but won't prevent you from making logical errors. In a larger org, this can turn into delayed-discovery nightmares.
A synchronous API call could give you back an error response and alert your immediately to something being wrong. The system notifies you directly.
A downstream event consumer may fail in ways entirely off of your team's radar. The downstream team starts getting alerts. Whether or not those alerts make it immediately obvious to them that it's your fault... that depends on a bunch of factors.
- pyrale 2y agoData consumers in unknown teams is a nightmare regardless of the architecture. Events sent for readership you can’t control are ideally of the type «x changed», and the consumer must then fetch data on the relevant endpoint. That or the company must have serious versioning policies.
- mattacular 2y agoWhat's the benefit of using an asynchronous event driven system if you can't process any of those events without performing a synchronous query back on the same provider for all of the necessary data?
- pyrale 2y agoYou get relevant notifications without polling or needing to sub, and you don’t have to be strict about message versioning.