Ingesting Webhooks with AWS Serverless · Growing BitsGrowing Bits

Recent Notes<br>Ingesting Webhooks with AWS Serverless

Aug 05, 2026

Building the Pointer Architecture with Terraform

Aug 04, 2026

SearchSearch

Dark modeLight mode<br>Reader mode

Ingesting Webhooks with AWS Serverless<br>Garden statusPage typeGuide<br>Growth stageSeed<br>Version0.2<br>Aug 05, 202646 min read<br>aws<br>serverless<br>webhooks<br>event-driven-architecture

Ingesting Webhooks with AWS Serverless

This is the first of two posts. If you want to skip ahead to the implementation, read part two or go straight to the GitHub repository.

I’ve recently been working on ingesting webhooks using AWS.

It sounds simple enough, right? We’ve been receiving payloads over HTTP for decades, so surely this is a solved problem. Someone, somewhere, must have already written a clean and satisfying serverless implementation.

This turned out to be a very fun and interesting rabbit hole, and I would like to share my journey.

Webhook basics

Let’s start with the basics: a webhook is simply an HTTP request sent by one system to another when something happens. Instead of asking the provider every few minutes whether anything changed, the provider calls an endpoint we expose.

The provider decides the rules of the game. Slack expects an HTTP 2xx response within three seconds and retries failed deliveries up to three times. Other providers have different rules: GitHub, notably, can send webhook payloads up to 25 MB in size and does not automatically retry failed deliveries.

Scale

“Webhook ingestion” can mean very different things.

One team may receive a few events every minute. Another may receive thousands of events per second when a provider retries a backlog, sends a bulk update, or has an incident. The architecture should be driven by both average traffic and the peak we must absorb.

CaseIngress rateRough daily volume if sustainedExampleServerless fitA1 event/second86,400 events/dayA small integration or internal tool. Long periods without traffic are common.Excellent. Paying only when traffic arrives is exactly the point.B10 events/second864,000 events/dayA healthy SaaS integration with occasional bursts.Excellent. This is a natural serverless workload.C100 events/second8.6 million events/dayA meaningful production workload. Failures, retries, and observability now matter more than the endpoint itself.Good, provided that quotas and the complete cost per event are understood.D1,000 events/second86 million events/dayA high-volume platform. A short outage can create a large backlog very quickly.Maybe. Bursty traffic can still fit, but sustained traffic needs cost testing.E10,000 events/second864 million events/dayInfrastructure-scale traffic. A one-minute burst is 600,000 events.Usually poor. Per-request and per-hop charges become expensive at this scale.F30,000 events/second2.6 billion events/dayVery large bursts or a major multi-tenant platform. One minute is 1.8 million events.Poor by default. Evaluate provisioned streaming and worker platforms instead.

We should make a distinction between accepting an event and processing it.

Accepting an event means validating the request, recording it durably, and returning a response before the provider’s deadline. Processing begins afterward and may involve database writes, third-party APIs, file downloads, media encoding, or other comparatively expensive work.

These two stages have very different performance requirements and failure modes.

A, B, and C: workloads that may look simple

At lower event rates, accepting and processing events can appear closely coupled. If requests arrive slowly and each event requires little work, the processing layer may keep up without accumulating a meaningful backlog.<br>For very low event rates, and when there is little work to do, the system may not need external buffers or workers.

Cases A through C may allow a simpler implementation, but they still need explicit limits, retries, idempotency, and visibility into any growing backlog.

These are also the workloads where serverless is usually at its best. Traffic is low or irregular, idle periods are common, and paying per request is often cheaper than keeping servers and workers running all day. Cases A, B, and C are the main target for the architectures in this article.

D, E, and F: not your serverless usecase.

Acknowledging 30,000 HTTP requests per second is an easier problem than performing 30,000 units of downstream work per second.

A system may continue returning successful responses while its processing queue grows by millions of events. From the provider’s perspective, every delivery succeeded. Internally, however, processing latency may have increased from seconds to hours.

Case D can still be a reasonable serverless workload, particularly when the traffic is bursty rather than sustained, but it deserves a careful quota and cost model. At this point, every additional managed hop is multiplied by tens of millions of daily events.

For...