Content staging and global reach

Nat Tam asked on March 16, 2015 18:02

Hi, I'm looking for some guidance around configuring Kentico to target a global audience. We are building a multi-site platform with editors and end users located in many locations worldwide. I'm investigating options (beyond CDN) which can maximise performance for both these categories of user.

Our feedback from Kentico themselves is that we should stick to a single production database. This would mean our only real option for globally distributing delivery would be CDN. However Kentico have also suggested that we could have multiple staging environments where content is managed. This would mean at least editors on opposite sides of the globe could edit content in geographically local staging environments and we could use bi-directional content staging to synchronise the live site.

Does anyone have experience with this kind of setup? Would you have any reason to recommend against it?

Also, if staging environments can be separated, why in theory can't the live site be served from multiple physical locations which also use content staging to stay synchronised?

I'd appreciate any guidance you have around this issue because these are big decisions that need to be made early yet could really affect the success of the project. Thanks in advance.

Correct Answer

Jiri Slapak answered on April 13, 2015 11:22

Hello Nat,

Our team was recently doing a research about this in general (not only connected to current Kentico features), so please let me present you our findings:

  • Replication of SQL server by is problematic and slow (we tried MS SQL replication, MS Sync framework and Azure SQL Data Sync), so having multiple DBs with compute instances in multiple regions for production purposes is not a good idea as it is approach that has been used in history and have been proven not optimal many times. Also the cost is much higher than any other solution.

  • Staging as a form of SQL replication has the same limitation as general tools used for SQL replication I mentioned earlier. Also please know that staging is not able to synchronize all types of Kentico objects. Now that is not a problem in case of development / administration as some synchronization lag is usually acceptable, there should be much lesser chance of conflicts and in case of conflicts it will be much easier to notice and resolve them without end clients ever noticing anything. Also in this scenario content staging will be synchronizing all the objects you need. However in production environment you would run into problems with the objects that can't be synchronized with staging and into conflicts and also synchronization lag would be much bigger problem.

  • Having multiple compute instances across regions with single DB is possible, however the region that does not have DB locally will be around 50% slower when it needs to connect to DB. Therefore this will help in that region in case of heavy output caching. The problem with this solution is that you still have only 2 points of presence, which means it will be still much worse than using CDN.

  • The best option definitely is CDN for as much content as possible - not only images, but also javascripts, CSS, parts of asynchronously loaded HTML etc.

0 votesVote for this answer Unmark Correct answer

   Please, sign in to be able to submit a new answer.