Lambda 1,000 concurrency and Sume webhook bursts finishing together

Lambda's default quota is 1,000 concurrent executions per Region, lower on new accounts, and a bulk queue of Sume runs can deliver dozens of webhooks in the same minute. Sume treats any non-2xx or timeout as a failed attempt and retries up to 10 times, so a briefly throttled receiver recovers, but only if you store events and answer fast.

What are Lambda's concurrency numbers?

The Lambda quotas page lists a default of 1,000 concurrent executions, raisable to tens of thousands, and notes that new AWS accounts have reduced concurrency and memory quotas that AWS raises automatically with usage. Each function can scale by 1,000 execution environments every 10 seconds. For synchronous invocation, each environment serves up to 10 requests per second.

A webhook receiver is a synchronous invocation, so those synchronous numbers apply.

How big is a Sume burst?

A bulk run holds up to 100 items with a concurrency window of 1 to 16, so no more than 16 children run at once and finish times spread out. But jobs with the same duration that started together can end together, and several queues or schedules can align on the hour.

Each child with a webhook_url sends one terminal POST. Even 100 in one minute is under two per second, nowhere near 1,000 concurrent executions. The real risk is a slow handler: at 10 seconds per attempt, slow executions hold slots and trip the timeout.

What does Sume do when the receiver says no?

Per the docs, success is any 2xx. Network errors and non-2xx responses are retried until attempts are exhausted: up to 10 attempts, a 10-second timeout each, and redirects are not followed. Job webhooks use a fixed delay between attempts, 30 seconds by default; run webhooks back off from 30 seconds, doubling with jitter up to an hour, and honour Retry-After on 429 or 503.

So a short throttle costs you a delayed event, not a lost one. A long outage past ten attempts leaves the job or run complete and the delivery failed; recover with the status endpoints or Redeliver.

How do I keep handlers fast?

Do the minimum before answering: verify the signature, write the event keyed by request_id, return 204. Put everything else behind a queue. An empty secret must refuse the request, so the sample fails closed.

The verifier below is plain Node and checks the multi-signature header used during secret rotation.

import crypto from "node:crypto";

export function verify(raw: string, ts: string, header: string, secret: string): boolean {
  if (!secret) return false; // never verify against an empty secret
  const t = Number(ts);
  if (!Number.isFinite(t) || Math.abs(Date.now() / 1000 - t) > 300) return false;
  const want = Buffer.from(
    "sume-v1=" + crypto.createHmac("sha256", secret).update(`${t}.${raw}`).digest("hex"),
  );
  let ok = false;
  for (const part of header.split(",")) {
    const got = Buffer.from(part.trim());
    if (got.length === want.length && crypto.timingSafeEqual(got, want)) ok = true;
  }
  return ok;
}

What should I watch?

Watch for throttling and duration on the receiver, and compare with webhook_delivery on the run or job: its attempts and status show how many tries Sume spent. If a burst does throttle you, request a higher concurrency quota in the Service Quotas console, which is how Lambda says you can change the default.

Sume does not see your Lambda metrics and does not slow its deliveries to match your quota; the retry schedule is the only pacing it applies.