Question

So I have a Rails application. It currently runs separate as front-end and back-end + database.

I need to scale it to have several back-end servers.

The backend server has Resque background workers running (spawned by user front-end requests). It also relies heavily on callbacks.

I am planning the following setup:

|front-end| --- |load-balancer (haproxy or AWS ELB)| --- Server 1 ---- Postgresql Database (+++ other DBs added via replication later if needed)
                                                    \___ Server 2 ---/
                                                                    ++ (other servers added in the same fashion later )

I have concerns about how to deal with putting Database on a separate machine in this case.

1) I intend to create a new empty Rails app with schema identical to initial back-end. Have it running and accepting updates / posts via HTTP and keep connected via remote SSH (to trigger :after_commit callbacks in back-end). Is it a bettergood idea?

2) I am using Postgresql and intend to switch to an enterprise DB once the need arises. Currently the need is to scale the part of back-end that does processing not the database.

3) Does this approach seem scalable?

Was it helpful?

Solution

I'm not sure I really understand your question. Generally in production applications the database layer is separate from the application layer. I can't quite tell if this pertains to you, but it's definitely an interesting watch. http://vimeo.com/33263672 . It talks about using a redis layer between the rails and db layers to facilitate queuing, and creating a zero downtime environment. It seems like it would be a better solution than using a second rails stack? I think it should look something like this;

|ELB| Web Servers |ELB| Application Servers |RRDNS| Redis Servers | PostGreSQL Servers |

If I am understanding your meaning. If not, that video link is still worth a watch :)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top