Skip to main content

⚙️ Core Technical Flows

Because managing potentially millions of WhatsApp broadcasts instantly guarantees rapid backend starvation and Cloud API throttling, Kloyst strictly organizes processing into isolated pipelines.

1. Rate Limiting & Queue Pipeline​

We utilize heavily localized Redis instances mapped to BullMQ interfaces to achieve strict throughput control.

The Problem​

If 5 clients press "Send Campaign" involving 20,000 contacts simultaneously, iterating native HTTP calls will severely violate Meta's max Rate Limits (e.g., 80 requests per second under lower tiers).

The Architecture​

  • Limiter Properties: Redis processes guarantee global rate limiting logic. It explicitly prevents processing > X jobs per second globally across multiple NestJS scaling nodes.

2. Retry Mechanism for Failures​

Webhooks and external APIs naturally fail occasionally (Network partitions or Meta outages).

  1. We implement an Exponential Backoff Strategy in BullMQ.
  2. If Meta throws a 500 Server Error on a dispatch attempt, the job drops back into Redis and sleeps for (2^attempts * 1000)ms.
  3. If max attempts are reached (e.g., 5), it drops down to the PostgreSQL MessageLog state mapped as FAILED.

3. Webhook Parsing Funnel​

Meta throws chaotic batches of webhooks mapping arbitrary nested arrays. Our funnel explicitly isolates and cleans entries sequentially.

  • Dead-Letter Resiliency: The Webhook receiver route is the single most important latency route on the platform safely executing logic. We aggressively cache checks.
  • If we do extremely complex operations, we simply dump the Webhook directly into a Redis WH_QUEUE and respond 200 OK to meta within milliseconds, allowing background workers to calculate the ledger later protecting us from Meta's strict webhook timeout constraints.