Webhooks are way better than polling for real-time updates, especially in a complex distributed system, when you need immediate info and dont want to waste resources. Think about it, polling just keeps asking 'Is it ready yet?' even when nothing's changed. With webhooks, you get a notification only when something actually happens. So, yeah, if you're looking for efficiency and speed in a complicated setup, webhooks win.

I'm building a distributed system and need services to react fast when others update. Right now, we're doing a lot of polling and some simple queues, but webhooks might make certain integrations much easier. The tough part is handling all the webhook registration, security, and making sure messages actually get delivered, especially with so many interconnected pieces and places things can break. Like, if an order status service updates, and shipping, analytics, and customer notifications all need that info instantly, webhooks just make sense. But what happens if a service receiving the webhook is down? How do we handle errors and retries? Are there times when building and maintaining a good webhook system is just too much hassle, even if it means less latency and using fewer resources, compared to clever polling or a message broker? I'm wondering if anyone has experience with balancing the good parts of real-time push notifications from webhooks against the operational headache in a big system. Any stories or tips for getting webhooks to work dependably at scale, particularly around making sure they're idempotent and managing subscriptions?