Zyvan — India-First Webhook Reliability Infrastructure

Active Development — Zyvan is currently being built. This page documents the architecture, decisions, and progress as the project evolves.

Overview

Zyvan is an India-first infrastructure platform for reliable webhook and event delivery.

Every modern SaaS product sends webhooks — payment confirmations, order updates, user events, system notifications. When those webhooks work, nobody thinks about them. When they fail silently, teams scramble to figure out what happened, replay events manually, and explain to customers why their integration broke.

The problem isn't sending the webhook. It's everything that happens when the destination isn't ready: the 500 errors, the timeouts, the retries, the duplicate deliveries, the events lost forever because nothing caught them. Every engineering team that ships a webhook system eventually builds their own retry logic, dead-letter handling, and delivery monitoring — and they build it in a hurry, usually after something breaks in production.

Zyvan is the infrastructure layer that handles all of that reliably, exposed as a developer-facing platform so teams don't have to rebuild it themselves.

The Problem

Webhooks look simple until they fail.

A destination goes down for 20 minutes. Does your system retry? How many times? With what backoff? If it retries too aggressively, you hammer a recovering service. If it doesn't retry at all, events are lost. If it retries without idempotency controls, you deliver the same event multiple times and corrupt data on the receiving end.

Most teams handle this by bolting retry logic onto their existing queue system — usually as an afterthought, usually incomplete. The result is a system that works fine in development and breaks quietly in production.

What a proper webhook delivery system actually needs:

• Durable ingestion — events persisted before anything else happens, so nothing is lost on crash
• Idempotency — safe to retry without causing duplicate side effects on the destination
• Intelligent retries — exponential backoff and jitter so retries don't compound an outage
• Dead-letter handling — failed events isolated for inspection and replay, not just silently dropped
• Event replay — recover from downstream failures by replaying events after fixing the destination
• Multi-tenant isolation — one customer's volume can't starve another's delivery queue
• Delivery observability — know exactly what was sent, when, what it got back, and why it failed

Building all of this correctly takes serious engineering effort. Zyvan builds it once, as a platform.

What I'm Building

Zyvan sits between an application and its webhook destinations. A developer sends an event to Zyvan; the platform takes responsibility for storing, queueing, delivering, retrying, and tracking it.

Send Event → Persist → Queue → Deliver → Retry if needed → Recover / Replay

From the application's perspective, it's a single HTTP call:

const response = await fetch("https://ingest.zyvan.dev/v1/events", {
  method: "POST",
  headers: {
    "Authorization": "Bearer zyvan_live_xxx",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    type: "invoice.paid",
    data: { invoiceId: "inv_123" },
  }),
});

From there, Zyvan handles everything. The destination receives the webhook, signed with HMAC so it can verify authenticity. If delivery fails, the system retries with exponential backoff. If it keeps failing, the event moves to a dead-letter queue where the developer can inspect it and replay it once the destination is healthy.

Every delivery attempt is recorded — status code, response body, latency, timestamp. There's no guessing about what happened.

Architecture

The system is built around a durable event pipeline that decouples ingestion from delivery processing.

The ingestion API accepts an event, validates the API key, persists the event to PostgreSQL, and enqueues it for delivery — all before returning to the caller. The caller gets a confirmation immediately; delivery happens in the background.

PostgreSQL is the source of truth. Redis and BullMQ handle the async delivery queue and retry scheduling. This separation means the system can absorb traffic spikes without losing events — if the queue backs up, events wait in durable storage rather than being dropped.

The architecture is deliberately modular so individual components can be improved independently. The delivery worker, retry engine, and dead-letter handler are all separate concerns.

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.

Why India-First

The webhook infrastructure market has strong global players — Svix, Hookdeck, Convoy. But none of them are built with the Indian market as a primary concern.

Indian SaaS companies, fintech platforms, e-commerce integrations, and payment providers have specific needs: INR pricing that makes sense at Indian market rates, India-region infrastructure for compliance and latency, and integration patterns that match Indian payment and commerce ecosystems (Razorpay, Shiprocket, Shopify India, and similar).

Zyvan starts with the Indian developer ecosystem as its primary audience. The pricing, infrastructure, and integration roadmap are all designed around Indian market realities — with the architecture fully capable of serving global customers as the platform grows.

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.