Stripe has a great API. Pretty much everyone I've talked to about it agrees, and it's often cited as a solid example of a best practice.<p>One of the best parts is their webhooks. The question is: how can I clone them?<p>I read in a blog post somewhere that the webhooks are based in large part upon a MongoDB collection that acts as a message queue. Sounds like a solid piece of advice, and I understand how Mongo's non-relational data storage makes for a pretty slick way of persisting events/messages. Besides that... any other hints? I'm look at you, Stripe devs.<p>Alternatively, are there SaaS services or open source libraries that help with this problem or am I stuck re-inventing the wheel?
Version 1.0 can be out in an hour and requires one page to register webhooks, one place to store outgoing event data (which can be in anything -- a SQL database with a column representing a JSON bag-of-serialized-attributes will work fine), and a cron job. The minimum implementation is not difficult engineering.<p>A lot about what Stripe does right is in the ancillary bits about consuming their webhooks:<p>1) Spend a lot of time thinking about what your retry policy is. Some service providers (including ones which I like) will do one callback and then not retry. This is often suboptimal for consumers. I personally like "retrying with expotential decay", which is a nice balance between "You get your webhook really, really quickly if a gremlin just happened to eat the first one" and "If your servers are experiencing hard downtime, we won't add to the problem by pinging the heck out of you."<p>2) There is no SaaS or open source option for "Have great documentation, at once both comprehensive and easy to consume for the goal-oriented developer."<p>3) There are a lot of failure modes for webhook systems, some of which you'll only discover when operating them. Transient network problems between your application and the consumer's. "Failure to agree on reality" between different moving parts of your application. Adding webhooks to the outgoing queue in a non-idempotent fashion, which seems to be one of the great Let Me Tell You About This One Timee stories in systems engineering. Timing issues with consumers receiving webhooks in an order other than that which they would logically expect, which might not be your problem but good luck convincing a customer of that.<p>You'll want to have instrumentation and monitoring up that wazoo, so you can resolve these little usage niggles. This boring, iterative execution on the base feature is approximately 99% of why really well-executed APIs (like Stripe or Twilio or whomever) are really fun to work with and, well, why there exist some APIs which are less fun to work with.