Inundated Servers

On the ninth day of Listmas, my data showed to me 9 inundated servers…

If you take the total of all of the other days of Listmas (with the exception of the SBLs and the authentication issues), you come up with a lot of extra mail being sent. In fact, the period between late October and just a couple of days before Christmas is the busiest period for mailing in any given year.

By and large, that’s good news. Billions of message go out to willing and happy recipients. They get news about good deals, marketers make a lot of money and everyone is happy. That is … until they’re not.

Generally speaking, mailbox providers know that they’re going to need some extra capacity in the holiday rush. But, they cannot plan for everything, and they shouldn’t have to plan on every single message arriving at the exact same moment. What you may not realize is that (thanks to human foibles) they do.

You see, people like to think in terms of round numbers. So, what do we do? We set up email jobs to go out at :00 and :30 in an hour. And everyone does it. Receiving mail servers only have so many open spots to handle the request to handoff an email. Those slots fill up and things back up. The result is a lot of messages receiving “Server busy, please try again later” error messages. There’s nothing that a sender can do but wait until new slots open up.

Picture it this way: You need to fill a swimming pool, but the only thing that you have is a set of 6 fire hoses. How do you do it? Ultimately, it comes down to “use all of the hoses, but understand that you’re still going to have to wait.”

So, receiving mail servers get slammed at the top and bottom of the hour, mail queues on the sending mail servers slowly drain over the next few minutes, and delivery is perceived to be slow. Now, as it turns out, this happened this year, too (as it always does), but some providers found their systems slammed by incoming requests that wouldn’t let up for multiple days.

So, who is at fault here? Well, it’s easy to say that the receivers should have more infrastructure. But, the truth is that their capacity works for the volumes that they see far more often than it doesn’t, and if the receivers planned for handling all incoming messages on the busiest hour of the busiest day of the year, they would have server capacity that would sit idle for an entire year just to be used on that one hour when the next year rolls around.

Now, that is a problem, especially when you consider that email is designed to handle these issues. Email is designed to have the email stored on one server until the next server says that it has accepted the message or given a rejection of the message that really means about the same as “and don’t try this message again.” If the message is delayed, the sending server will just wait a few minutes and try again — over and over again until the message is received or times out (generally after 72 hours).

It’s not really the sender either. They are just doing their job. But, they have some control over the problem as well. Rather than sending their messages at either 8:00 or 8:30, they could offset that by a small amount in order to take advantage of anticipated decreased loads. So, send the message 8:08 or 8:36 rather than the top and bottom of the hour.

8 annual mailings
“That’s our business model!”
“We’ve gotta make our numbers,”
5 SBLs,
4 authentication failures,
sending 3 times daily,
2 purchased lists,
and that’s why they’re having slow delivery.

Bibliography

1. Retail Email (2013, January 1), Alert: Retail email volume grows 19% during 2012. Retrieved December 18, 2017 from https://blogs.oracle.com/marketingcloud/alert-retail-email-volume-grows-19-during-2012.
2. Retail Email (2012, December 24), Alert: Retail email volume hits all-time weekly high during week before Christmas. Retrieved December 18, 2017 from https://blogs.oracle.com/marketingcloud/alert-retail-email-volume-hits-all-time-weekly-high-during-week-before-christmas.