Webhooks are the ultimate escape hatch to systems integration. Event publishing that doesn't require you to know much about who is listening on the other end. It's trivial to create a publisher or consumer (bring your own HTTP server/client).
On the surface, Webhooks seem antithetical to the rise of the cloud native – it's easier than ever to set up servers that long-poll, managed pub/sub infrastructure, or simple event queues. But the opposite might be happening.
- Zero-trust architectures give a framework for authorized webhook endpoints that travel over the public internet. You still have to think closely about external traffic from your webhook provider (e.g., Stripe's smokescreen) to make sure it isn't being abused via server-side request forgery.
- Serverless and cloud event-driven architectures are more likely to be push rather than pull. Scale to zero and FaaS means that applications aren't continuously running.
- Fewer missed events. Better DevOps building blocks mean more reliable services. Given a public Lambda URL, you can be fairly certain of the availability of that endpoint (your application logic is a different story).
- More SaaS services, more loosely coupled integrations. SaaS companies can no longer try to implement as many connectors as possible (M:N API Problem), so webhooks are a quick shortcut to giving customers a small amount of flexibility.
Webhooks are probably not the answer when message deliverability is crucial: services with strict SLAs, streams with high volumes of data, or where sync is important. Queues and streaming solutions like Kafka are better options (at the cost of complexity).
You can also view webhooks as a shift of responsibility from event producers to event consumers. Webhooks put the onus of event management onto the consumer. Whether this is a temporary shift or something more long-term, it remains to be seen.