WhatsPie

a. Memory Leaks in Concurrency

Running hundreds of concurrent WhatsApp WebSocket connections under Baileys in a single Node.js process causes severe memory leaks. Baileys maintains a heavy in-memory cache of contacts, chats, and pre-keys, which quickly triggers Out-Of-Memory (OOM) crashes.

We solved this by designing an isolated session runner architecture in whatspie-node-v3. Each connected device session runs within its own isolated client context. Rather than saving session credentials in files, which makes multi-node scaling impossible, we serialized all session state details (keys, pre-keys, and creds) directly to the PostgreSQL database. We leveraged Prisma Client and wrapped the credentials update tasks in the usePrismaAuthState handler with an async-lock mutex. This guarantees that concurrent authentication updates do not cause database write race conditions.

b. API Gateway Bottlenecks

The original API Gateway was built in Node.js, which struggled with high-volume database queries and request latencies under peak marketing broadcast loads. Average response times exceeded 200ms, creating HTTP bottlenecks.

We resolved this bottleneck by rewriting the public REST API Gateway in Go (whatspie_api_v2). By using Gin, GORM for connection pooling, and the Sonic JSON serializer, we reduced baseline response times by 75%, down to 10ms. The Go gateway processes authentication and validation synchronously, then delegates the HTTP relay request to the WhatsApp worker inside an asynchronous goroutine, instantly returning a successful response to the merchant client.

c. Webhook Reliability

Merchant servers often experience downtime or latency during broadcast campaigns. Direct webhooks from the worker without a retry buffer resulted in high message status loss and timeout failures.

We engineered an automated retry webhook dispatcher in the Node.js worker with exponential backoff (2s, 4s, 8s) up to 3 attempts, capped with a strict 10-second timeout. To prevent merchant servers from bottlenecking on raw binary media downloads, we built an automated media upload bridge. The worker intercepts media attachments, downloads the binary from WhatsApp, uploads it to AWS S3, and replaces the raw binary payload with the S3 CDN URL in the webhook metadata.

a. Scalability Targets

The system goals focused on moving from single-device automation to a robust multi-tenant platform. We defined clear metrics:

- Support up to 10,000 active concurrent WebSocket device sessions across distributed Node worker instances.

- Reduce RAM consumption to under 50MB per inactive WhatsApp session.

- Maintain message API dispatch response times under 100ms for bulk broadcasts.

b. Developer Experience / DX

Making the platform developer-first was crucial for adoption. The interface goals were:

- Provide a sandbox environment using Docker Compose for local service emulation.

- Lower setup onboarding time by using WebSockets for real-time QR code generation, reducing connection delays from 20s to under 4s.

- Deliver clear, interactive API documentation mapping authentication, contact validation, device creation, and webhook delivery formats.

a. System Architecture Design

We started the design phase by drawing sequence diagrams for session initialization and credential syncing. Decoupling the platform into three specific containers was critical to isolate resource-intensive WebSocket sessions from the public REST API and administrative interface. We modeled the request routing using Docker networks, ensuring that database connections remained secure.

b. Database Schema Modeling

We designed the relational schema to handle multi-tenant subscriptions and billing. The database maps:

- users (storing balances, API tokens, and reseller configurations) to invoices and subscriptions.

- devices (tracking phone numbers, paired statuses, node URLs, and proxies) to device_sessions.

- device_sessions (storing fragmented Baileys credential details like pre-keys and creds in JSON string blocks).

- messages (storing wa_id, type, body, status, params JSONB, and file attachments).

c. UI/UX Dashboard Flow

We mocked the dashboard interface in Figma, designing a sleek dark UI with glassmorphism components. For the merchant panel (whatspie_app), we used Laravel Filament v3 to build quick administration tables for devices, webhook logs, and subscription billing.

For the chatbot builder, we created a visual drag-and-drop React interface using React Flow (@xyflow/react) and Inertia.js. Non-technical merchants can easily connect triggers, conditional branches, S3 files, and Gemini auto-responders, which are saved as serialized JSON graphs that the backend parses on incoming webhooks.

a. Performance Profiling

To verify the Go rewrite, we performed load tests simulating high-concurrency broadcasts. Memory profiling showed that the Go API gateway maintains a stable footprint of 30MB, compared to Node’s 150MB, representing an 80% memory footprint reduction.

Database query optimization was verified using GORM preloading, reducing query overhead and preventing N+1 queries during bulk requests.

b. Socket Reconnection Tests

We wrote reconnection logic to handle sudden network disruptions. We built a stale connection sweeper (startStaleConnectionCleanup) that sweeps connections every 2 minutes. If a session is closed and has not updated for 5 minutes, it is swept from memory. If the device remains ACTIVE, the worker launches a reconnect attempt (capped at a maximum of 5 attempts) using an in-memory NodeCache map to prevent infinite loops.

c. API Latency Metrics

We tracked response latencies across core routes using Postman. The message dispatch endpoint (/messages) responded in under 10ms, since Go offloads the worker REST request to a background goroutine. The test suite endpoints (/test/success and /test/error?type=panic) verified that panic recoveries and error traces are captured cleanly by the Sentry logger, including user and device context tags.

a. API Specs Generation

To streamline developer handoff, we built a documentation portal using Docusaurus (whatspie-api-docs). The portal details the entire REST API surface, including authentication headers, device management endpoints, message payloads, contact validation, and webhook parameters. We wrote MDX pages with parameterized tables and copy-pasteable request code blocks in cURL, PHP, and JavaScript.

b. Sandbox Environment

We created a local sandbox using Docker Compose to replicate the three-tier setup (PostgreSQL, Go Gateway, Node Worker, and Redis). This allows developers to run the services locally, execute QR pairings, validate webhooks, and test group metadata updates (UpdateGroupMetadata) or contact additions (AddGroupMembers) before deploying to production.

a. Lessons in Microservices

Decoupling the platform into specialized microservices is essential when building socket gateways. Separating the Go REST gateway from the Node.js WebSocket engine ensures that dashboard access and API queries remain responsive even during heavy message campaigns.

b. TypeScript Adoption

Using TypeScript to write the WebSocket runner engine (whatspie-node-v3) was critical. Typing the Baileys client, message models, and auth state helpers prevented runtime type mismatches and simplified connection event handling.

c. Laravel Ecosystem

Laravel Octane combined with Filament v3 is extremely productive for billing dashboards, payment gateways (Midtrans and PayPal), and admin controls, automating invoice validation and balance top-ups without manual checks.