Interaq.ai - Messaging Automation
Engineering high-volume customer communication workflows.
A customer engagement platform where campaign delivery, application workflows and messaging infrastructure are each built on the technology suited to that workload.
- Industry
- MarTech · Customer Engagement
- Services
- AutomationProduct EngineeringMarketing & AnalyticsWeb & Mobile
- Platform
- Web Platform · Backend
- Technology
- React · Laravel · Golang · Redis · Kafka
Interaq.ai is a customer engagement and messaging automation platform. Businesses use it to build, run and track messaging campaigns, with WhatsApp Business messaging as the delivered channel.
The engineering interest lies in what happens after someone presses send. A campaign is a single user action that expands into a large volume of individual message deliveries, each with its own outcome, retry behaviour and status to report back.
KwikTech engineered the platform around that asymmetry, using a hybrid backend where campaign processing, application workflows and message infrastructure are handled by the technology best matched to each, rather than forcing all three through one runtime.
The challenge
Messaging platforms carry two workloads that want opposite things. Application work (accounts, templates, campaign configuration, reporting) is request-driven, benefits from a mature framework and changes often as the product evolves. Campaign delivery is the opposite: long-running, highly concurrent, and largely unchanging once correct.
Running both through a single conventional application backend forces a compromise. Campaign processing at volume competes with the requests that keep the interface responsive, and the user who launched a campaign watches the dashboard they launched it from slow down as it runs.
There is also a correctness dimension. Message delivery has real consequences: a retry implemented carelessly becomes a duplicate message to a real customer.
One action, many deliveries
A single campaign launch expands into a large volume of individual sends, each with its own outcome to track.
Competing workload profiles
Interactive application requests and sustained campaign processing degrade each other when they share a runtime.
Status that must flow back
Delivery outcomes have to reach reporting without the reporting path becoming a bottleneck on delivery.
Delivery correctness
Messages reach real customers. Duplicate or dropped sends are product failures, not statistics.
The approach
We separated the workloads rather than compromising between them, and chose each technology for the job it actually does.
Laravel runs the core application: accounts, templates, campaign configuration, reporting and the workflows that change most often as the product develops. This is the work where framework maturity and development speed pay off directly.
Golang handles campaign job processing. When a campaign runs, expanding it into individual deliveries and working through them at volume is concurrent, long-running work, and it is isolated from the application backend so a large campaign does not slow the interface being used to monitor it.
Kafka carries messaging between those components asynchronously, which is what allows them to be decoupled: campaign processing does not block waiting on downstream work, and delivery outcomes flow back without coupling reporting to the delivery path. Redis serves caching and fast-access data. React provides the frontend where campaigns are built and monitored.
What we delivered
A customer engagement platform with a hybrid backend, where campaign processing runs independently of the application serving the interface.
WhatsApp Business messaging and marketing automation is the delivered channel, with campaign creation, execution and tracking in one workflow.
Campaign management
Building, configuring and launching messaging campaigns from a React interface.
WhatsApp Business messaging
Business messaging and marketing automation as the delivered channel.
Campaign job processing
Golang workers expanding and processing campaign delivery independently of the application backend.
Event-driven messaging infrastructure
Kafka carrying asynchronous messaging between platform components.
How the platform is put together.
Hybrid backend architecture
The interface and the core application handle request-driven work. Campaign delivery runs separately on infrastructure built for concurrency, with asynchronous messaging between them, so a large campaign never slows the screen being used to watch it.
- Interface
Campaign Interface
React
Where campaigns are built, launched and monitored
- Application
Core Application
Laravel
Accounts, templates, configuration and reporting
Campaign Processing
Golang
Concurrent campaign job and delivery processing
- Infrastructure
Kafka
Asynchronous messaging between platform components
Redis
Caching and fast-access data
A conceptual view of how workloads are separated, not a deployment topology.
Using several backend technologies in one platform is a decision that has to earn itself. Here each one is doing work the others would do worse.
React: the interface
Where campaigns are built, launched and monitored. An interactive surface over a system doing sustained work underneath.
Laravel: core application
Accounts, templates, campaign configuration and reporting. The request-driven product surface, where framework maturity translates into shipping speed.
Golang: campaign processing
Expanding a campaign into individual deliveries and working through them concurrently. Isolated from the application, so volume does not slow the interface.
Kafka: messaging infrastructure
Asynchronous messaging between components. What allows campaign processing and the application to be genuinely decoupled rather than nominally separate.
Redis: fast-access data
Caching and fast-access paths supporting both the application and campaign processing.
Campaign creation
Building and configuring messaging campaigns from the platform interface.
WhatsApp Business messaging
Business messaging and marketing automation on WhatsApp.
High-volume job processing
Campaign delivery handled by dedicated Golang workers built for concurrent workloads.
Asynchronous architecture
Kafka decoupling campaign processing from the application backend.
Campaign tracking
Delivery outcomes flowing back into reporting for the campaigns that produced them.
Workload-matched architecture
Each backend technology handling the workload profile it suits, rather than one runtime handling all of them.
- Campaign processing isolated from the application serving the interface
- An asynchronous architecture that decouples delivery from reporting
- Each backend technology matched to the workload it actually handles
- Campaign creation, execution and tracking in one workflow
- A platform structured so additional channels extend it rather than reshape it
The capabilities behind this work.
Automating high-volume workflows?
When one user action expands into thousands of operations, architecture stops being an implementation detail. Let's build the infrastructure for it.