Blog
Lessons Learned Building a Webhook Gateway
The lessons learned while building a webhook gateway start with a simple-looking path: accept HTTP, send HTTP. The hard part is everything that happens during failure: duplicate delivery, partial outages, noisy providers, schema changes, slow receivers, and replay risk.
These are the product and engineering lessons that shaped FastHook's model.
Separate The Model
A gateway becomes easier to reason about when ingress evidence and delivery work are separate records. One accepted provider request may create several destination events, and each event may create several attempts without changing the original request.
- Sources receive provider traffic.
- Requests preserve what arrived.
- Connections decide where traffic should go.
- Events represent destination-specific work.
- Attempts explain what the receiver returned.
Make Recovery Boring
Recovery controls should operate on the smallest failed unit. Retrying one event or pausing one connection avoids resending healthy branches and gives operators a clear record of the action they took.
- Retries should be visible, not hidden in workers.
- Replay should be filtered, cancellable, and tied to records.
- Pause should isolate one destination branch instead of stopping all ingress.
- Metrics should answer whether the issue is provider ingress or destination delivery.
Design For Operators
During an incident, the operator needs evidence before action. The interface should show what happened, why it failed, and what is safe to retry.
That evidence should connect the captured request, routing decision, destination response, retry history, and replay outcome. A useful gateway shortens the investigation without hiding the delivery model behind a single success badge.