Design for Failure

Dealing well with failure ... is one of the characteristics that distinguishes a well-behaved application from one that merely works.

says Brian Goetz in Java Concurrency in Practise and I completly agree.

I recently was forced to use a web site of the Singapore government to register for marriage. Well, I have to say that I'm quite happy that they even provide a web site. Germany's government is offline in comparison to Singapore.

Anyways, the process was simple: You provide your personal details, pick a date&time and pay the fee. Sounds simple, right? Well it turns out not to be that simple after all.

After picking the date&time, I was redirected to a 3rd party web site, which is handling the payement. Unfortunately, that site needs the latest JRE installed, for whatever reason, which I didn't have. My only option was to cancel the transaction and switch to another computer, which has the latest JRE installed.

After punching in our personal details again, I wanted to pick the same date&time. Unfortunately the web site said, that the spot was blocked. I immediately thought: did they really cancel the transaction?

I know that there is the possibility that someone picked the exact same date&time that I chose, while I was switching computer, but I think that is very unlikely. The whole web site is really brittle. For instance, it heavily uses JavaScript, which only works in IE and if you submit your personal details, you can't go back to change them, you need to start from scratch.

If you design a consumer application like this and use the term transaction, I think you should really make sure that you handle your transactions properly. I know it's hard, but it's even more important when money is involved. You have to assume that the client will abort the transaction at any step in the process, for various reasons: browser crashes, no credit card at hand or the internet connection dies.