Fact Sheet

MessageGears Modern Cross-Channel ESP Architecture

We often find ourselves explaining this as briefly as we can at conferences and during customer and partner and analyst meetings. The below is meant to be a high-level summary only, written by a fairly non-technical person. Not every feature and function of the MessageGears platform is described below — only the high-level.

MessageGears Cloud

MessageGears offers a 100% multi-tenant SaaS render and sending service cloud that is accessible via APIs. MessageGears Cloud provides all the functionality of a transactional messaging provider like SendGrid, Sparkpost, or Mailgun. However, unlike with transactional messaging providers, the MessageGears Cloud is highly optimized for both transactional and bulk (i.e. marketing) job processing. In order to send messages faster and reduce unnecessary bandwidth, we allow customers to send jobs of virtually unlimited size by invoking a single API call that passes in the content to be rendered, as well as a link to the audience data (which can be staged in Amazon S3 or any URL accessible location). Therefore, extremely large jobs can be sent to our SaaS render and sending cloud for processing in a matter of seconds. All the heavy lifting of processing large bulk jobs is then performed in MessageGears Cloud, including message rendering, delivery, tracking, and analytics.

MessageGears Campaign Management

Our Campaign Management software is called “Accelerator” and is a single-tenant, multi-user web application. It is generally installed in our customer’s private cloud or other hosting environment under their control. MessageGears Accelerator accesses pre-existing internal audience and other content sources safely and securely, with no need to map and then replicate some subset of this data back and forth to a third-party “marketing cloud” database (no ETL). MessageGears Accelerator provides the browser-based user interface used by marketers to create audiences, cross-channel content and conditional logic, to create and manage complex cross-channel orchestrations, to schedule jobs, and to view analytics. It provides all of the marketer functionality expected of a modern cross-channel ESP (often now called a customer engagement platform). When a job (campaign) is launched by Accelerator, a database query is run to extract the audience data (only the data that is needed to personalize the message for the audience is extracted). Accelerator then places the audience data securely in an Amazon S3 bucket and calls an API to the MessageGears Cloud to process the job. It then continually polls the MessageGears Cloud to report on the progress of the job.

These two components (MessageGears Cloud + MessageGears Campaign Management) are purpose built and highly optimized to work together in an extremely efficient manner for the Super Senders of the world. Together, these components combine the flexibility and security of installed software with the power and efficiency of SaaS.

We are very different from all of the legacy marketing clouds, as well as the newer upstart marketing clouds, in that we have no architectural limit on the scalability we can provide to an individual customer, or even to an individual job. Databases/data syncing and MTAs (email servers) are the main choke points for most of our competitors. Since we don’t host our customers’ audience data, we’ve eliminated one of the most common bottlenecks to scalability. Our Campaign Manager software accesses all available audience data directly from our customers’ private and increasingly modern (Snowflake, Redshift, BigQuery, Azure) data sources — no mapping or syncing required. Benefits of this approach are massive agility for the marketer, data security (no PII leaves your private environment), and cost (you don’t have to pay — again — to store your data in someone else’s marketing cloud when you already have this data in your private internal enterprise customer data platform).

MTAs are the other most common bottleneck for other ESPs. We address this challenge by breaking our customers’ bulk jobs into small pieces we call “payloads” (no more than 1,000 recipients each). We place these payloads on queues that are accessible by any number of MTAs for rendering and delivery. These MTAs are all constantly polling these 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. Scalability in other areas of our platform is managed through more traditional techniques using load balancers and auto-scaling server instances. Our analytics data is stored in an AWS Redshift database and is not a part of the time-sensitive job processing workflow. We leverage multiple AWS availability zones and regions for additional resilience.

Our platform is designed for concurrent, time-sensitive communications for the largest enterprise senders. We assign dedicated IPs for each of our clients. Marketing and Transactional campaigns are also separated to send on different IPs, ensuring reputation is separate and your time-sensitive triggered messages are delivered on time. Clients are provisioned a number of IPs based on volume/cadence and types of mailings.

MessageGears Data Security

Only recipient address information (email address, phone number, mobile device ID, etc.) and personalization attributes (first name, zip code, points balance, etc.) are submitted to the MessageGears Cloud environment during API invocation for delivery of personalized messages. All data is cryptographically secured in-transit and at rest. During the course of message delivery, recipient channel identifiers (email address, phone number, mobile device ID, etc.) are asymmetrically hashed for event logging, reporting and event distribution back to the customer. Post delivery, all submitted recipient data as well as message content are redacted from requests and processing archives. All persisted and subsequent events connected to the request (deliveries, opens, clicks, etc.) are identified to the recipient by the asymmetric hash ID generated during processing.

For a visual of what is described above, see https://messagegears.com/products/architecture-scale/

For more detail or a deeper dive overview + demo, please don’t hesitate to reach out.