Hacker News new | ask | show | jobs
by mikegreenberg 5368 days ago
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).

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.

1 comments

Mike this is great, thank you. Good angle for me to think on.