Auto Drive is a decentralized content-addressed storage solution built on the Autonomys Network, leveraging its underlying permanent storage layer known as the Autonomys Distributed Storage Network (DSN).
In order to horizontally scale our sole file cache server, we need to do a few things.
First, we need to use GeoDNS (simpler) or Anycast, via services like Cloudfare, Amazon, etc to allow DNS routing based upon geographic location. The developer should use whatever technologies they are most comfortable with.
Second, on the frontend, we should have a message stating that constantly switching locations via a VPN will result in slower site performance, as we use a geographic cache. This warning message should be displayed on account creation. But, in the future, it could be dynamicly generated based on recognition of a particular client switching locations (managed through device fingerprinting).
Third, we do not care about duplication of content (cache entries) across servers. In other words, it is ok if image.jpeg is stored on two servers. It is not a distributed database. HOWEVER, we must maintain the global state of our credit management system. In other words, across servers, we must keep track of the upload/download/pinning usage of all clients.
To implement the global credit management state, we will separate it from the CDN and put it on its own server. Servers within the CDN will query the global credit server b4 allowing upload/downloads/pins. Similarly, it will post atomic updates to the global credit server.
In the future, if the global credit server is a bottleneck, there are multiple ways to scale it. But, the simplest and best would be to distribute it and just use a distributed database service that abstracts all the complexities away from us.
In order to horizontally scale our sole file cache server, we need to do a few things.
First, we need to use GeoDNS (simpler) or Anycast, via services like Cloudfare, Amazon, etc to allow DNS routing based upon geographic location. The developer should use whatever technologies they are most comfortable with.
Second, on the frontend, we should have a message stating that constantly switching locations via a VPN will result in slower site performance, as we use a geographic cache. This warning message should be displayed on account creation. But, in the future, it could be dynamicly generated based on recognition of a particular client switching locations (managed through device fingerprinting).
Third, we do not care about duplication of content (cache entries) across servers. In other words, it is ok if image.jpeg is stored on two servers. It is not a distributed database. HOWEVER, we must maintain the global state of our credit management system. In other words, across servers, we must keep track of the upload/download/pinning usage of all clients.
To implement the global credit management state, we will separate it from the CDN and put it on its own server. Servers within the CDN will query the global credit server b4 allowing upload/downloads/pins. Similarly, it will post atomic updates to the global credit server.
In the future, if the global credit server is a bottleneck, there are multiple ways to scale it. But, the simplest and best would be to distribute it and just use a distributed database service that abstracts all the complexities away from us.