While using Commonwealth Bank’s online bank NetBank last week I transferred over $1000 on to my Credit Card. I didn’t owe anything on this credit card I just wanted the funds on there to use… Since then I’d noticed my Available balance was on top $2000 of my limit…

Really confused thinking the bank had screwed up and increased my limit without my authorisation I gave them a call. Just off the phone and I’ve found out they currently have a sporadic error occurring on NetBank.

Basically some transfers being made between accounts are registering the deposit twice, and the withdrawal once!! I.e. I was withdrawing $1000 and depositing it on my card, but it was registering 2 deposits.. so $2000 in total… CHING CHING!

The phone operator corrected the error despite me insisting it be left how it was He also said the problem would have been corrected in a couple of days anyway - but I wonder whether it really would have?

This is just one VERY good example of why you should build thorough logging in to your web applications for auditing purposes. Just think the amount of money this bank would be losing is they hadn’t!! Or perhaps are if they are relying on fools like me to point out their mistakes.

This raises an age old question which will likely be debated for many years to come. Ultimately both methods of storage have their benefits and costs.

Storing images on the file system has a marginally faster retrieval rate, thanks to web and proxy servers being good at what they do.

Storing images in a database allows for all of your data to be central stored which is more portable, and easy to replicate. This solution would likely also be easier for taking a point-in-time backup with referential integrity.

Which option you choose would really depend on the type application you’re building in my opinion.

So if you’re building an application with a moderately sized amount of image data, and moderate amount of traffic using a database would be okay as the benefits outway the cost. However if you’re building something like flickr with large amounts of data and high traffic, using the file system would be the advised approach.

I’ve also heard of a combined solution that could provide the best of both world. This is storing your images in the database to gain the benefits there, but also use filesystem caching of these to obtain the performance benefits.

For a senario of a small photo storage site with 2 Gig of images, I would recommend the filesystem approach or consider attempting the combined solution. Although at only 2 Gig either approach would be fine… but we need to allow for some growth, it could boom right?

Some tips for getting the best performance out of the filesystem:

• Limit the number of images in any one directory (or suffer performance loss)
• Include not only an image identifier in the filename, but also a secret code (to prevent discovering files)

See the following website has some great information on flickr:

http://www.highscalability.com/flickr-architecture

Additionally there is this presentation on scalable web architechure:

http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches