All systems

i-Connect

A WhatsApp platform that has to deliver exactly once

Campaigns, sequences, a shared inbox, hosted forms, WhatsApp Flows and ordering with payment inside the chat — built on a channel that enforces its own rate limits and refuses to forgive a duplicate.

The problem

For a large number of businesses the customer is already in one app all day, and it is not the business's app. Reaching them there sounds like a messaging problem and is actually a correctness problem: the channel caps how fast you may send, charges per conversation, and gives a customer a direct and permanent way to report you for the message they did not want. A broadcast tool that is merely fast will eventually send something twice, and on this channel a duplicate is not a cosmetic bug.

How it is put together

  1. 01

    A send path that treats the channel's rate ceiling as a design constraint rather than a thing to retry against, with reconciliation after every campaign to prove what was actually delivered.

  2. 02

    Sequences triggered by inbound keywords, form submissions or time, with explicit behaviour when the messaging window has closed rather than a silent drop.

  3. 03

    Hosted forms and WhatsApp Flows, including screens that load their options from the business's own system at the moment the customer opens them.

  4. 04

    An ordering path with checkout inside the chat, payment through the seller's own gateway credentials, and an orders board — deliberately arranged so the platform never holds the money.

  5. 05

    A data lifecycle built for India's data-protection regime, with retention windows and erasure rather than retention by default.

The hard parts

Exactly once, at the ceiling, with the receipts

Fifteen thousand recipients at the platform's own per-second cap, every one delivered exactly once, verified afterwards by reconciliation rather than assumed from a success count. At-least-once is what the infrastructure gives you; exactly-once is what the business needs, and the distance between them is a claim ticket, a unique constraint the database enforces, and a reconciliation pass that is allowed to disagree with the sender.

The index that was invisible to the query that needed it

Sustained ingest sat around thirty-three messages a second and every instinct in the room said add capacity. The cause was a partial unique index defined with a type filter — correct, present, and silently unusable by the plain equality lookup that every contact fetch depended on, so each one was reading the whole collection. Adding ordinary lookup indexes beside the partial ones took sustained ingest past a hundred and thirty a second on the same hardware. The lesson is now a standing rule: a partial index with a filter is not evidence that the query using it is indexed. Check the plan, not the index list.

Approval is part of the architecture

This channel reviews message templates before they may be sent, rejects display names, and withholds capabilities until a business is verified — so the approval state of each template is data the product has to hold and show, not paperwork to be done once. Building as though approval were a launch task produces a platform that cannot tell its customer why a message did not go.

Does your send path have to be right as well as fast?

A message that goes twice is worse than one that goes late, and at volume you cannot tell the difference by looking. If your pipeline has to prove what it did rather than assert it, that is the shape of this problem.

Get in touch