XRegional is a simple library that demonstrats a specific approach to enabling data consistency across multiple Microsoft Azure regions (datacenters).
Currently XRegional supports Azure Table Storage and Azure DocumentDb and uses Azure Queues to propagate data from a primary to a secondary storage. XRegional relies on ETags and optimistic concurrency features of Table Storage and Document Db. The ETag notion comes from the HTTP protocol space, where a client can issue an HTTP request with an If-Match request header condition, and if the server fails to meet this condition it responds with HTTP status code 412. More on this can be read at this section of the HTTP protocol specification.
XRegional approach is aimed primarily for one writer / multiple readers scenario where writes occur strictly in one region but reads occur in all regions. Nevertheless this approach allows for failover to another write location in case the primary write region experiences an outage. Also it should be understood that XRegional performs full updates of an Azure Table entity or a Document Db document, partial updates are not supported. On the other hand you might redesign your data structure such that the final entity structure will consist of multiple data parts – each independent of the other - representing different regions and each data part is updated solely by the region it represents.
XRegional introduces a simple concept of Gateway that is used in the primary region to send data over to other Azure regions. There is one interface IGatewayWriter and two implementations: GatewayQueueWriter and GatewayMultiQueueWriter to send data respectively to one or multiple secondary regions through the queues. GatewayQueueWriter stores a message to the Azure blob storage if it is exceeds 64KB limit passing a message-pointer instead. A message is zipped and passed as an array of bytes for the maximum efficiency. On the contrary, GatewayQueueReader is to be used in the secondary region and it simply dequeues the next message from the gateway queue calling either a callback for subsequent processing of the message or an “on-error” callback to give you a chance to process the poisonous message. Instead of GatewayQueueReader you should use TableGatewayQueueProcessor for Azure Tables and DocdbGatewayQueueProcessor for Document Db as those two classes implement the write operation to the secondary region’s data store for you. Either of the two QueueProcessor's can be hosted as a Worker Role or an Azure Web job.
To go and start executing writes to either an Azure Table or a Document Db collection, use SourceTable or SourceCollection respectively. Both implement a “brutal” writer approach. Their counterparts: TargetTable and TargetCollection execute writes in the secondary regions relying on the optimistic concurrenty and ETag rules.
Follow instructions in XRegional.Tests/Readme.txt to set up and run the tests. Please note that the solution will not compile unless you create the app.config file as shown in Readme.txt