A backend built to follow through

Every event
deserves an
arrival.

Receivers fail. Workers restart. Networks get in the way.
A resilient webhook engine keeps the delivery moving.

FASTAPI · REDIS STREAMS · ASYNC WORKERS

THE DELIVERY PATHAt least once
01 / INGESTAccepted.HMAC verified · ID claimed
202
atomic enqueue
02 / PERSISTWork survives.Redis Streams · pending state
worker signs exact bytes
03 / DELIVERDelivered.Receiver accepts · job acknowledged
2xx

A failed attempt takes another route.
Persist. Back off. Retry.

ACKNOWLEDGE AFTER A SAFE TRANSITION

Built for failure.
Backed by evidence.

28,800 / 28,800

Delivered in the 24-hour soak

288 / 288

End-to-end smoke checks passed

0

Observed OOMs or unexpected restarts

Historical test
September 2026

01 / Interactive playground

Follow an event.
Even when things go wrong.

Choose a scenario. Step through the decisions.
Sample events; no production traffic.

delivery / playground
SIMULATION
EVENT TRACESTEP 01 / 02

    Acceptance creates a job. It does not confirm arrival.

    LATEST DELIVERY STATEPENDING
    sample-order-1001
    Event type
    order.created
    Attempts
    0
    Last response
    202 · Accepted
    Next action
    Waiting for a worker
    GET /deliveries/{event_id}SAMPLE JSON

    Status timestamps are illustrative. Retry backoff includes jitter.

    At-least-once delivery means a receiver can see an event again. Deduplicate by event ID.

    02 / The actual service

    A real backend.
    A live connection.

    These checks call this service directly.
    Sample events stay in the playground above.

    System readiness

    Checking…

    Is the queue reachable? Is a worker listening?

    Redis connection
    Checking…
    Worker heartbeat
    Checking…

    Requesting /readyz…

    Readiness checks dependencies. A delivered event is the end-to-end proof.

    Inspect a delivery

    LIVE / READ ONLY

    Already sent an event? Look up its current state.

    Use an ID from your API request. Records expire after the configured retention window (24 hours by default).

    03 / Engineering, in the open

    The guarantees.
    And the receipts.

    Read the implementation
    01

    One ID. One enqueue.

    A Redis Lua script claims the event ID and queues the job atomically. Concurrent duplicates cannot create extra jobs within the idempotency window.

    02

    Failure has a path.

    Failed attempts persist before acknowledgement. Exponential backoff with jitter leads to another attempt; exhausted jobs go to the dead-letter queue.

    03

    Crashes don’t erase work.

    A healthy worker reclaims stale, unacknowledged messages. Outbound HMAC signs the exact bytes sent to the receiver.

    RELIABILITY / 24 HOURSA

    28,800 delivered.

    A September 6–7, 2026 soak on the historical Oracle VM: 288 cycles, 288 smoke checks, zero failed cycles. Peak RAM: 621 of 954 MiB.

    Inspect the audited summary
    PERFORMANCE / LOCAL INGESTIONB

    675.48 requests/s.

    A 30-second local k6 run on September 12, 2026. Ingest p95: 74.90 ms. No worker ran; this measures enqueueing, not delivery capacity.

    Inspect the benchmark metadata

    Historical measurements under documented test conditions. The service runs on one host, has no cross-host high availability, and does not guarantee delivery ordering. DLQ inspection and replay use a protected operator CLI.

    Built by Vansh Chauhan

    Small surface.
    Serious delivery.

    Explore the contracts. Inspect the implementation.
    Every claim has somewhere to lead.

    Explore the API