Where to store translations in cloud applications?

I am currently building an application for an architecture running in the amazon cloud (some webservers w/ php5.3, load balancing, PostgreSQL).

A key feature of my (PHP5) application is, that everything (on the frontend) has to be translatable into various languages, so there will be lots of strings, which are represented by a "token", that have to be translated.

My Question ist: Where would you store these translations?

• Store the translations in files on the local (webserver) disks?
• Store the translations in files on a central storage?
• Store the translations in the database?
• Elsewhere?

Additional info: No matter where the translations will be stored - there will be some caching (Redis, + template cache), so the files / DB will not be queried on every rendered page.

Each of the above solutions has pros and cons, and after lots of discussion in my team, we did not find a solution that we all were happy with.

Some of our thoughts:

• Files are easier to maintain (update translations via overwriting files)
• DB-Tables are more flexible (build a nice translation interfac开发者_高级运维e around the translation data)
• DB-Tables are only stored once; so this is cheaper than lots of files in the cloud, i think (we pay for storage and data transfer)
• Central storage for the files could be a bottleneck

So what is your oppinion?

Greetings, Robert

You should do both - maintain a master storage of the language data in a database, which will make it easy to build management application around it, and build local files (or other local storage approach) for the actual execution. Constantly querying language data from the database is wasted effort, specifically because language data typically is pretty static.

If you want to ensure scalability, you should build on at least three layers:

1. Local (SQLite, Redis, files in tmpfs...); and

2. Cloud-like (e.g. Memcached); and

3. Master storage (e.g. a database server)

The decision on which layer to store your data should always be based on from where the data is retrieved in the most efficient way:

1. Static or de facto static data (=language, configuration, skins...) should be stored locally, to guarantee fastest possible access to the data. You will have to come up with a way for building and syncing updated data across multiple servers (save for local cache, if you are using such). Approaches include: rsync, unison, Redis replication, version control systems...

2. Dynamic but cacheable data should live in the cloud-like cache, as the assumption is that it is often rebuilt and so can take advantage of the performance gains that come from sharing built data.

3. Database should be only accessed when you can't avoid it (e.g. stale cache)

I wouldn't particularly worry about the IO access costs. Scaling a database server or having to do rearchitecturing mid-project will be much more expensive than the IO. And if you're worried about it, find a local storage solution that mainly relies on RAM and you can avoid the disk reads altogether and enjoy another performance gain.