Cloud or Local Data? Which is Right for Your Cloud-Native App?
Recently, I’ve written several articles on data architecture. Earlier this year, I wrote about how to structure your data for service-based applications, such as cloud-native applications. Last week, I wrote about data strategy and the importance of geography in data architecture.
In this article, I will focus on a different type of data locality—that is, front-to-back data locality. An important question for all cloud-native applications is, where should the application data be located? Should it be located in the front end of the application or in the back end? And, just as importantly, why does it matter?
Frontend Vs. Backend Data Architecture
The difference is conceptually simple. For a typical web browser-based application, any data that is stored in the web browser is frontend data. Any data that is stored in the backend servers is backend data. For a system using a local app instead of a browser (such as a mobile phone application or an application on your laptop), the frontend data is any data that is stored within the application itself within the user’s hardware.

Figure 1 shows frontend data stored in an end user’s web browser and mobile app and backend data stored in the backend servers that comprise the application.
Why does it matter where you store the data? Because the characteristics of how the data can be used and how it works change based on where the data is stored.
Data stored in the front end—the web browser or mobile application—is data that is instantly accessible by the user. This data allows an application to work responsively, and it also presents the ability for the application to work offline. This is because the data the application is using is stored locally on the user’s hardware. However, frontend data is available only to the single user consuming the data. It is not directly available for sharing or consumption by any other user of the application.
Data stored in the back end—the application backend servers—is data that is stored remotely from the end user. This data, when needed by the end user, is transferred back and forth over the internet between the end user (who is consuming the data) and the back end where the data is actually stored. This means there is increased latency for accessing the data. Additionally, since the network is required to utilize the data, the devices must be online to consume the data and access to the data won’t be as immediate nor as reliable as frontend data.
But backend data is data that is easily sharable with other people. That data can be consumed by anyone with permission anywhere the application is usable. The data is in the cloud and hence available for all authorized users to access expeditiously.
Given these options, the question is clear. Where should data be located? The answer depends on the data requirements and the needs the user has for the data. The answer is data-specific.
Let’s take a look at a simple example—let’s look at two different real-world word processors that both do essentially the same thing—they allow you to write, edit and view documents. However, the way they implement these requirements is totally different, and the data storage they use is also radically different.
Microsoft Word stores your documents locally on your device. This is basic frontend data. It is fast, responsive, and you always have your data with you (even when your device is offline). However, sharing your documents is harder because you typically have to send the documents back and forth to collaborate on them. Google Docs stores your documents in the backend servers. It is not quite as fast or responsive, and you typically have to remain online to access the documents, but sharing them is substantially easier. In fact, multiple people can collaborate on the same document in real-time—it just works.

The difference between MS Word and Google Docs is the specifics of the chosen data architecture and where the data is actually located. Each application basically does the same job, but by selecting a different data architecture, the applications are optimized for different use cases—optimal single-user experience versus optimal shared experience. There is nothing wrong with either architecture; they are just serving a slightly different need.
Selecting your application’s architecture
Selecting where to store your application data—backend or frontend—is a critical step in creating your overall data architecture and a step that is highly dependent on the needs and requirements of your users.