Let’s say you just did an integration with a payment provider like Stripe. Part of that flow involves Stripe calling back into your application to let you know that something happened.
This pattern is called a webhook. It allows you to let a 3rd party handle some part of your process and let you know that their part of your process is done.
Let’s say that you’re now providing the webhook as part of your offering. How do you do it?
The naive way is to have your call to your customers’ services contain the payload they need to know about. The thing that you track happens, and so you call them with the details of it.
Why is this naive? What happens if their server is not available? Do you retry? How often? How many times? Can your customers afford to miss your callback?
Moar better: your webhook simply tells them that you have new data available for them. They then call back into you to get that data.
What happens if they’re not available? That’s fine. They already understand that they call into you to get the data, so they’ve already built to be able to check with you for new data. Your outbound webhook is just a performance optimization at that point.
This is how event sourcing works, by the way. Consumers drive the consumption rather than having data pushed to them and for the same reasons.
