We were cruising along on Cyber Monday afternoon when I noticed that the FedEx Rate API was down, which is kind of important since we use it to pull shipping rates during checkout. No big deal I thought, it will default to the backup system, which was a rate table in our database. FedEx has scheduled downtime regularly and this backup has always worked well. Just to be certain though, I started investigating and realized that since this “downtime” wasn’t scheduled, we weren’t receiving a quick error message back. Instead it just hung on us, and in turn the checkout page just hung on our customers.
I myself couldn’t get the checkout page to load, and a quick scan of orders showed that the flow had significantly diminished. Oh shit, I thought to myself. This is a problem. I quickly programmed in functionality to default to the backup rates, bypassing the live API, and deployed it to the site. Problem solve in less than 20 minutes…sort of.
Immediately I noticed two things:
- The checkout page was faster, noticeably faster, like applying a coupon code was instant instead of hanging for 10 seconds.
- Our backup rates weren’t very accurate because, you know, they were backup rates only to be used temporarily
#1 led me to the conclusion that we needed to stop using the live API. Speed = conversions = $, especially on mobile. A lot happens on the checkout page, so I always (wrongly) assumed that the slow-ish speed was due to a combination of factors – the massive amount of queries and calculations along with the API call. It had been a while since we tested the backups, but we never noticed this obvious increase in speed during testing…I’m not sure how, but we didn’t. Anyway, not using the live API was an accidental huge win for us. Nothing like a 5-10x speed increase on the most important part of your site by doing nothing!
Except that #2 was now a big problem. The reason we used the live rates is because FedEx rate calculations are a beast. It’s not just a simple rate table like we had developed for our backups, there are all sorts of surcharges that can be applied in an almost endless variety of circumstances. Rather than develop for those, it always made sense to just pull the rates from the API live, as I think most sites and shopping cart software do.
Now that the stakes were raised, we all decided it had to be done. I spent the remainder of the week immersing myself in the minutia of FedEx rates. By the end of the week we had a shiny new rate system. It hits the API overnight to generate the base rate table, but if there’s an issue with the API call it just slows down how fast our rate table is updated, it doesn’t have any impact on customers checking out. It also is now able to:
- Quote rates based upon whether an address is residential or business (it’s financially beneficial to ship Ground to businesses and Home to residents despite the services being almost identical)
- Apply the appropriate residential surcharges for FedEx Ground & Home
- Detect if a zip code is considered “rural” and then apply the appropriate Delivery Area Surcharge
- Support multiple-box shipments
- Calculate appropriate rates & surcharges for SmartPost-only areas like P.O. Boxes and U.S. Territories
- Has support for 2015 dimensional (DIM) pricing
- Populate rates using test zip codes not subject to any of the above surcharges so that we’re always starting with a base rate for a zip code range and then adding on any surcharges after that
- Works with our Guaranteed 1 – 3 Day Shipping
I then spent quite a bit of time checking the rates for every single order that came through. After those all looked good, I set up regular automated alerts, reports, and spot-checks to continually ensure the system is still working.
Ah, good times.