I'm currently designing a set of webservices related to travel industry. one of this service need to be take in input a airport code and a locale, and return the localized city name.

fn(cityCode) => localizedCityName
fn(airportCode) => cityCode, localizedCityName, localizedAirportName

I have currently in the mongodb a collection of cities which contains, among other stuff, for each city, localized infos, and airports list :

 airports:[{code:'GTW', name:'Gatwick'}]

I'm wondering what would be the best performant and scalable since :

  • The pivotal format is json (so moving data from solution to another is easy)
  • There are about 200 cities, but each city can contain a significant amount of data not related to our use)
  • The data we need is rarely or never changing (gatwick airport will always be in london ...)
  • There is need to localize a few cities at a time (20 to 100).
  • the api is only on one server (with redis installed) but we hope to get one day to the point where clustering would be required.

I was considering :

  1. Leave the data in MongoDB, and query as needed, and use index to optimise. Pros : data consistency, unique source for the queries. Cons : not performant

  2. Re-arrange my json, and store it to many files, by rearrange i mean having a assoc json array with cityCode as the key , and airportCode for the other files pros: Uber faster cons: no consistency, not scalable ??

  3. Re-arrange my json and store to a redis same as before except it's on a redis cache pros: Same as before except more scalable maybe cons: need to read and parse the json (i couldn't really see anything else)

NOw the questions :

  1. Do you have some other strategies to recommend ?
  2. Which one should i go for and why ?

closed as primarily opinion-based by user40980, JeffO, BЈовић, GlenH7, Bart van Ingen Schenau Feb 16 '15 at 15:00

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


The most performant solution is in-memory, after that.. YMMV. For example, reading the data from file can be slower than reading from the DB. I wouldn't like to say which is better, so you'll have to test it.

However, if redis is caching the file, then this will be faster (effectively in-memory!) so I'd go for that, but automated consistency is something worth having. So, I would generate the files from the data held in the DB. If you do this at startup (or reload of the application), you can ignore the file completely and apart from a delay between updating in the DB and writing to file (which I assume you'd schedule for a known release time) you're good to go. Obviously you could add a method to your administrative system to force a rewrite which might be even better.

  • Thanks for the input .I did go for a file solution with and admin to re-generate the file on demand. The data is also in redis, so i'll test both to figure what works best – syroz Feb 15 '15 at 18:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.