CodeNXT Lab · Case study 01 / Bhejna
Bhejna.
High-throughput WhatsApp delivery engine. Contract-first, queue-backed, built for messages that cannot be silently dropped.
01
The brief.
What they came with, in their words.
We wrote this brief for ourselves. Every WhatsApp integration we had been handed did the same thing under load: accepted a message, returned 200, and lost it. We wanted a delivery path where a message is either delivered, retried, or visibly parked. Never quietly gone.
02
Constraints.
The real ones, not the stated ones.
- The WhatsApp Cloud API rate-limits, and it fails in ways that look like success. A retry has to be safe to run twice.
- A dropped message is not an error we get to discover later. The failure has to be visible at the moment it happens.
- We run it on our own money, so the idle cost has to stay near zero and scale only with volume.
03
What we built.
The system, and what it runs on.
A queue sits between the producer and the WhatsApp Cloud API, so accepting a message and delivering it are separate concerns with separate failure modes. The delivery worker owns retries with backoff; anything that exhausts them lands in a dead-letter queue rather than disappearing.
The contract comes first. Producers write against a fixed message schema, so the delivery path can change underneath them without a coordinated deploy.
10,000 messages/day · 99.9% measured uptime
Go · Postgres · Redis · NATS · Docker · Cloudflare Workers
04
The system.
One drawing. No screenshots.
05
What we did not build.
Every scope carries an exclusions list.
- No two-way inbox. Bhejna delivers messages; it does not host conversations or render a chat UI.
- No campaign builder, audience segmentation, or contact management. It is a delivery engine, not a marketing platform.
- No analytics dashboard. It reports delivery state; interpreting that is the calling system’s job.