Storing images in file system and returning URLs or virtually resizing and returning byte arrays?

Posted by ismaelf on Programmers See other posts from Programmers or by ismaelf
Published on 2012-03-19T23:07:30Z Indexed on 2012/03/19 23:38 UTC
Read the original article Hit count: 164

I need to create a REST web service to manage user submitted images and displaying them all in a website. There are multiple websites that are going to use this service to manage and display images. The requirements are to have 5 pre-defined image sizes available.

The 2 options I see are the following:

  1. The web service will create the 5 images, store them in the file system and and store the URL's in the database when the user submits the image. When the image is requested, the web service will return an array of URLs.

    I see this option to be a little hard on the hard drive. The estimates are 10,000 users per site, and lets say, 100 sites. The heavy processing will be done when the user submits the image and each image is going to be pulled from the File System.

  2. The web service will store just the image that the user submits in the file system and it's URL in the database. When the user request images, the web service will get the info from the DB, load the image on memory, create its 5 instances and return an object with 5 image arrays (I will probably cache the arrays).

    This option is harder on the processor and memory. The heavy processing will be done when the images get requested.

    A plus I see for option 2 is that it will give me the option to rewrite the URL of the image and make them site dependent (prettier) than having a image repository for all websites. But this is not a big deal.

What do you think of these options? Do you have any other suggestions?

© Programmers or respective owner

Related posts about design

Related posts about ASP.NET