Webhookrelay.io — A Use Case
Webhookrelay.io is a turnkey SaaS platform for relaying webhook data from one endpoint to multiple data repositories. In this example we are going to explore one use case for the Webhookrelay.io Fanout service, and how it can help you manage and control your data.
Webhookrelay.io is an affordable, easy to use solution for firms that need to make decisions about where to point their webhook data from data producers that only supply a single webhook end-point. Take Sendgrid as an example. The ESP provides a real-time data webhook for email deliverability events — the pay load looks something like this:
[
{
"email": "<omitted>@gmail.com",
"event": "processed",
"send_at": 0,
"sg_event_id": "cHJvY2Vzc2VkLTQyMjkwNjctSnVKLTRHa29UN2FwQ0VDcjhXSW1TZy0w",
"sg_message_id": "JuJ-4GkoT7apCECr8WImSg.filterdrecv-p3mdw1-77d77b4d7d-zf84v-19-5E5EECFB-3F.0",
"smtp-id": "<JuJ-4GkoT7apCECr8WImSg@ismtpd0005p1las1.sendgrid.net>",
"timestamp": 1583279355
}
]This data can be sent to a single endpoint using SendGrid’s Event Notification Setting under Settings -> Mail Settings found on your SendGrid account’s dashboard.
Up to now, SendGrid users had few options to realize value from their own data — consume it themselves for analysis or send it to a third party like 250ok.com (recently acquired by Validity). While 250ok.com will make quick work of this data and offers an amazing suite of products that provide valuable insights; the data being produced by SendGrid ultimately belongs to the business generating it. In the current scenario, the business generating the data is sending their data to a third party for consumption and losing the ability to consume it themselves. Enter Webhookrelay.io Fanout.
Webhookrelay.io Fanout provides its users with the ability to relay their webhook data generated from data-producers like SendGrid to multiple endpoints in parallel. At a high level, this is what we will do for you:
After pointing your SendGrid event webhook at Webhookrelay.io:
The AWS Load Balancer will forward the request to one of the Kubernetes pods running within your company’s unique namespace:
The first pod is going to produce the payload to the Kafka cluster for temporary storage (None of your relayed data is stored permanently when using the Webhookrelay.io Fanout service):
The second pod consumes from the Kafka topic. After Webhookrelay.io receives your request, all of your relayed payloads are transmitted through the infrastructure in a namespace that is unique to your account:
The consumer pod retrieves the message from the Kafka topic and forwards the payload to its designated endpoints:
Video Demo:
The video below demonstrates how to use the Webhookrelay.io Fanout service to add endpoints to their relay account, and then testing the relay using the SendGrid webhook. The first relay endpoint points to Webhook.site, the same website SendGrid recommends using to first test their event webhook. The second relay endpoint points to Beeceptor.com, a webhook receiver. After each endpoint is added, the demo user tests the webhook relay and reveals the forwarded data in the windows on the left side of the demonstration video.
Leveraging AWS and Kubernetes, Webhookrelay.io is highly available, scalable, and fast. Using Sendgrid’s very own Loader.io to load test the service, we can see that at 250 and 500 client connections per second, the error rate for data transmission is zero:
250 Client Connections per Second:
500 Client Connections per Second:
At 500 client connections per second, Webhookrelay.io processed 30,000 requests in one minute with zero errors. The AWS Network Load Balancer paired with the Kubernetes Nginx ingress controller not only allows for traffic isolation but also incredible throughput and high availability.
