I would add on top that it looks like a bad idea to route webhooks over a central API Gateway (perhaps the drawing should be updated to clarify the demarcation line between customer-owned infrastructure vs service provider infrastructure).
As each Webhook would have client specific URI for each service API it may interact with, the API Gateway proxy would need to be wildcard/catch-all, providing little value-add on the API definition and routing. A reverse proxy would be more adequate (even if this job is fulfilled by an API Gateway, it might still be preferable to distinct both roles in the pictures for clarity)
The service should be able to send the webhook directly to the client to optimise flows and reduce maintenance at the level of the API gateway.
thanks for the wonderful post!
The following are the drawbacks of webhook:
- unreliable due to dependency on the availability of subscriber and publisher
- no guaranteed delivery or acknowledgment causing data loss or duplication
- increases complexity and introduces coupling between components
I would add on top that it looks like a bad idea to route webhooks over a central API Gateway (perhaps the drawing should be updated to clarify the demarcation line between customer-owned infrastructure vs service provider infrastructure).
As each Webhook would have client specific URI for each service API it may interact with, the API Gateway proxy would need to be wildcard/catch-all, providing little value-add on the API definition and routing. A reverse proxy would be more adequate (even if this job is fulfilled by an API Gateway, it might still be preferable to distinct both roles in the pictures for clarity)
The service should be able to send the webhook directly to the client to optimise flows and reduce maintenance at the level of the API gateway.