Zyvan — Webhook Reliability Infrastructure

Active Development — Zyvan is being built as infrastructure for reliable webhook delivery, handling event ingestion, retries, failures, replay, and delivery observability.

Overview

Zyvan is infrastructure for reliable webhook and event delivery.

Modern applications depend on webhooks for payments, orders, notifications, account events, integrations, and other asynchronous workflows.

Sending a webhook is easy.

Making sure it is not lost, safely retried, traceable, and recoverable when the destination fails is the harder problem.

Zyvan provides that reliability layer between an application and its external webhook destinations.

The core workflow is:

Receive → Persist → Queue → Deliver → Retry → Recover → Replay

The Problem

Webhook delivery often looks like a simple HTTP request:

Application
    ↓
POST Webhook
    ↓
Customer Endpoint

But real systems have to deal with:

• Destination downtime
• Timeouts
• 5xx responses
• Network failures
• Duplicate events
• Retry storms
• Permanently failing destinations
• Lost delivery history
• Manual recovery

A reliable webhook system needs more than a request and a response.

It needs durable storage, retry policies, idempotency, failure handling, replay, delivery history, and secure outbound requests.

What I'm Building

Zyvan sits between an application and its webhook destinations.

A developer sends an event to Zyvan:

Application
    ↓
Zyvan API
    ↓
Persist Event
    ↓
Queue
    ↓
Delivery Worker
    ↓
Webhook Destination

When delivery fails:

Delivery Failure
      ↓
Retry
      ↓
Retry
      ↓
Retry
      ↓
Dead Letter
      ↓
Inspect / Replay

The application does not need to build this reliability layer itself.

Key Engineering Decisions

Persist before queuing. The event is written to the database before it enters the queue. If the worker crashes mid-processing, the event is still recoverable. No events are lost to infrastructure failures.

Idempotency as a core constraint, not a feature. Queues guarantee at-least-once delivery, which means duplicates happen. The system uses idempotency keys to detect and suppress duplicate deliveries, so retries are always safe on the destination side.

Backoff with jitter. Naive exponential backoff causes retry storms when multiple events fail simultaneously. Adding randomized jitter spreads the retry load and prevents a recovering destination from being immediately re-hammered.

Tenant-level isolation in the queue. A high-volume tenant sending 100,000 events shouldn't delay a smaller tenant's delivery. Queue priority and rate limits are modeled at the tenant level from the beginning.

HMAC signing on every outbound request. Destinations can verify that requests genuinely came from Zyvan, not a third party. Security is a first-class concern, not an optional add-on.

Current Status

The first version is focused entirely on getting the core reliability path right:

Receive → Persist → Queue → Deliver → Retry → Recover → Replay

That complete loop — working correctly, reliably, at production quality — is the foundation everything else builds on. Once it's solid, the next stage covers stronger observability, tenant-level controls, advanced rate limiting, and deeper developer tooling.

Building in public. Shipping toward something real.

What This Project Demonstrates

For anyone reviewing this as part of hiring or due diligence:

This project sits in the infrastructure layer of the stack — the kind of engineering that's invisible when it works and catastrophic when it doesn't. Building it well requires understanding distributed systems, failure modes, queue semantics, idempotency, and multi-tenant architecture at a level that most web projects don't demand.

Zyvan is unfinished. That's expected — it's being actively built right now. What the project demonstrates isn't completion; it's the ability to identify a real problem in a real market, design a production-quality system to solve it, and execute on that design independently from architecture through implementation.

The decisions being made here — how events are persisted, how retries are scheduled, how tenants are isolated, how failures are surfaced — reflect genuine systems thinking, not just following a tutorial.