# Options for distributed architecture

**URL:** <https://www.ruby-forum.com/t/options-for-distributed-architecture/119795>\
**Category:** Rails\
**Created:** [November 10, 2007, 4:41pm UTC](https://www.ruby-forum.com/t/options-for-distributed-architecture/119795 "2007-11-10T16:41:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![tobynicholas](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e9c0ed/32.png) [@tobynicholas](https://www.ruby-forum.com/u/tobynicholas)\
**Post date:** [November 10, 2007, 4:41pm UTC](https://www.ruby-forum.com/t/options-for-distributed-architecture/119795/1 "2007-11-10T16:41:38Z")

</div>

Apologies for the long post!

I’m working on an application which is standard Rails fare:  
database-centric, hosted, with RESTful (-ish!) controllers exposing  
methods as web services. Nothing out of the ordinary.

But at some point I’m going to run into a barrier as my audience is  
quite conservative and certain organisations that form a very important  
part of my target audience will want, and probably demand, the _ability_  
to deploy their application onto their own servers, even if they end up  
using the hosted service day-to-day. This is no huge business obstacle  
as I intend to open-source the app anyway. Naturally, I’d hope and  
expect the majority of clients to use the hosted version. The reality is  
that they are more likely to if they know that they can use the app  
locally if the company managing the hosted version goes belly-up.

However, what I don’t want is all the data they are storing in the  
locally-deployed app to be locked away from the outside world. Although  
they may be entering data into their own deployment, I’d like the  
centrally hosted application to keep a read-only cache of their data as  
up-to-date as possible, at least updated once every 24 hours, and make  
it available to other users to the extent the owner of the data permits  
(these rules are embedded in the app already, so “all” that would be  
required is for the ‘slave’ deployment to communicate updates to the  
‘master’). Naturally clients would have the ability to turn off this  
synchronisation.

RDBMS-native replication doesn’t seem to make sense as I have no control  
over the application deployments. I’m looking at using web services to  
communicate updates from one deployment to another, but would rather  
avoid re-inventing the wheel as I can imagine this getting tricky  
quickly. Are there proven architectures for this situation? Should I be  
looking to simultaneously update the local and remote application or  
batch updates each day? I’m not talking about high volumes of data or  
large number of deployments. And I don’t want to over-engineer an  
architecture that I hope will be used very little!

Any thoughts very welcome as I go into this,

Toby