Architecture in Progress
Payload Bay
Payload Bay is an open-source, self-hosted event-delivery platform being designed as the controlled layer between webhook providers and the applications that consume them. The current work establishes the reliability contract and backend foundation before public interfaces and installation paths are presented as finished.
Status
active
Period
2026—Now
Context
Early-stage open-source platform
The challenge
Direct webhook integrations couple every provider to an application endpoint and leave each product team responsible for signature verification, durable storage, retries, replay, and incident visibility. Failures can become invisible precisely when the receiving application or network is least able to explain them.
Operating constraints
- Provider signatures must be checked against the unchanged request body.
- An event must be persisted before the provider receives an acknowledgment.
- Delivery is asynchronous and at-least-once, so duplicate attempts must be expected rather than hidden.
- Private applications need an outbound connection model instead of another publicly exposed inbound endpoint.
- The Community edition must remain capable without event, source, or runner limits designed only to force an upgrade.
The approach
The platform is organized around a durable event record and explicit delivery lifecycle. A stable ingress accepts and verifies the original request, persistence separates provider acknowledgment from downstream availability, routing creates deliveries for the correct targets, and attempts retain enough evidence to understand failure and recovery.
System outline
01
Canonical endpoints and aliases receive events while preserving the original request used for verification.
02
Durable events, receipts, deliveries, attempts, responses, and incidents form the operational record.
03
Asynchronous workers deliver to HTTP targets with retry and replay support.
04
Outbound runners are planned to reach private applications without exposing them directly to providers.
05
The committed Supabase workspace currently contains the backend configuration, migrations, Edge Functions, queue, and scheduled-work foundation.
Selected decisions
01
Persist before acknowledging
Provider success means Payload Bay has accepted durable responsibility for the event, not that a downstream application happened to be online at that moment.
02
State at-least-once delivery honestly
Retries and recovery can produce duplicate attempts, so the platform documents that contract instead of implying exactly-once behavior it cannot guarantee.
03
Make recovery a product surface
Attempts, failures, replay, and incident context are modeled as inspectable operations rather than buried in worker logs.
04
Prove the backend path before polishing the dashboard
The repository currently prioritizes ingress, persistence, delivery, retry, and recovery while public interfaces and SDK boundaries remain intentionally unstable.
The result
Payload Bay is not yet an installable release. The work completed so far defines the product boundary, repository structure, local Supabase development environment, and the reliability model that the implementation is being built to prove. Presenting it as an in-progress architecture case study makes that stage explicit while showing the engineering decisions already in place.