Featured Project: Betwext Broadcast
Betwext Broadcast is an SMS marketing application created by the partners at Vuurr, and used as both an internal tool for our clients and an independent, outside sales product. Broadcast functions similar to many email marketing suites in that it sends targeted SMS campaigns like an email marketer would send email blasts. The primary application contains several key features that require a fairly robust backend infrastructure.
Phone Number Provisioning
Each account receives its own long code phone number that must be provisioned from the SMS provider for sending messages. It is then enabled in the new user’s account.
Third Party Integrations
Besides integration with the external SMS gateway, integration with Eventbrite and Constant Contact were crucial to allow event organizers the ability to send messages to attendees before, during, and after events.
Sending Large Campaigns
When an account wanted to use a short code, Broadcast needed the ability to handle hundreds of thousands of outgoing SMS requests in a matter of seconds. The Redis backbone behind outbound SMS I/O was an important key to this.
Subscriber List Management
Since a subscriber can belong to several lists within an account, it was important to build in validation that not only ensured subscribers will only receive a campaign message once, but also allows for appropriate tracking of metrics across multiple lists within a campaign.
The Architecture
Frontend Application
Betwext Broadcast is divided into three separate applications. The first is the frontend application that users interact with. It operates on its own cloud instances as a standalone application with no storage resources on those servers. The application is built on top of Codeigniter, a PHP framework, and has an API layer in the middle that allows external interaction with the application on a per account basis.
Inbound Messages
The next part of the stack is the incoming message layer. Again operating on its own instances, this acts as the receiving application from the message provider when a message delivers. Essentially it’s a traffic router: By first checking the database for which account owns the phone number a user sent a message to, and then secondly grabbing stored metadata on the user, the system can lastly parse out the first word in the response and route it to the proper place. For example, if a user texts “STOP” or “HELP,” they receive the proper assistance from the system, otherwise they receive an account level response. Additional routing handles storage and management of text chains going forward.
Outbound Messages
The outgoing message layer is the last part of the stack. When a user sends a campaign, or when a scheduled campaign is set to deliver, the primary application makes an API request to the outbound I/O layer. That application (on a separate server cluster) then ingests all of the numbers receiving a message from the database and creates a new list in Redis. From there, the code selects chunks from Redis 1,000 keys at a time. Because of a limit from the SMS provider of 40 concurrent requests, the stack then breaks off 40 numbers from that 1,000 and concurrently makes requests to the 3rd party API. Responses from those requests are stored in Redis for use later and counting successful outgoing messages. After a message has been successfully delivered to the carrier, an update is posted back to this application, and the resulting record is updated in Redis, marking the message as “Sent” or another status.