I think your mechanism of using the DB as a “reverse” cache could work.

I’m not an expert on file system replication – but it should not be so bad that you would opt for a database, especially for a media library. I’d be curious as well to know how large the library is.

Another solution would be this. Write all new data to disk and memcached. Fetch from memcached if you can (I’d key the images as URL paths and you could do this straight from your web server) and then handle the misses using the filesystem. Memcached can be spanned and accessed from multiple servers, furthermore data that hasn’t changed and therefore may no longer be in memcache, should have replicated… if not… you might have some deeper issues.

Let me know how your implementation goes. I think it will work, it’s all about benchmarking it to see if it works to your standards.

We are about to do a media library which will be on N-Servers with load balanced web/file servers. So we are thinking about performance but also replication lag of the file system.

What we are thinking of doing is saving the files to a database and having a physical pointer on the file system. When that file is requested we use htaccess to test if that file is valid, if not the application will serve the file out of the database and save it in the pointer location. So next time the file will come from the file system.

The benefit of this solution is we can drop in new file application servers with no replication lag.

It seems to be the ideal solution, but any feedback would be great.

Cheers John