Introducing Rate Limits

We have been speaking to engineers who have implemented webhooks to understand their workflows and one of the recurring themes was that the webhook sender at certain times generated a burst of webhook events. In this blog post, we’ll dive into the issue of overloading webhook receivers, provide examples, and introduce the concept of setting rate limits. We’ll also show you how to set rate limits easily on our platform.

Understanding the Problem:

Imagine a scenario where a webhook sender generates a massive number of webhook events in a short time frame. This can happen in various situations:

1. Payments Company: Issuing refunds for the previous day, leading to a high volume of webhook events scheduled all at once.
2. SaaS Billing: A subscription service generating invoices on a specific date and attempting to charge them all simultaneously.
3. E-commerce Flash Sale: An e-commerce platform running a flash sale, resulting in a surge of purchase-related webhook events.
4. IoT Devices: A network of IoT devices sending status updates simultaneously, such as temperature readings or security alerts.
5. Weather Alerts: A weather forecasting service broadcasting alerts for multiple regions during severe weather events.
6. Travel Bookings: A travel aggregator confirming bookings for a group tour, leading to a sudden influx of notifications.
7. Healthcare Providers: Health systems send patient data updates to various clinics and hospitals as a cron job.
8. Microservice architecture: Decoupled services with different data stores need to keep some portions of data in sync between two systems.

There are many more stories like this with a recurring theme of being conscious to not overload the webhook receiver. Imagining a world without webhook senders implementing rate limits would mean that webhook receivers have to overprovision servers which will only be utilized at full capacity for a short time while having very low average utilisation and thus high cloud bills. If not overprovisioned, then it would mean losing important data and a degraded service experience while having different systems that are not in sync with each other.

We immediately realised this could be a great value add for webhooks as a service product, since the webhook sender could send webhooks to us at virtually any rate they want and we would apply rate limits as and when we send them to the receiver thus the receiver would not be exposed to the spikes and would instead see a smooth stream of webhooks being received. We wilfully overprovision the servers a bit to be able to handle all sorts of spikes. Because of our multi-tenant architecture, the load on our servers becomes more or less predictable since many spikes are happening with many customers and thus we can service the needs of our customers.

How to set rate limits?

Go to Nirah’s dashboard -> Endpoints. Defining an endpoint is crucial to apply rate limits without which rate limits are not defined. Rate limits can be applied while creating a new endpoint or while updating an endpoint.

Managing webhooks and setting rate limits is essential to maintain a smooth and reliable communication channel between your services. With our Webhooks as a Service product, you can address the challenges of spike management and provide a more stable experience for your webhook receivers. Try our platform today and simplify your webhook rate-limiting process effortlessly.