IntelliSMS Business Messaging Platform

IntelliSMS Business Messaging Platform overview

IntelliSMS provides bulk business messaging and marketing workflows to enterprise customers. Next Olive built its next-generation infrastructure: a multi-platform messaging system that handles high-volume SMS campaigns through telecommunication carriers, runs rich-media WhatsApp marketing through the Meta Cloud API, and keeps a React web console and Flutter apps for Android and iOS in sync in real time. The platform is multi-tenant, with row-level tenant isolation in the database, and is built to SOC 2 Type II, HIPAA and GDPR requirements because some of its customers send healthcare Communications.

The engagement ran through five phases of an agile lifecycle. Requirement analysis mapped peak throughput rates, distribution methods and carrier gateway rules, and fixed the boundaries between microservices so bulk text processing stayed isolated from live marketing flows. Design and prototyping produced the network topology, entity relationship models and mock messaging engines used to verify payload sizes and caching logic before construction. Development built each module around asynchronous execution with no cross-service code dependencies. Testing subjected the queuing network to synthetic spikes and simulated failures to confirm throttling and backpressure work without dropping messages, alongside continuous scanning for vulnerabilities and memory leaks. Deployment built the cloud environments from Terraform across multiple availability zones and cut traffic over through canary releases, with automated alerting configured for long-term support.

Challenge in enterprise Communications

The legacy IntelliSMS application had three structural problems. Its monolithic backend could not sustain unexpected processing spikes: when one customer launched a large campaign, everything else slowed down. The database had no automated scaling, so growth meant manual intervention. And the web and mobile products lived in separate codebases, which produced constant synchronisation issues between what a user saw on the console and on their phone.

Two further constraints came from the channels themselves. Sending SMS at volume without respecting carrier rate limits gets a sender blocklisted, so dispatch speed had to be controlled per destination network and adjusted to live congestion signals. WhatsApp imposes strict file-size and template rules on media and interactive messages, so every asset had to be normalised before it reached Meta's servers. The objective was a fully decoupled, cloud-native communication network in which each channel has its own independent computing environment.

Solution architecture & delivery

Clients connect over HTTPS and WebSockets on TLS 1.3 to an API gateway and access control layer that terminates traffic behind a web application firewall and validates Okta-issued OAuth 2.0 tokens. Behind it sits a Kubernetes microservices cluster with separate pod groups for bulk messaging, WhatsApp API handling, sync and cache, and telemetry. RabbitMQ state nodes carry the asynchronous work; PostgreSQL managed nodes with primary-replica replication and point-in-time recovery hold relational data; a Redis primary/replica cluster provides cache, session state, counters and the pub/sub backplane; and AWS S3 buckets with SSE-KMS encryption store media. Every table carries an indexed tenant identifier and row-level security policies filter each query by the caller's validated token, so customers sharing hardware can never see each other's data.

The bulk messaging engine works as a pipeline. When a corporate customer starts a campaign, the application layer validates permissions, extracts the recipient phone database and formats the text into standard JSON transport objects. An inbound validation matrix checks each payload for data conformity, destination formatting and account balance before it may enter a queue. Dynamic partitioning splits large files into chunks so many processing pods send different parts of the same campaign simultaneously. Queues are separated by priority and destination network, and custom token bucket rate-limiting plugins, reading carrier limits from Redis, set dispatch intervals in real time; excess traffic waits in secondary queues that workers drain at a safe pace. Carrier feedback handlers parse return receipts to track delivery confirmations and slow dispatch when a network signals congestion, and damaged or unroutable records are diverted to a dead-letter queue for inspection without stopping main traffic.

The WhatsApp marketing gateway is an enterprise wrapper around the Meta Cloud API. An asset management microservice ingests source media and runs it through a formatting pipeline that resizes image arrays, transcodes video to optimised codecs, compresses documents and strips unneeded metadata to meet WhatsApp's size limits, then stores the result in S3 and links it to a template marker. Template handlers manage quick-reply fields, selection menus and call-to-action buttons within Meta's structural rules. Lightweight webhook receivers absorb sent, delivered and read signals and inbound replies, forwarding them to background workers, and conversation state analytics categorise reply text to trigger automated response workflows or hand the chat to a live operator.

The cross-device sync engine ties the web console and the Flutter apps together. Every message event, incoming answer or read receipt is written to PostgreSQL and published to Redis; WebSocket servers behind lightweight reverse proxies filter each broadcast to the active connections of that customer account. If a mobile client loses coverage it stores activity in an encrypted local SQLite database, then reconciles on reconnection using vector clock conflict resolution and delta payloads that send only changed data. Operationally the platform runs active-active across three availability zones, autoscales the messaging microservice to as many as fifty pods on Prometheus CPU and memory metrics, fails over the database to a replica in under thirty seconds, rotates AES-256 keys every ninety days through cloud key management, uses mutual TLS between services, applies expansion-and-contraction schema migrations for zero-downtime releases, and writes every administrative event to write-once audit storage for SOC 2 validation.

Key features of the IntelliSMS Business Messaging Platform

• Bulk SMS engine on RabbitMQ with inbound validation, dynamic campaign partitioning, priority queues and dead-letter isolation
• Token bucket rate limiting per carrier channel with feedback-driven dispatch speed to avoid carrier blocklists
• WhatsApp Business Platform gateway on the Meta Cloud API with template, quick-reply, menu and call-to-action message support
• Media optimisation pipeline that resizes, transcodes and compresses images, video and documents into S3-hosted assets
• Webhook receivers for sent, delivered and read events and inbound replies, with conversation analytics routing chats to automation or live operators
• Real-time cross-device sync over WebSockets and Redis pub/sub between the React console and Flutter Android and iOS apps
• Offline mobile mode with encrypted SQLite storage, vector clock reconciliation and delta payloads
• Multi-tenant row-level security, Okta single sign-on with role-based access, HIPAA data masking of sensitive message content and GDPR erasure and portability modules

Who this SaaS product is for

This architecture suits messaging providers and enterprises that send at carrier scale: bulk SMS and WhatsApp marketing vendors, customer engagement platforms, and regulated organisations such as healthcare providers that need PHI kept out of logs and message metadata. It is equally relevant to any SaaS team that needs one backend to serve a web console and native mobile apps with identical state, and that must show SOC 2 Type II, HIPAA and GDPR controls to enterprise buyers.

Impact & results

• Bulk messaging decoupled from the console: customers upload very large recipient lists without slowing the management interface or other services
• Load tests confirmed the queuing network throttles and applies backpressure under synthetic spikes without dropping messages
• Messaging microservice scales to up to fifty container pods within seconds of a traffic spike and consolidates when demand falls
• Carrier rate limits enforced automatically per channel, holding excess traffic instead of triggering network rejections and blocklists
• Single Flutter codebase for Android and iOS replaced separate mobile builds, with the web console and apps kept in sync by one event backplane
• Database failover to a replica in under thirty seconds; active-active deployment across three availability zones
• Zero-downtime schema changes through expansion and contraction migrations, and canary deployments for production releases
• SOC 2 Type II audit trail in write-once storage, HIPAA masking of medical identifiers in message bodies, and GDPR erasure across PostgreSQL, Redis and logs

FAQ about the IntelliSMS Business Messaging Platform