Ask HN: What should I build an iOS API in?

I wish I could provide a strong opinion on a solution good for I/O. I'd need to do research and it's probably what you've already covered, from the sounds of the conversation already here. If I were faced with the decision knowing what I know today, I'd use some queuing system RabbitMQ or other AMQP protocol with a pool of DB servers sucking up requests and processing them. You can maintain a synchronous response with the requesting server via some frontend code (Python w/ Django or Node).<p>With this setup, you can easily throw more DB instances in the pool to grow with your needs. The frontend should be able to handle as many requests as needed (especially Node which has VERY lightweight threads, I hear). You'll just need to reduce the turnaround time via the queue.

Doesn't matter what you use for front end. Ruby used to be a POS VM in terms of performance, but who knows now a'days, but just about anything can return json, so just grab what you can.<p>Your real pain point is going to be your back end. If immediate consistency isn't important, run a job queue with works in the back end hitting some kind of fast access nosql and have a worker whose job it is to write to a mysql or postgress store. raid the ebs volumes and keep a monolithic volume sister box to take snapshots off. you can have the entire environment scripted and repeatable.

There is no right answer here. It really depends on what kind of purpose your backend serves. Is it processor bound or I/O bound? How frequently is your app going to hit the backend? How fast do you expect to grow?

It probably does not matter a lot. Find a programmer that has written a server back end to an iOS app before and use what she wants to use.

Node.js