What Does It Take to Send Billions of Emails?
When it comes to transactional and marketing email, there are email senders, there are high-volume email senders, and then there are really high-volume email senders. Most of us can grok the amount of email that a small or medium sender generates in a typical month, but the volumes at the higher end of the spectrum can be a little mind-boggling. Especially to someone who isn’t steeped in the business of email deliverability.
Setting aside the bad guys like spammers, there’s nothing inherently untoward about sending very high monthly volumes. Just think for a minute about large e-commerce retailers that generate several email notifications (order confirmation, shopping cart abandonment, shipping notification, etc.) for each transaction. Or a social network that sends emails in response to activity and engagement (friend requests, likes, retweets, etc.) on their platform.
It’s really a question of basic math. When you have a large number of users (5–20 million) who receive multiple messages per day, or a really large number of users (40–50 million) receiving one message per day, you’re in high-volume email territory. And that’s just to get past the velvet rope; the highest volume senders like Facebook or Twitter send 1–10 billion emails per day. (I tend to hear Carl Sagan’s voice in my head: “billions and billions of emails…”) The numbers add up really, really quickly.
To be sure, it’s an exclusive stratosphere of senders who reach the very highest monthly volumes, but the tools and practices they’ve developed to do it are applicable to all senders who rely upon email to drive their business. It’s a multi-dimensional challenge: complexity and scalability of message generation, throughput of sending, and deliverability on the receiving end. And it’s a challenge my colleagues and I spend a lot of time helping senders solve. Here are some of the best practices we’ve learned that could help you, too.
First, Pick the Right Platform
As I suggested above, a company’s particular characteristics and business needs have a big impact on what its email looks like. But, in my experience, senders tend to fall into four basic groups:
- Low volume/complexity who want a cloud solution
- High volume/complexity who want a cloud solution
- Low volume/complexity who want an on-premesis solution
- High volume/complexity who want an on-premesis solution
For purposes of this framework, “low volume” means sending less than 10 million messages per month, while “low complexity” means business logic like filtering, routing, or content manipulation aren’t performed in the messaging layer. “High volume” and “high complexity” suggest the opposite. (Clever nomenclature, right?)
Here, I’m going to step back and make a small product plug: One of the real advantages of our SparkPost cloud offerings is that our cloud is highly elastic and will scale to meet nearly any load. The efficiency of that model for most senders is really hard to overstate. Just as importantly, SparkPost’s operations team—not your own staff—deals with the details of managing messaging performance, scalability, and deliverability, letting you focus on business differentiation and strategic value.
Now, having said that, we know that not every business is ready to use the cloud today. Some may elect for a hybrid cloud/on-premises architecture. Awesome. And others will want to keep email infrastructure completely in house. We get it. Different businesses have different needs. That’s why SparkPost (and our parent company, Message Systems) offers a solution for each of these four categories of sender.
If you use PowerMTA, be sure to check the wealth of PowerMTA resources at Port25 to optimize your installation. And, of course, SparkPost customers get the benefit of these best practices and many more courtesy of our cloud infrastructure and crackerjack ops and deliverability teams. But for the rest of today’s post, I’m going to give some love to folks that are using Momentum.
Making the Most of Momentum
I’m just going to say it: Momentum users really get what high-volume email is all about. (And, by the way, the Momentum platform is a core underpinning in the SparkPost cloud.) Over the years, our services team and our expert customers collectively have developed a lot of expertise about what it takes to optimize this ultra-high performing email platform. Here’s what we’ve learned works in the real world.
- Parallelize Processes
- Remove Bottlenecks
- Optimize Queues
- Be Scientific
I’ll touch on each of these areas below.
The Momentum platform was designed as a parallel solution, and there are several areas that benefit from being parallelized when working with Momentum:
- Inject messages using multiple parallel processes. The scheduler-based architecture leveraged in Momentum provides maximum performance when handling incoming traffic from multiple sources. Injecting across multiple connections will provide maximum performance.
- Send across multiple IP addresses. Not only will many ISPs have a limit on how much traffic they will accept from a given IP address, but separating traffic streams in to separate IP pools can also help with deliverability.
- Scale horizontally. Our recommended installations start at three nodes per role to ensure redundancy and availability, and each role can be scaled independently as needs increase from either a sending or reporting perspective.
With the right platform, and sufficiently parallel injectors and sending IPs, the next key to sufficient performance is to remove common bottlenecks that can affect platform performance. The most common areas are hardware and network bottlenecks, and will be covered in the next sections.
With the 3.6 release of Momentum, a new performance benchmark was achieved through the introduction of the new SuperCharger architecture. With SuperCharger, the scheduler-based architecture that enables Momentum’s performance was parallelized to allow for multiple schedulers to operate in a single Momentum instance. The new SuperCharger technology allows for significantly improved vertical scalability, with a properly provisioned supercharger-enabled Momentum instance able to send several times the volume of a non-supercharger instance.
With the introduction of SuperCharger, Momentum instances can leverage multi-core server architectures, moving the hardware bottleneck to disk IO. Physical disks in a RAID-10 configuration can provide performance in the range of 2-4 million messages per hour, while SSDs can double that, and PCIe-based SSD systems such as FusionIO can help reach performance in excess of 10 million messages per hour.
In addition, Momentum’s caching system improves performance and can leverage a large amount of RAM; typically we recommend 4GB of RAM per core. (Here’s a full list of hardware minimum specifications.)
Performance can be increased through additional cores (with accompanying memory) and higher performance IO systems. Investments in larger systems can be balanced against scaling horizontally with more servers, leveraging the clustered capabilities of Momentum.
With the increased performance available through the SuperCharger architecture, it becomes increasingly important to ensure that the supporting network is capable of handling the bandwidth generated by a Momentum instance, let alone a cluster of nodes.
The following recommendations are made regarding network bottlenecks:
- Isolate network connections for injection, delivery, and administrative traffic. By separating inbound and outbound traffic you effectively double the available bandwidth to the server.
- Move to 10GigE Ethernet. A fully provisioned server with PCIe SSD technology can push enough traffic to saturate Gigabit Ethernet.
- Use bonded NICs to increase availability and to increase available bandwidth. For many senders bonded Gigabit NICs with separated injection and delivery pathways can provide sufficient bandwidth without a move to 10GigE.
As mentioned earlier, spreading traffic across multiple IP addresses has multiple benefits:
- Each IP address will be assigned to its own Binding, meaning that messages will be isolated to their own queues, helping to prevent queue collisions.
- Multiple IPs allows you to send sufficient traffic to ISPs that have restrictions on incoming traffic on a per-IP basis.
- Separating message streams to their own IPs and bindings enables Adaptive Delivery to be more effective at automated traffic shaping by giving it more granularity.
While the number of IPs you will need varies based on sending reputation, at a minimum make sure that you separate out traffic into bulk and transactional. A general guideline is to use one IP address per 100,000 messages per hour you will be sending.
When configuring multiple IP addresses for the same mail stream, take advantage of the Binding Group capability of Momentum to allow for common configuration and easy round-robin IP assignment by assigning to the group.
As you work with the recommendations in this article, focus on making one adjustment at a time and measuring the results before making further changes. For example, when adjusting the number of injectors, try adding five connections at a time and measuring throughput in order to identify the ideal number.
Similarly, with some of the tunables, start by reviewing data to identify current throughput, then calculate an appropriate setting before testing.
Common Performance Pitfalls
In addition to the overall best practices I described above, I’d like to make special note of a few issues for senders looking to highly tune their infrastructure to improve performance.
There are three key memory settings that are often overlooked and left at their defaults:
- Max_Resident_Active_Queue : Controls how many messages are cached in memory on a per-queue basis. Set to either -1 or a larger number like 10,000 if you have sufficient memory.
- Max_Resident_Messages : Controls how many messages are cached in memory on a server-wide basis. Set to 90-95% of RAM divided by Growbuf_Size (default 16k). I.e. 96GB / 16k = 6,000,000
- Growbuf_Size : Configured the size of memory chunks used to cache messages. Ideally we want the average message loaded in a single chunk. Set to larger than your average message size (but not to your max message size).
One key advantage of using Momentum is the ability to implement policy scripts to achieve complex message and server manipulations using automation. In older versions of Momentum, policy was implemented using a scripting language called Sieve++, an extension of the Sieve filter language used in several messaging tools.
With Momentum 3, we introduced a new option for policy scripting in the Lua scripting language. Lua provides a more robust and extensible scripting language that is better optimized, and which supports the multithreaded SuperCharger architecture. All users looking to leverage SuperCharger and generally increase performance should migrate their policy scripts to Lua.
In recent releases of Momentum we have introduced support for OpenDKIM as a module. The advantage of OpenDKIM signing is that is has multi-threaded support, enabling higher performance when used with SuperCharger. Moving to OpenDKIM is quite straightforward and requires minimal configuration changes.
Headers in Custom Logs
One advantage of Momentum is the ability to use the custom logger module to create log files that contain only the data you need, in the format you prefer. One logging macro available to senders is %h , which will capture a named header and place its content into the log line.
The %h macro comes at a cost: It parses the whole message on each event to find the header and record its contents. A better-performing alternative is to use a Lua script to read the header and place its value into a context variable, then use the %vctx_mess macro to load the context variable into the log.
I can’t tell you how cool it is to see how Momentum and SparkPost are being used out in the real world by high-volume/complexity email senders. I’m thrilled to be able to share these recommendations to help optimize a Momentum installation for maximum performance.
By the way, want to learn more about getting the most from your email infrastructure? The SparkPost Support Center and Momentum customer support site have a wealth of operational advice. And, if your interest is particularly focused on making sure email gets to the inbox, check out two great ebooks that explain some of the nuts and bolts of email deliverability: Email Best Practices 101 and How to Send Zillions of Emails a Day.
Businesses have more options than ever for choosing email sending infrastructure: from on-premises servers to full-service, hands-off marketing solutions—and everything in between.
What’s the best approach for managing high-volume email today? It’s tempting to say there’s one, easy answer for every scenario. While we at SparkPost are undeniably believers in the cloud, we also know that many companies have made significant investments in on-premises software over the years. Moreover, a particular company may have other business factors that preclude wholesale move away from their existing infrastructure.
The truth is, we think SparkPost provides an ideal middle ground between in-house infrastructure and full-service marketing providers. We deliver both the scalability and operational expertise of a dedicated cloud provider with the API-driven control and extensibility of specialized software products like Momentum and PowerMTA. In fact, it’s this combination of qualities that makes SparkPost an ideal candidate for deploying a hybrid approach to email infrastructure: one that combines the best of the cloud with the existing footprint of on-premises investments.
Here are five scenarios where this hybrid approach makes a lot of sense.
1. Creating options for diverse mail streams. A big benefit of a hybrid email infrastructure is flexibility. Some types of mail are easily segregated to the cloud, while others might be tightly coupled to other in-house systems. For example, marketing messages to well-defined customer segments might be easily migrated to cloud-based sending, while transactional mail, like password resets or shipping confirmations might be generated by in-house systems that offer limited external integration options. A hybrid approach allows you to pick and choose the best solution for each mail stream your company might have—and gives you some runway room to extricate transactional message generation from legacy systems over time. (By the way, segregating different types of mail streams into dedicated address spaces also is a best practice that leads to better deliverability.)
2. Offloading deliverability headaches to the experts. Managing the inbox performance of email programs is no easy task. There are countless factors that shape inbox performance, and these rules are constantly changing as ISPs fight against spammers and other bad actors. SparkPost’s deliverability team is the industry’s best—and their expertise gets results, whether a message is generated completely in our system or relayed from an on-premises server configured to work with our cloud. That deliverability improvement is a quick win for anyone deploying a hybrid cloud approach. Outsourcing your sending also means offloading the headaches of maintaining and managing your own IP reputation, along with the costs associated with monitoring it. Better inbox performance, lower costs, fewer headaches? Win, win, win!
3. Scaling sending capacity for seasonal or other peak demand. In many businesses, message volume can be very unpredictable and bursty. In others, there may be a seasonal peak demand much higher than other periods of sending. For example, a major product launch could spike email volume for a limited period. Or, a retailer might send 100x its usual volume during the Black Friday holiday shopping weekend. Scaling on-premises infrastructure to handle these peak loads is a waste of capital investment that would normally sit idle, but a hybrid architecture allows you to use the elasticity of the cloud to absorb these peak demands, whenever they might occur, while optimizing capital spend.
4. Mitigating risk while maximizing control and compliance. In many regards, a cloud infrastructure provides an inherent advantage for risk mitigation through the redundancy and disaster recovery benefits intrinsic to large-scale virtualization. A hybrid sending architecture builds on this by adding the possibility of switching sending from one environment to the other, should one fail for any reason. At the same time, while SparkPost adheres to stringent security best practices and offers a variety of mechanisms for ensuring the security and authenticity of data transmitted to the cloud, we know some customer systems require particular regulatory controls, need to live off the grid on a private network, or may require zero latency or other quality-of-service factors harder to control over a public network. In these cases, connecting an on-premises email infrastructure to the sensitive systems, while relaying message delivery though the cloud allows for optimum risk management and control.
5. Getting your feet wet and enabling incremental change. The final reason to consider a hybrid of on-premises and cloud email infrastructure is deceptively simple. Because SparkPost is built to scale from small message streams to the very highest volumes of traffic, it provides an ideal route for getting real-world experience with the performance of cloud-based email delivery, one message stream at a time. This incremental approach is a hidden benefit of the SparkPost service. A step-by-step migration to the cloud is the antithesis of wrenching “rip-and-replace” changes, and it provides a path for the gradual, well-managed sunsetting of on-premises infrastructure.
These are just five of the reasons for considering a hybrid cloud/on-premises email infrastructure, but they all share one trait: flexibility. Whether it’s adding cloud sending capacity, controlling capital costs, or boosting deliverability, a hybrid cloud enables as many deployment options as there are email programs.
That flexibility is one of the traits that makes SparkPost so compelling: our industry-leading deliverability, performance, and real-time reporting don’t come at an all-or-nothing price, and they don’t require the risks of rip-and-replace deployments. (And, by the way, configuring PowerMTA to relay to SparkPost is really easy.)
Update: Want to learn more? We are hosting an upcoming webinar about the benefits and approaches to deploying SparkPost in combination with your existing on-premises infrastructure. Join us on December 9 at 10 AM Pacific Time for “Hybrid Email 101: How to Add Cloud Services to Your On-Premises Infrastructure.” Register today!
The industry’s leading email platform with even easier deployment options and better customer engagement
We are excited to announce the availability of Momentum 4.2, the latest release of our flagship messaging platform. Here are a few of the new features available in Momentum 4.2:
API Enhancements for Better Customer Engagement
- The APIs have been extended to allow scheduling of mailings and easier management of recipient lists.
- The SMTP API interface allows the sender to control engagement tracking, include metadata and tags, and assign a message to a campaign report. The user can now also create, CC, BCC and archive copies of a single message while receiving tracking of each copy in the set.
Industry’s Leading Deliverability Tool Just Got Even Better
- Adaptive Delivery data is now presented in the Momentum reporting user interface (UI), allowing deliverability managers to quickly and easily drill into deliverability issues for quicker problem resolution – improving deliverability and brand reputation.
Automation of Deployment and Configuration Management
- Distribution of Momentum software now uses the Linux yum utility to manage packages. Momentum deployment configuration can also be managed with off-the-shelf management tools such Ansible and Puppet.
We have also enhanced inbound security for our receiver/carrier customers, with new anti-spam/anti-virus plugins and full IPv6 functionality.
Finally, all the features of Momentum 3.6 are now also available with this latest release, providing an easier path for customers to migrate to Momentum 4.2.
We are confident that these new capabilities will further enhance our customers email programs to drive even better customer engagement. For more information on the new release, please visit our website or contact us.
I woke up feeling extra chipper today. Why am I so excited? Well today is the day that Message Systems officially launches our first cloud email service. And today is the day that all businesses that rely on email as their critical engagement channel with customers can finally get access to the very same email infrastructure that our customers, the most prestigious and demanding large volume email senders in the world (who collectively send 20% of the world’s email), use on a daily basis. Today marks the democratization, so to speak, of high quality email infrastructure software and the beginning of the end for what we call the SAD (poor service, weak analytics and low deliverability) state of affairs in the mass cloud email infrastructure market.
How did the cloud email services market become SAD you may ask. The answer is simple. Lack of competition has led to low investment in a truly outstanding cloud email infrastructure service for companies of all sizes. Over the last 5 years, Message Systems has been busy investing in and building the best email software in the world, winning evaluations and converting large-scale senders (who can choose whatever software they please) onto our Momentum platform. Among this select group of senders Momentum is known to be the best on-premises email software available, and Message Systems people are trusted as the foremost email experts as well. Even companies I have spoken with who don’t use Message Systems often admit that if they could have afforded it at the time, they would have chosen Momentum too.
My point is that Message Systems Momentum as an on-premise solution has really only been accessible to the large-scale senders, multiple of which send in excess of a billion messages a day, and to companies who have the staff, expertise and resources to afford the deluxe solution. Our investments have flowed to serve the email needs of high end ESPs (Epsilon, Yesmail who run multi-tenant operations on Momentum), marketing automation suppliers (Eloqua, Marketo), publishers (PBP, Agora), banks (JPM, AMEX, BofA) and large cloud companies (Groupon, LinkedIn, Facebook, Salesforce.com, Twitter). Our software, because it was largely only available as an on-premises solution, was not very accessible to many smaller or medium-size senders. (Message Systems does have quite a few smaller customers too, but these companies usually see email as a core differentiating capability, and they have the in-house expertise and staff to run the systems.) So the players in the existing cloud email services market weren’t really competing on quality of service, it was more competing on price. The underlying problem, however, is that these other cloud email services are built on less capable software that never withstood the competition to be the best and win at the high end of the market.
So for Message Systems today, our entry into the cloud email infrastructure market opens up a large number of new customer prospects and a big market. And for end mailers, our entry into the cloud email market marks the beginning of new choices and competition in a market, which frankly hasn’t had much serious competition. From talking with customers, our research has shown those using today’s crop of cloud email services feel a general lack of Service from their provider, an inability to understand and effectively adjust their email program through Analytics and just plain low Deliverability, which one email industry expert told us was actually less than 70% for one of the major cloud services across their customers.
This is about to change. Message Systems customers routinely get delivery rates in the high 90s because of the power of our Adaptive E-mail Network and software automation that allows senders to automatically comply with constantly changing ISP rules. We will be managing deliverability for our SparkPost customers as a part of the service. Our SparkPost service also contains real-time and accessible detailed data on email delivery made available via beautifully designed analytics working with an integrated data warehouse unlike anything you have seen from the other services… You will be able to drill down into the details of your email sending immediately, understand ISP issues with our bounce classification system and protect your brand. And last, you’ll get all of this from a company that serves and is trusted by the most demanding emailers in the world.
If you are a serious email sender, you owe it to your self to check out SparkPost. Now you too can have the same powerful email platform used by the best of the best in email on a pay-per-use basis at a price that is probably right around what you pay today for a lot less service, analytics and deliverability.
It’s no secret that Momentum delivers over 20% of global legitimate email traffic. With the availability of open source and low-cost commodity message transfer agents out there, that’s no small feat. Time and time again, the world’s biggest senders such as social networks, email service providers and cloud-based companies choose Momentum over commodity MTAs. We’re talking companies like Facebook, Twitter, PayPal and Yesmail, among many other industry leaders. Why, you ask? That’s because these companies understand the importance of being able to count on a platform that has high deliverability, scalability, performance, professional support and no hidden cost. With a commodity MTA, you can expect a bumpy ride that is seconds from disaster. With Momentum, you’re getting the best the industry has to offer, and a smooth sailing ride to ensure your mail gets to its destination.
Find out more about how Momentum outperforms commodity MTAs with the Momentum vs Commodity MTAs white paper.
At its inception in the early 2000s, the Momentum digital messaging solution was envisioned and took shape as a superior alternative to the open source message transfer agent (MTA) server products – Postfix, Exim, Sendmail – that were, at the time, the primary options for large-scale email sending and receiving operations. Once Momentum hit the market, it quickly became known among engineers and technicians in the Internet infrastructure and email industries as the fastest, most scalable messaging platform available. Installed in the data center, a single-box (one hardware server) Momentum implementation could handle the same sending volumes and provide superior speed of delivery compared with a 10- to 15-server implementation running commodity MTA software.
But Momentum wasn’t just a better, faster race car. It represented a completely novel approach to how email could be managed, sent and received online. Momentum’s developers rethought all aspects of MTA architecture and the mail management process to come up with a complete platform that streamlines sending/receiving at every touch point to increase efficiency, performance and speed, while also increasing choice and flexibility around integration with applications and data sources.
Among Momentum’s many innovations were a more intelligent approach to message queue management, smarter bounce handling and feedback loop processing, an integrated policy engine with a development environment that includes hundreds of APIs, and an automated deliverability optimization capability that draws on all of these features to help senders achieve and maintain the best possible inbox delivery rates.
These attributes set Momentum apart from the competition when it first debuted, and still do today. In fact, through continual refinement by the Message Systems engineering and product development teams, Momentum now provides greater performance than ever. To provide an overview of the features and capabilities that make Momentum the leader in the marketplace, solutions consultant Rob Marchi and I put together a white paper that details the solution’s queue management architecture, Adaptive Delivery® capabilities and other features. Have a look here.
The Message Systems Training Division is proud to announce a new training offering to customers: Quarterly 3-Day Momentum Training Courses.
Once a quarter, the Message Systems training staff will conduct a 3-day Momentum training course at one of our offices throughout the world.
The first of these offerings is scheduled for Columbia on April 1-3, 2014.
The topics covered will include the following:
- Deliverability Best Practices
- Adaptive Delivery® Basic Overview
- Momentum for Sending Overview
- Getting Started: Installation, Starting Services and Basic Configuration
- Momentum: Sending Messages
- Hands-on Message Systems Adaptive Delivery
- Momentum Configuration Management
- DKIM, FBL’s, and Seedlists
- Logging with Momentum
- Momentum Bounce Handling
- Failover: Clustering
- Momentum Policy
- Web Based User Interface
- Lua Introduction, Fundamental API’s, and Policy Scripting
Attendees include professionals from different organizations and industries, each with their own unique sending issues. Gain insight into the challenges and solutions faced by other businesses or network and learn from industry peers. If you’d like to register for the training course, please email firstname.lastname@example.org.
Can’t wait for training to start? Here’s something to keep your occupied in the meantime. Check out our white paper on adding Momentum to your business, Overcoming the Challenges of High Volume Sending.
Testing your Lua scripts can sometimes be a bit tedious. It usually involves injecting a message in order to trigger the callout that will execute the code and output a message to the log. You must then open the log in order to check the log entry.
There is a better way. The Momentum console is extensible so you can add a command used solely for testing code. This does away with the need for injecting a message and looking for log entries in paniclog.ec.
local function test_code(cc)
— put code you wish to test here
local doc = xml.parsexml([[<doc></doc>]]);
local node = doc:root();
local child = node:addchild(“item”);
child:contents(“I am a child node.”);
— use print for console output
- This code uses the XML library so it must be included.
- Choose whatever name you wish for your function. The parameter passed to a control function is control construct userdata — we needn’t be concerned with it here but if you do want to pass an argument to the console command access it in the following way: cc.argv. The code that you want to test goes inside this function.
- This print statement will output node as text, verifying that the XML object has been created. You do not need to send a test email or check for log entries in paniclog.ec.
- You must use the msys.registerControl function to register your console command. You can register any number of commands from the same script file so, if you wish, you can keep adding functions.
Test your code by issuing the command /opt/msys/ecelerity/bin/ec_console /tmp/2025 test_code. Invoking the console in this way-in batch mode-executes the command test_code and immediately exits the console. You should see output such as the following:
<item name=”Junior”>I am a child node.</item>
Errors will also be output to the screen. For example, if you attempt to pass nil to the child:contents function you will see the following error message:
bad argument #1 to ‘contents’ (string expected, got nil)
The console provides a very convenient way of testing code but it has limitations. You have no access to userdata such as an ec_message so you cannot test message object methods. Additionally, some Lua functions can only be used during specific callouts and require that a message transit Momentum.
Running into the same old issues whenever you try to send high volumes of email? You need Momentum, the all-in-one platform for email, mobile, integration and analytics. Get the Overcoming the Challenges of High Volume Sending white paper today!
Since it’s Valentine’s Day this week, we thought we’d do a brief feature on the Message Systems’ customer that has done more to bring happy couples together than any other company in the world. Match.com was one of the first online dating sites on the Internet – debuting in 1995 – and has continued to dominate the space up to the present day. The company has grown steadily, and now maintains a presence in 24 countries and territories, hosting sites in 15 different languages. Match.com’s mission: to help singles find the kind of relationship they’re looking for, and to create romantic opportunities so singles are more likely to find someone special.
Match.com began working with Message Systems in 2008. The company had built its email operations on open-source Postfix mail servers, and after years of growth was beginning to experience delays and performance issues. The concern, not surprisingly, was that delays in email delivery could impact the experience for the site’s users. The search to upgrade its infrastructure led Match.com to Message Systems.
Match.com installed a trial version of the Momentum platform from Message Systems and quickly resolved the bottlenecks that it had been experiencing. After the trial period, Match.com cut over to a full multi-server Momentum implementation for all of its customer relationship content, which provided far superior performance and reliability. Momentum enabled Match.com to minimize downtime and dramatically cut time-to-delivery for customer communication, all while actually increasing delivery. This switch gave Match.com the ability to scale effectively as the business grew in the ensuing years with dramatically reduced hardware footprint, providing significant savings on energy and data center costs.
Going on six years together, the Match.com + Message Systems relationship is still going strong. Happy Valentine’s Day, Match.com!
With Valentine’s Day on the horizon, finding the secret to your customer’s inbox is imperative for your business and bottomline. Find out what successful senders are getting right with The Six Secrets of Successful Senders!