| Hey throwaway! I think this could work, but it might not be the highest priority. Think about this perspective: The API is entirely HTTP, and tries to meet users where they are by providing tools that they are most comfortable with. Frequently, these users are familiar websites or mobile apps. As such, webhooks are implemented over HTTP. If there was an alternate way to integrate with events, it'd be something that's either: 1. accessible to novice users, or 2. delivers on high throughput/latency needs of the largest users, or 3. resolves a storage/latency/compute cost incurred behind the scenes Thinking about these: For #1, websockets would score better than SMTP For #2, kafka (or a managed queue like SQS) would score better (many support dead letter queues and avoid the latency at the mail layer) For #3, it isn't clear that SMTP reduces the latency, compute, or storage costs SMTP might be familiar -- and it's possible for you to build your own webhook → SMTP bridge if you wanted it -- but doesn't score well enough on any of these metrics to be built in-house. [Disclaimer: I work at Stripe, and these opinions are about how I'd approach this decision. They're not the opinions of my employer.] |
But I'm not convinced on the latency/compute/storage comparison with Kafka or other solutions. I think a POC would need to be built and perf tested, and then tweaked for higher performance and lower cost, like most software. Considering the volume of traffic that mail software is designed for, I can't see how even a large provider like Stripe would have difficulty scaling a mail system to match Kafka. It's not like mail software is written in Java or something ;-)