How MessageGears Scales Delivery to Customer Demand

MessageGears is the world’s first hybrid Customer Engagement Platform, and has been sending large volumes of messages for demanding marketers since 2011. Our ability to scale and meet the demands of Super Senders across the world stems from three key pieces of functionality, inherent in our system architecture:

1. Direct connection to on-premises data, with no prescribed schema or data format
2. Efficient bulk message processing, optimizing data payloads for delivery
3. Ability to scale message render and delivery units (MTAs), ensuring expedient message delivery and SLA throughput

This document will walk through each step in the message delivery process, and explain how MessageGears scaling capabilities are best in class.

Direct Connection to Data

The most common bottlenecks for other ESPs are MTA capacity and rigid, multi-tenant data structures. The MessageGears system architecture breaks through these bottlenecks by offering a schema-less customer data integration and an elastic personalization and delivery service layer.

Connecting directly to client data sources enables marketers to personalize content based upon their internal structure. MessageGears processing a schema-less structure allows for large, heavy sends to be broken into smaller batches of data and elastically distributed across our infrastructure.

Our Accelerator application initiates the message sending process by selecting data used in the templating process from the user’s data source, and placing it into a cloud-based file of variable size according to the size of the recipient list. Although these files typically contain template-level data (email address, name, etc.), these “batches” of data are cryptographically secured via Amazon KMS encryption, and are readable only by the MessageGears cloud processing environment.

Once all of the necessary recipient data has been extracted and processed into a consumable format, an API call to MessageGears’ cloud environment begins the next step of the delivery process.

Bulk Message Processing

It’s worth noting that transactional messages skip bulk message processing, and are sent directly to message render and delivery. For sends to multiple recipients, upon completion of recipient upload, marketing campaign requests data flow leads into MessageGears cloud environment, where large data files are broken into more consumable “payloads” of data.

Operating on a single large list of unbounded size is inefficient, and would inhibit the scale and speed at which messages can be processed. This is a typical barrier for many common ESPs. However, MessageGears’ direct connection to data allows for much faster file processing in this regard. Because cloud processing is separated from the environment data store, MessageGears is able to disseminate recipient batches containing millions of recipients into smaller “payloads” of a more easily processable and digestible number of recipients.

Once the MessageGears cloud environment further breaks our customers’ bulk jobs into payloads, the payloads are able to be effectively and efficiently redistributed across multiple message queues that are accessible by any number of render and sending agents (MTAs) for personalization and delivery.

Message Render and Delivery

MessageGears’ ability to separate bulk job processing from critical render and delivery services leads to an elastic resource pool of rendering and send agents. These agents are responsible for:

• The evaluation of the freemarker render of all constituent parts of the message (template, recipient, context, etc.) and appropriate recording of render errors
• The delivery of each message on its intended channel, and recording of feedback from partner (PMTA, SMS, Push) on message delivery or failure

Our rendering agents are all constantly polling the previously mentioned payload queues for work. This technique provides virtually unlimited horizontal scaling, even at the individual job level. Our MTAs are thus designed to scale so bulk campaigns can be delivered at the same rate regardless of batch size. Because transactional messages are not processed in line with bulk messages, they are fed directly to our rendering agents to ensure processing times are always in line with SLAs.

Scalability in other areas of our platform is managed through more traditional techniques, using load balancers and auto-scaling server instances. Our analytics data leverage enterprise data streams to generate metrics on sends every minute and operate independently from all core processing.

Finally, the platform itself is distributed across multiple AWS availability zones for redundancy and configured with auto-scaling configurations to meet client demand.  External monitoring and internal telemetry make sure the system is always running efficiently and in a healthy manner. For more information on our focus of platform reliability and uptime, please read our blog entitled “What Makes Email More Reliable With MessageGears.”