Duerelay is an event integrity platform built for production systems where webhook failures are not merely inconvenient — they result in missed payments, broken provisioning, misapplied entitlements, or quota drift that compounds over time.
The platform sits on the path between inbound event intake and downstream execution. Its purpose is not to capture requests for debugging, though it supports that. It is to make event handling deterministic, observable, and enforceable — at each step from ingest through metering and audit.
Duerelay is relevant anywhere a business-critical system relies on event-driven control flow: payment confirmation, subscription state changes, access provisioning, entitlement enforcement, or any downstream action where a silent failure or duplicate execution carries direct cost.
This document describes the architecture, integrity model, and operational posture as currently implemented.
The Problem
Webhook infrastructure fails in ways that are easy to underestimate. The failure modes are not exotic. They accumulate.
Silent failures. A delivery attempt returns a non-2xx status or times out. The originating system may retry, or may not. Without active delivery monitoring, no one knows until a downstream symptom surfaces — often hours or days later.
Duplicate processing. Retry logic in event originators is common. Without idempotency enforcement at the receiver, the same event is processed multiple times. In billing and provisioning contexts, this creates real state divergence.
Replay ambiguity. When a failure is identified, replaying an event without replay-specific controls risks re-executing side effects that already occurred — re-billing, or re-provisioning an already-active resource.
Quota and accounting drift. Usage accounting based on event counts is only reliable if the count is atomic and consistent. If usage is incremented outside a transaction, or if duplicate events are not suppressed, billing data drifts from the true usage.
Weak tenant boundaries. Multi-tenant systems that co-mingle event processing without organizational scoping expose tenant A's event data or processing context to tenant B's request paths. This is a correctness failure, not just a security one.
Operational blind spots. When an incident occurs, the ability to reconstruct what happened — which events were received, which were processed, which failed and why — determines recovery time. Without structured audit surfaces, incident resolution becomes guesswork.
These failure modes occur in production systems that rely on off-the-shelf webhook relays, request bins, or simple forwarding proxies without enforcement or accounting layers.
What Duerelay Is
Duerelay is an event integrity and control-plane layer. It is not a request bin or mock endpoint for development. It is not a debugger-only tool for inspecting payloads. It is not a transport relay that forwards events without understanding them.
It is a system concerned with the correctness of event execution end-to-end. This means it enforces identity and organizational scope at intake, applies policy before events reach downstream handlers, records metered usage atomically, and exposes structured surfaces for observability and incident recovery.
A debugger captures. A relay forwards. Duerelay enforces.
Integrity Model
Six properties define the integrity model. Each is a runtime invariant, not a documentation claim.
Identity and organizational scope. Every event processed through Duerelay is associated with a verified organizational identity. Org scope is derived server-side from the authenticated session or API credential — never from request body, query parameter, or client-supplied header. This is a hard invariant with no bypass path in the request pipeline.
Tenancy and isolation boundaries. Organizational boundaries are enforced at every layer: storage, processing, and response construction. An operation scoped to Organization A cannot read, modify, or trigger state belonging to Organization B. This is structural, not policy-based.
Idempotency and duplicate suppression. Events are assigned stable identifiers. Duplicate submissions — from retries, replays, or client-side bugs — are detected and suppressed rather than re-executed. This property is critical in payment-adjacent and provisioning-adjacent pipelines where double-execution has direct cost.
Atomic enforcement and policy application. Enforcement decisions — whether an event should be admitted, quota-checked, blocked, or metered — are applied within a single bounded admission function. There is no multi-step path where an event can pass quota enforcement and then fail metering, or vice versa. This eliminates a class of race conditions common in distributed enforcement implementations.
Provider isolation and bounded external coupling. Duerelay integrates with external providers through isolated, bounded interfaces. Provider-specific identifiers and states are not exposed in customer-facing API responses or in event processing paths. Provider coupling is contained to defined integration points.
Runtime truth and auditability. Enforcement state is always computed at runtime from stored state. There are no cached enforcement decisions that can drift from truth. Audit surfaces expose what actually happened in the system, not what was intended.
Execution Model
Events move through a defined path. Each step has a specific responsibility.
Ingest. Events arrive at a hardened intake endpoint. The ingest layer handles volume, initial routing, and source authentication without performing business logic.
Authenticate and verify. The event is authenticated against the receiving organization. Source identity is established. This step fails closed — unauthenticated events do not proceed.
Scope. The event is assigned to the correct organizational context. All subsequent processing uses this scope. No request-supplied scope data is trusted past this point.
Enforce. The enforcement layer evaluates the organization's current policy state: quota position, billing status, capability flags, and enforcement configuration. This is the single decision point for admission or rejection. It is atomic.
Deliver and process. Admitted events are delivered to the configured endpoint(s) and processed according to delivery configuration. Delivery state is tracked with attempt-level resolution.
Meter. Usage is recorded atomically as part of the processing transaction. Metering is not a background job. It is a committed step in the event lifecycle.
Audit and observe. The event record, delivery outcome, and enforcement decision are written to an observable surface. This record supports incident diagnosis, replay, and billing verification.
Sandbox and Production Separation
Sandbox and production environments are distinct trust domains with structural separation at the data layer. They do not share event storage, quota state, enforcement state, or billing context.
This separation exists for two reasons beyond developer convenience.
First, billing integrity. Usage metered in sandbox must not affect production billing, and production quota must not be consumed by test traffic. These are distinct accounting ledgers.
Second, enforcement correctness. Testing enforcement behavior in sandbox must not require production credentials, production endpoints, or production state. A sandbox environment that collapses into production trust context is not a meaningful test environment.
Duerelay enforces this separation at the organizational level. An organization operating in sandbox mode cannot interact with production resources, and vice versa.
Billing and Usage Integrity
For systems where event volume maps directly to billing — either Duerelay's own usage billing or a customer's downstream billing logic triggered by events — accounting correctness is a product requirement, not a nice-to-have.
Duerelay's usage metering is atomic. Usage increments occur within the same transaction boundary as event admission. An event that is admitted is metered. An event that is rejected is not. There is no window where an admitted event can fail to be counted, or a rejected event can contribute to usage.
Quota enforcement is computed against metered usage, not estimates. Overage detection is based on the same counters that drive billing calculations. Organizations near quota thresholds encounter enforcement decisions based on committed usage data, not stale snapshots.
This design is intentional. In revenue-critical systems, billing ambiguity erodes customer trust more reliably than any individual delivery failure.
Operational Posture
Duerelay's operational surfaces are designed for incident diagnosis, not just steady-state monitoring.
Observability. Delivery attempts, enforcement decisions, and event lifecycle events are structured and queryable. Operators can determine the exact state of any event — received, rejected, admitted, delivered, failed — without reconstructing logs.
Incident diagnosis. When a delivery failure occurs, the failure context (attempt log, response codes, payload) is preserved and accessible through the control-plane interface. Diagnosis does not require access to the originating system.
Replay and debugging context. Events can be replayed with explicit controls. Replay operations are scoped to specific events, run through the same enforcement path as original delivery, and produce audit records distinct from the original event's record. This prevents replay from obscuring what actually happened.
Auditable changes. Changes to endpoint configuration, enforcement state, and organizational policy are tracked. The audit posture is designed to answer "what changed, and when" for any operational incident.
Who Duerelay Is For
Strong fit. SaaS products with revenue-affecting webhooks — payment confirmation, subscription lifecycle, seat provisioning, entitlement grants. Event-driven internal platforms where downstream execution must be reliable and auditable. Teams whose current tooling is a request-capture tool or a simple forwarding proxy that lacks enforcement, idempotency, or structured observability. Systems where a silent failure or duplicate event carries direct cost.
Not primarily for. Teams building static websites or non-event-driven applications. Development-only webhook inspection needs where production correctness and billing enforcement are not concerns. Workloads with no downstream consequence to event loss or duplication.
Current Scope and Future Direction
Today. Duerelay's practical focus is webhook and event intake integrity: authenticated ingest, organizational scoping, atomic enforcement and metering, delivery tracking, structured observability, sandbox/production separation, and control-plane tooling for incident diagnosis and replay.
Direction. The platform is designed to extend toward a broader event integrity layer — covering more event origin types, richer enforcement policy, and deeper integration with the billing and provisioning systems that depend on event correctness. These are directional, not committed deliverables.
The platform is in active production use. Its current scope is intentionally narrow relative to the broader vision. That is a design choice.
Duerelay is built on the premise that event infrastructure fails in predictable ways, and that predictable failure modes are engineering problems, not acceptance criteria.
The platform's architecture reflects a deliberate prioritization: correctness over convenience, enforcement over observation, determinism over eventual consistency.
For systems where events drive revenue, access, or customer trust, that prioritization is the point.