USPS Server Meltdown

m2pc writes "The US Postal Service is experiencing major server issues for its shipping API web services. After spending about an hour debugging my own eCommerce software for a client, I found the problem was with the USPS shipping servers being unavailable. Further research showed that message boards for OS Commerce and other e-Commerce packages are filling with posts from angry users who are experiencing crashing Web store applications and frustrated customers. Developers are scrambling to find interim solutions, from hard-coding fixed price shipping, to 'rolling their own' shipping calculation APIs based on the USPS Fixed Rate Zone Tables, to disabling the USPS option altogether. One user reported yesterday that a call to USPS yielded the response 'we expect it to be down all day.' As of 9:20 AM PST the service is still unavailable."

Comments

That's what you get....

[morgan_greywolf]

And that's what you get for writing e-commerce packages that rely on 3rd party sites for basic functionality...

Don't say I didn't tell you so...

Re:That's what you get....

[qoncept]

While in principle I agree with that, what are they supposed to do? They are quoting you a price for a service they don't provide themselves.

Re:That's what you get....

[Anonymous Coward]

And that's what you get for writing e-commerce packages that rely on 3rd party sites for basic functionality...

Like a credit card processor? How many web stores have more than one?

Re:That's what you get....

[smallshot]

If it's important enough they should have a backup. I know it's not always within budget, but their website doesn't have to crash because the USPS service is unavailable, it could simply fall back to an acceptable solution, such as a fixed price, an estimation table, or an error message that says the USPS shipping estimator is down and shipping will be calculated at the time of shipment, or they can try again later. Yeah, they'll lose some business, but they can lose less business with a decent backup.

Re:That's what you get....

[KevMar]

try {

}
catch (exception ex){

}

Re:That's what you get....

[Anonymous Coward]

In actuality, they are providing a third party service and should anticipate issues like this. I my head all I can think is, how stupid are they? It's not like the postal rates change that often, certainly not day by day. Yesterday I was having problems with getting rates using Stamps.com software (overpriced crappy service in the first place), now I know why. I was able to manually make stamps instead simply by looking at a postal rates schedule on a trusty piece of paper. I wonder now why Stamps.com wouldn't be able to have access to this same piece of paper for the data they needed, but apparently they didn't think to put this data in their own database - instead they're relying on the postal service to do all the work for them, while they charge me $16/month to make stamps and shipping labels. I'm calling to cancel my account now - inept fools.

Re:That's what you get....

[JoelKatz]

"While in principle I agree with that, what are they supposed to do? They are quoting you a price for a service they don't provide themselves."

Fail gracefully. For example, state that they are unable to price that shipping option at that time. Offer you to accept the option without knowing the price, select another type of shipping, or get an email when they know.

Designing software to gracefully handle external failures is a vital real-world programming skill.

Re:That's what you get....

[EvilIdler]

Wouldn't it be easier to have a background task update the USPS prices, and just use the last working snapshot?

Crashing Web store applications?

[truthsearch]

Only a really terrible developer would hit a web services API and not code for it to fail. No one should expect a third party service to be up 100%. The apps should fail gracefully. Anyone finding their e-commerce software handling this situation poorly should find another package.

If a store offers only the USPS delivery method and the web service is down, the user could be directed to call the sales number to place their order. If the store offers other deliver methods the store front could instruct the user that USPS isn't currently available and they must choose another method.

Re:Crashing Web store applications?

[Rorschach1]

osC is insidious. You install it because it's open source and a zillion other sites are using it, so it can't be THAT bad, right? Then you have to install a few contributions to add the basic functions you need - and with each contribution, adding the next gets harder and harder.

But you get up and running. Then you discover all of the little annoying usability quirks - US state names don't use proper abbreviations, customers in Ireland can't place an order without a post code even if you set the minimum length to zero, the payment option selection looks like it has a default selected when it doesn't, users don't know that 'authorize.net' is actually the credit card payment option, and so on.

So you spend hours fixing those. Meanwhile, you've got the database populated with all of your products, and you're using it to track sales figures. Maybe you add some back-end order processing stuff for your own convenience.

Eventually this mass of haphazardly patched spaghetti code becomes an absolute nightmare to do ANYTHING with, but by this point you've spent so many hours working on it that it's easier to just keep slogging away at it than to just abandon the whole thing, install something new, and try to move your catalog and your sales records over to the new system.

And THAT is why there are so many osCommerce sites.

Re:Why SAS fill eventually fail

[zappepcs]

There is a better way. Code your own backup solution, revert to it when the SaS you are counting on fails. In this case, that would be a static shipping 'estimate' process that substitutes data when the USPS service fails. Writing code what depends on a third party is dangerous. If your business depends on that software you are fooling yourself if you think it won't fail. It will. This is where coding disaster recovery functions into your system is important.

Many of the posts here are about how stupid this situation is, but people are like that. There is a better solution: don't rely on SaS to hold your business together on a daily basis.

Re:Healthcare?

[djnewman]

Um... The post office is private, but protected. Even the best hardware and software fails on occasion. That was my point earlier - we need a better service model if we expect SAS to work. If the small Government crowd had their way the post office would still be the Pony Express. Let's see you get a letter acorss the country in a week for less than 50 cents. UPS and FedX can't - they get $5 for the smallest item. So much for off loading services to business!

Re:That's what you get... for not using FedEx

[quanticle]

To be fair, what sort of "backup" calculation would you have done here, short of reverse-engineering the USPS algorithm for calculating shipping rates?

I'm not usually a rabid free-market libertarian, but this here can be seen as a result of the fact that the USPS isn't really beholden to its customers. Can you imagine FedEx or UPS being afflicted by such an issue? And, if they were, would they blow off inquiries with a glib, "We expect the servers to be down for the rest of the day?" Of course not, because, for FedEx, UPS, DHL, et. al. such an outage directly affects the health of the organization. If people can't calculate shipping rates, they can't ship, and if they don't ship, the company doesn't make money. The close linkage between revenue and working services tends to put more impetus behind keeping things working and making sure that they get fixed quickly if they do happen to go down.

Re:Healthcare?

[Waffle Iron]

The government can't even manage to keep a simple web service online, and people still believe that it would be wise to let them control health care.

Get real. On several occasions, I've had to manually intervene to fix idiotic billing f*ckups between my PRIVATE insurer and a PRIVATE hospital, who had entered into mutual contracts to be in the same "network". For some reason, they couldn't get their own computers to talk to each other and I had to fix their bugs by going deciphering cryptic paper printouts myself and wasting hours calling customer service. This kind of stupid private healthcare IT problem happens routinely to millions of people every year. Therefore, using your reasoning I conclude that due to a clear history of incompetence, it is unwise to let private parties handle health care, and such practice should be banned.

Re:That's what you get... for not using FedEx

[TemporalBeing]

Because it's no longer reliable enough. The S&H charges change based on too many values for the few factors (carrier, size, weight, destination, type of delivery, timing of delivery, etc.), and things change. So it's not a necessarily easy calculation to perform.

Re:Why SAS fill eventually fail

[zappepcs]

In this case, you might want to only guarantee prices quoted from USPS and use your data as 'estimates' in the event that your own data is wrong and costs change at shipping time.

In yet other cases, the backup plan might simply be to use data from last week or yesterday if that is sufficient, but is data that is held in house on your servers.

Depending on the situation and requirements, any number of solutions are possible. By using a 'back up' solution that is not as good or perhaps as accurate, when the system fails to the back up, you have something that is workable if not 100% perfect or accurate.

You may indeed have a backup solution that is 100% accurate etc. and that is good. It's purpose is still a backup if that is how you configure the systems. You could also choose not to use the SaS and rely totally on your in house solution, but that is not what was being talked about here.

Re:What can Brown do for you?

[Anonymous Coward]

NYC is a whole different matter that most people in the US don't have to deal with.

Re:That's what you get... for not using FedEx

[je ne sais quoi]

then why is there a law the prohibiting Fedex/UPS from charging below a certain amount?)

Oh come on! When you make such an outrageous claim like this, back it up with a reference please. Last time I bought my forever stamps, they were 42 cents a piece. Good fucking luck getting a price anywhere near that in private industry. Sure, I can have a great web-server if I'm like FedEx and charge $30 to mail an envelope. Of course, every time the postal service wants to ask for more money to have updated services like eCommerce whatever, congress complains.

Americans are pathetic sometimes -- they expect their government services to do as well as private industry, yet they don't give them the ability to charge what private industry charges. Amtrak is a similar situation, Amtrak is expected to be cash flow positive, yet they are not allowed to own their own tracks, those are owned by the freight companies, whereas their main competitors run on highways that are paid for completely by the taxpayer and gas taxes, or operate out of airports also funded by taxpayers.

That's what you get... for not using Utilities.

[Ostracus]

"Americans are pathetic sometimes -- they expect their government services to do as well as private industry, yet they don't give them the ability to charge what private industry charges. Amtrak is a similar situation, Amtrak is expected to be cash flow positive, yet they are not allowed to own their own tracks, those are owned by the freight companies, whereas their main competitors run on highways that are paid for completely by the taxpayer and gas taxes, or operate out of airports also funded by taxpayers."

Welcome to municipal broadband. Oh wait!