Conduit

Problem

Every integration project starts clean and rots the same way: one client needs a custom CRM field, another sends webhooks out of order, a third retries on a timeout and double-books a meeting. Left alone it becomes per-client spaghetti no one wants to touch. Conduit is the framework that refuses to let that happen.

Approach — architecture

A tenant / adapter / router model. Every external system is an adapter implementing one SDK contract. Inbound events hit an idempotent pipeline — dedup, order, then route to adapters — so replays and out-of-order deliveries are normal, not incidents.

Idempotency and ordering live before routing, so adapters stay simple.

What I built

A pnpm monorepo: the event router, an adapter SDK, and per-tenant config in Postgres with Redis for dedup keys and replay state. It ships both as SaaS and self-hosted from the same core.

// Idempotency: first writer wins; duplicates are acknowledged, not reprocessed.
const seen = await redis.set(`evt:${tenant}:${event.id}`, '1', {
  NX: true,
  EX: 86_400,
});
if (!seen) return ack(event); // duplicate delivery — safe no-op
await router.dispatch(tenant, event);

Hard parts

• Adapter abstraction — one contract that CRMs, telephony and webhooks all fit.
• Webhook idempotency & ordering — dedup keys plus per-entity sequencing.
• Multi-tenant isolation — config, secrets and rate limits scoped per tenant.
• Replay / merge — re-run a window of events deterministically to heal state.

Outcome

Onboarding a new integration is now writing one adapter against the SDK, not forking the pipeline. The idempotent core turns “webhooks are unreliable” from a recurring outage into a solved problem.

Links

Repo and docs are placeholders until this is public.