4 ms·
Some teams parallel to mine have an event based contract with their upstream, vs my team has a service contract. We've been doing some refractors to combine co
by 8note 5y ago
Some teams parallel to mine have an event based contract with their upstream, vs my team has a service contract.
We've been doing some refractors to combine common systems, so now the same team is upstream for both.
Talking to the sister teams, theyrepretty unhappy about their relationship with the upstream and are trying to avoid and replace them internally, vs we quite enjoy them.
I think the big difference is in mental model. When you're passed an event stream, the producer doesn't care about the events going out, and it's on you to handle all of them, and for failures, you have to reach out to whoever made failures in the upstream system, rather than the upstream team doing it. Otoh, for a service call, you only need to throw an exception for a bad event, and the upstream team is responsible for communicating the failure.
The more event based interfaces you have between your team and the folks making the change, the harder it gets to tell them that they're doing something wrong, and the less you even know about what they're doing or how to find them.
Mind you, immediately after the service call, we put messages on a queue. Distributing the message between systems we own works just fine