relayENGINEERING PROJECT

GO + POSTGRESQL · OPEN SOURCE

Every event
deserves a
delivery record.

From an accepted event to a signed webhook. Relay makes delivery durable, retries bounded, and uncertainty explicit.

Explore the code ↗Follow an event ↓

Built by Luan Bonifacio. A backend engineering project, developed one verified milestone at a time.

RELAY / DELIVERY RECORDILLUSTRATION
order.created evt_example
  1. 01
    Authenticated & accepted

    Client token verified. Destination ownership checked.

    ✓
  2. 02
    Committed to PostgreSQL

    Event + delivery saved atomically. Then HTTP 201.

    ✓
  3. 03
    Claimed by a worker

    Durable lease. No transaction held during HTTP.

    ✓
  4. 04
    Signed & delivered

    HMAC-SHA256 · HTTPS · receiver returned 204

    ✓
DELIVERY OUTCOMEsucceeded ↗

Example flow, not live traffic or performance data.

3 attempts

Initial automatic delivery budget

5 seconds

Outbound HTTP deadline

At least once

Receiver deduplication required

Explicit boundaries.
No exactly-once promise.

01 / FOLLOW THE EVENT

A small system.
A deliberate delivery path.

One Go repository, separate API and worker processes, and PostgreSQL as the durable queue. No message broker required.

01 / RECEIVEAPI

Authenticate · validate · commit

02 / PERSISTPostgreSQL

Events · leases · attempts

03 / DELIVERWorker

Claim · sign · send · record

04 / VERIFYYour receiver

Verify signature · deduplicate

Delivery has more than one ending.

Explore illustrative outcomes. A timeout or worker crash cannot prove that the receiver did nothing.

pending → attempting → succeeded

The receiver returns 204. Relay records success. The response confirms acceptance by the receiver, not completion of its business workflow.

02 / ENGINEERING DECISIONS

The hard parts
are in the boundaries.

Designed around failures that happen between systems, with tests for the behavior that matters.

01

Commit before acknowledgment

Authenticated ingestion persists the event and its delivery in one transaction. Idempotency is client-scoped: matching request bytes reuse the event; conflicting submissions are rejected.

02

Outbound requests have limits

Public-address validation, DNS-pinned HTTPS, no redirects, and bounded request time and response size constrain the sender before it reaches a receiver.

03

Secrets have a lifecycle

HMAC-SHA256 signs the timestamp, stable event ID, and exact payload bytes. Destination secrets are encrypted with AES-GCM and move through explicit lifecycle states.

04

Crashes leave evidence

Durable leases and fenced completion coordinate workers. Interrupted attempts remain unknown in history. Retries consume a persisted budget, with jittered delays.

Read the architecture →

03 / PROJECT STATUS

Built in public.
Scoped with care.

This is an engineering portfolio, not a hosted webhook product. This domain serves the project page; the Relay API is not publicly exposed.

IMPLEMENTED

A durable delivery core

Authenticated destinations and ingestion, idempotency, encrypted signing keys, signed HTTPS attempts, bounded retries, and a continuous worker, per-event attempt history, and paginated delivery browsing, one controlled replay per failed event, and administrative client-token rotation and revocation, plus durable per-client request rate limits, capacity quotas, and administrative operational metric snapshots, a private exporter, tested alerts, and an isolated recovery demo, active private monitoring, Telegram alerts, and coordinated 30-day history retention.

PLANNED

Operational readiness

The authenticated API and worker are live, with a verified signed HTTPS integration and isolated backup/restore checks. Scheduled off-host backups and release automation are next.

Inspect the implementation and tests ↗

READ IT. RUN IT. TRACE IT.

Good delivery starts
with understandable code.

Open the repository ↗