The development of Global Scale

Monday, May 22, 2017| Tags:

The architecture of Nextcloud is a classic Web Application architecture. I picked this architecture 7.5 years ago because it is very well known and is proven to be scaled relatively easily. This usually works with off the shelf technologies like http load balancers, clusters of Linux webservers and clustered databases.

But for many years users and customers asked for ways to distribute a single instance over several datacenters. A lot of users and customers run organizations that are not in one office or sometimes not even in one country or on one continent. So how can the service run distributed over different hosting centers on different continents?

Until now there was no good answer for this requirement.

Over the years I talked with users who experimented with different approaches. Unfortunately, they all didn’t work.

If you talk to storage people how to solve this challenge they say: No problem. Just use a distributed storage system like Gluster, Ceph, Hadoop or other.

If you talk to database people and how to do this they say: No problem! Just use one of the cluster and replication systems for Oracle, MySQL, MariaDB and others.

The challenge is how this all works together. If a user changes a file in Nextcloud then it is necessary that the file is changed, potential encryption keys are updated, log files are written, database tables are changed, email notification are sent, external workflow scripts are executed and a lot of other things happen. All these operations that are triggered by a single file change have to happen in an atomic way. It happens completely or not at all. Using database replication and storage replication independently will lead to a broken state and data loss. Additional problems are that you need the full bandwidth and storage in all data centers. So there is a lot of overhead.

The Global Scale architecture, that we designed, is currently the only solution, as far as I know, which solves this challenge.

Additional benefits are that the storage and database and overall operational costs decreases because simpler, commodity and more standard components can be used.

Another benefit is that the locality of data can be controlled. So if it is a legal requirement that certain files never leave a certain jurisdiction then this can be guaranteed with the right GS Balancer and File Access Control settings.

So far I only talk about the benefit that GS breaks a service down into several data centers. This is only half of the truth. Nextcloud Global Scale can be used in an even more radical way. You could stop using clustered Nextcloud instances in general. Killing all central storage boxes and databases and move completely to commodity hardware. Using only local storage and local databases and local caching. This changes the world completely and makes big storages, SAN, NFS and object store boxes completely obsolete.

The Global Scale architecture idea and implementation were developed over the last year with feedback and ideas from many different people. Storage experts, Database vendors, Linux distribution people, container and orchestration experts for easy automatic deployment and several big customers and users of Nextcloud.

The main inspiration came out of long discussions with the people at DeiC are running the National Research and Education Network of Denmark. DeiC was doing successful experiments with a similar architecture for a while already.

At Nextcloud we are committed to develop everything we do as open source. This includes this feature. Also, if you want to contribute to this architecture then no Contributer License Agreement is needed and you don’t need to transfer any rights to the Nextcloud company.

More information about Nextcloud Global Scale can be found here:


Always get in contact if you have questions, ideas, proposals, requests or other feedback.

Get in Contact