The common practice, when taken to an application, is to deploy to a server and provide an access point for the application. If the application wins global proportions, the process is repeated; however, it usually performs deployment on servers geographically closest to the new market where the product wants to be established. There's nothing wrong with that; the problem arises with regard to the location of database servers.

It is relatively common to see applications that are strategically distributed geographically, but fetch data from a server many kilometers away. This practice represents a different experience in each part of the world because, for example, if the database servers are in the United States, the experience for the end user will be much better in the United States than in Australia. This is due to physical distance, latency, and possible loss of packets. The solution to this problem is regionalization of the data. If we think of our news portal, people in Europe are more interested in information about Europe than about South America. This means that when my editorial publishing system publishes a new word, you must store the data first by region and let the data be subsequently standardized in a process similar to the CQRS. In a few moments, the data does not need to be standardized due to the specificity of the subject.

Data distribution strategies by geographical location may be the most diverse. However, something that cannot be passed over is the regionalization of data, because it influences directly on the performance of the application.