Event-Driven Architectures - Internal & External ● ● ● ●
EDA = microservices = AWS, Azure, or GCP. Critical events also come from external services (e.g. Stripe, Shopify, Twilio) via inbound webhooks. Your architecture must account for both internal and external events. Why havenʼt we applied the same rigor, tools, and patterns to external event delivery?
Slide 8
How Leading Platforms Are Rethinking Event Delivery
Slide 9
Twilio Sink
Slide 10
Shopify “Webhooks”
Slide 11
Stripe Event Destinations
Slide 12
Introducing Event Destinations ● ● ● ●
A modern event delivery model, inspired by Stripe, Shopify, and Twilio Supports delivery to many destination types — HTTP, queues, streams, and event buses Focused on reliability, scalability, and developer experience We’ve created a set of open-source guidelines have a conversation and assist adoption
eventdestinations.org
Slide 13
Event Destinations: For API Platforms (producers) ● ● ●
Improved reliability: Delivery to durable, fault-tolerant services (e.g., EventBridge, Hookdeck, Pub/Sub, Kinesis) Increased efficiency: Offloading retries, buffering, and failure handling to destination infrastructure Required security: Event destination types that require auth are an improvement on webhooks
Slide 14
Event Destinations: For Developers (consumers) ● ● ●
Integration flexibility: Choose how and where to consume events — webhooks, queues, or event buses Simplified infrastructure: Remove the HTTP ingestion layer Improved DX Better observability, fewer ingestion issues, and improved integration with existing tools
Slide 15
Event Destinations: A Model Inspired by Practice ● ● ● ●
Real-world patterns from Stripe, Shopify, and Twilio Delivery to Amazon EventBridge, GCP Pub/Sub, AWS Kinesis, and more Community-led effort to formalize and share modern event delivery guidance eventdestinations.org / github.com/hookdeck/event-destinations
Slide 16
Event Destinations Guidelines: Required ● ● ● ●
At least two event destination types, including webhooks Automatic delivery retries with exponential backoff APIs to create, update, and delete destinations Alerts for destination failures
eventdestinations.org
Slide 17
Event Destinations Guidelines: Recommended ● ● ● ● ● ●
At-least-once event delivery guarantee Event topics and topics-based subscriptions Auto-disabling of failing destinations after too many failures Developer UI to configure destinations & inspect events Manual retries via UI or API Filtering based on payload content
eventdestinations.org
Slide 18
When to Consider Event Destinations ● ● ● ●
Handling increasing scale and subscriber volume Experiencing frequent webhook failures or retries Reducing operational burden from delivery management Supporting customer integration needs
The Future of API Event Delivery ● ● ● ● ●
Event Destinations are shaping the future of API event delivery Move beyond webhooks to scalable, resilient infrastructure Supports modern architectures and developer expectations Join the Event Destinations Initiative and help define what comes next Outpost: open-source Event Destinations implementation
eventdestinations.org
outpost.hookdeck.com
Slide 21
Thanks & Questions
Phil @leggetter Hookdeck API Days / New York 14 May, 2025