pingbus.live

Every growing team knows the moment: something important happens and you need to tell someone. You reach for email. Then SMS. Then WhatsApp. Then push. Then a Zapier hook for the ops Slack. Six months later you have five notification libraries, four sets of credentials, three retry strategies that disagree, and a 'send a message' function nobody wants to touch. PingBus exists to prevent that — one API call, all channels, queued, signed, retried, logged, handled.

The first design decision in a developer tool is psychological, not technical. The integration developer thinks in HTTP verbs and API keys — they want client.whatsapp.sendMessage() to just work, and every new concept before their first message is a reason to leave, so PingBus has to feel invisible. The operator lives in dashboards — they scan a QR once, watch delivery rates, and investigate why one message missed at 2am; they want control without memorizing routes. The same deployment serves both.

The dashboard borrows from Vercel and Railway: dark-by-default, monospace-adjacent, dense but not cluttered — information density is a feature for this audience. The Channel Store presents each channel as a scannable card so a developer at 11pm identifies 'Email: connected' vs 'SMS: not configured' in under two seconds. API consoles use a split pane — compose left, live delivery log right — and the first time a developer watches a message travel queued → sent → delivered, PingBus earns their trust. Color is functional: green READY, amber QR_REQUIRED, red DISCONNECTED, gray INITIALIZING.

The name is deliberate — a router decides where to send things; a bus carries them reliably, absorbing spikes and handling failure without asking the producer to care. Nothing is sent synchronously: an API call validates and authenticates, writes a queued log entry to MongoDB, pushes a job to a Redis-backed Bull queue, and returns 202 Accepted immediately. A worker picks it up, delivers against the real channel API, and updates the log to sent or delivered. The HTTP layer stays fast, failures recover without client cooperation, and backpressure lives at the queue, not the app.

The most demanding and most valuable channel uses Baileys — a protocol-level client speaking the WhatsApp WebSocket binary directly, no browser, no Puppeteer. Each session is a ~50MB Node WebSocket, so a single 8GB VPS safely holds 150 concurrent sessions and the image sits at ~250MB instead of ~1.2GB. The old Chromium-per-session tools (whatsapp-web.js) burned 300–500MB each; Baileys takes the same hardware from 10–15 sessions to 150, dropping EC2 Spot cost from ~$0.87 to ~$0.09 per session per month.

Auth state uses Baileys' useMultiFileAuthState over a per-instance tmpdir backed by a Redis hash (baileys_files:{instanceId}), falling back to MongoDB on cold start and snapshotting back on every creds.update, throttled to once per 5 minutes to avoid write amplification. The Signal key store is wrapped in a cacheable LRU to prevent 'Invalid PreKey' races. Reconnection is staged exponential backoff (1s → 10s → 30s → 120s), a loggedOut reason triggers clearAuth() for a fresh QR, and each session registers in a Redis Session Registry mapping instance → owning worker node — the foundation for horizontal scaling.

Email is multi-tenant per instance with AES-256-GCM encrypted credentials and a test-before-save 'Ping' that reports real SMTP latency. SMS (Twilio) uses a two-phase model that never conflates 'accepted' with 'delivered' — the carrier webhook confirms the handset. Push abstracts away device tokens: register, then target a userId, token or topic; PingBus batches FCM multicast and auto-prunes NotRegistered tokens. Outgoing webhooks are queued, HMAC-SHA256 signed with the user's own API key, and retried 1m → 5m → 30m before being marked dead.

The real power is the Unified Multi-Channel Dispatcher: a strategy-based send that renders templates once (no content drift across retries), fans out to channel queues and tracks each in a DispatchEvents collection. Parallel mode fires everything at once for maximum reach; waterfall fires the primary first and falls back on failure or timeout when cost matters. A Redis lock (SET delivered:{id}:{channel} NX EX) stops a fallback firing the instant a delayed 'delivered' arrives, and per-dispatch idempotency keys make sending the same payload twice in 24h a queue-level no-op.

SDKs ship for Node/TypeScript, Python, Go and Java, all governed by one normative SDK Master Spec: env-var auto-detection, transparent auth routing (Bearer vs WhatsApp path-token injection), exponential backoff with jitter, typed response envelopes and shared error codes. Method names are identical across languages (client.email.send, client.sms.send), so migrating Python → Go, every name is recognizable. The Node SDK doubles as a React integration exporting hooks like useWhatsAppStatus, and verifySignature uses constant-time comparison in all four to close timing attacks.

Beyond human developers, PingBus embeds an MCP (Model Context Protocol) server directly in the Express backend. AI agents — Claude Desktop, a custom Anthropic-SDK agent — connect over SSE and discover tools dynamically: dispatch_notification, check_dispatch_status, send_whatsapp, send_email, send_sms. Ask an agent to 'alert the dev team the database is down, WhatsApp first then SMS' and it constructs a waterfall payload and calls the tool. The MCP server reuses the existing Bull infrastructure — no duplicate delivery paths — and passes the user's Bearer token through SSE to scope every call.

Security is at the boundary: pk_-prefixed Bearer keys on every route, AES-256-GCM SMTP encryption with a key that never touches the database, HMAC-signed webhooks, per-userId multi-tenancy on every query, and Twilio X-Twilio-Signature verification against status spoofing. Scaling is additive, not a rewrite — the Session Registry routes each stateful WhatsApp session to its owning node, worker load is reported to Redis every 30s for least-loaded placement, and the path runs single Docker Compose (~$24/mo) up to a multi-region K8s + Atlas M20 cluster, with on-demand Squid proxy containers per session.