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
- 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.
- 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.
Archives
- November 2021
- July 2020
- June 2020
- March 2020
- February 2020
- January 2020
- November 2018
- February 2018
- January 2018
- December 2017
- January 2017
- August 2016
- June 2016
- April 2016
- March 2016
- February 2016
- July 2015
- June 2015
- March 2015
- February 2015
- November 2014
- June 2014
- April 2014
- February 2014
- December 2013
- November 2013
- September 2013
- May 2013
- June 2012
- April 2012
- September 2011
- August 2011
- March 2011
- January 2011
- November 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- November 2009
- October 2009
- July 2009
- June 2009
- May 2009
- March 2009
- January 2009
- October 2008
- September 2008
- April 2008