Scalability and webhooks
A jackpot drop, a big-match kick-off, a bonus expiry at midnight. Throughput is provisioned per key and events keep arriving while your consumer catches up.
- Burst ceiling
- 18k msg/s
- Retry window
- 24 hours
- Signature
- HMAC-SHA256
Build order
- 1
Register an endpoint
Point an HTTPS URL at the event classes you care about and store the returned signing secret.
- 2
Verify and acknowledge
Check the signature, write the event, return a 2xx fast. Slow acknowledgements trigger retries.
- 3
Handle duplicates
Events are at-least-once. Key your writes on the event id and duplicates become harmless.
- 4
Set your ceiling
Raise the throughput limit for a known peak, then let it fall back so a runaway job cannot drain a budget.
What it gives you
Event delivery that survives your worst minute
- Per-key throughput ceilings you set yourself, with a burst allowance for scheduled peaks
- Signed payloads with a rotating secret and a replay window, so origin can be verified
- Exponential retry across twenty four hours with a dead-letter queue you can replay from
- Event ordering preserved per message id, with a monotonic sequence number for gap detection
- Regional egress from three availability zones with automatic failover between them
- A live event tail in the console for debugging without adding logging to your consumer
Wire scalability and webhooks into your stack
Sandbox keys are free and behave exactly like production, including the failure codes. Nothing to schedule and nobody to talk to first.