Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Data Patterns for the Edge: Data Localization, Privacy Laws, and Performance

Data Patterns for the Edge: Data Localization, Privacy Laws, and Performance

Key Takeaways

  • Moving to Edge will become inevitable for enterprises across industries to address data localization, privacy laws, and optimization for performance.
  • Data Pattern on Edge walks through how Edge can integrate and coexist with your existing ecosystem.
  • Industry-tested scalable data patterns allow various complex use cases to be onboarded to Edge.
  • Open-Source technologies promise a cost-efficient alternative rather than costly cloud models.
  • Expand your data horizon to the Edge for performant user experiences with a lower latency budget.

With the advent of local data-privacy laws, there is growing competition to get powerful data experiences closer to the end-users. So let’s look at different enterprise data patterns (like synchronous data retrieval, subsequent data retrieval, and prefetch data retrieval) and see how the data can be ported to the Edge without the complexities of cloning the entire architecture.

Enterprise User Experience Data

 The figure shown above shows the existing data at the enterprise level. Service A is an abstract representation of multiple services. Service B represents the service tier accessing the data locally to the data center. Service C is an abstract of all services accessing the data from external third-party providers. The data retrieval across these services can internally be classified as:

  • Synchronous Data Retrieval. Here, all user data is retrieved in a single or parent request — this could be the initial HTML payload call or service calls from the native mobile application. An example of this would be any transactional experience or personalized user experience: an enhanced version is chunked progressively or paginated to the end-user.
  • Subsequent Data Retrieval. In this case, the initial critical data is retrieved, and subsequent data is retrieved over Asynchronous calls. An example would be advertisements or game titles. You would see below the fold recommendations (wherein the required content is made available to the end-user on scroll or content below the initial screen resolution).
  • Prefetch Data Retrieval. In the third scenario, based on predictive statistics, ranking, or workflow, the user engagement time is leveraged to prefetch or load the data, which might be media resources, templates, or personalized data.

For someone unfamiliar with edge computing, anything outside your data center can be considered “the edge” of the network, given that the Software-defined networking (SDN) is closer to the end-user. You or your organization qualifies for edge computing (e.g., if the compute is an interaction between the data center and edge components; unlike local computing, where much of the computing is done toward the edge nodes of the cluster).

Even before we dive deep into data patterns of Edge computing, it’s clear that the industry norm has been moving to a static data set for user devices or the browser. Unfortunately, this has  resulted in an overhead of user resources and bandwidth and at the same time a loss of the control mechanism on the data available at some point in time. 

We try to understand how Edge can keep the traditional control knobs or semantics for the engineers at data centers and also not make users pay the penalty of your optimization. In short, we are targeting expansion of the data horizon from D space to E space, as shown in Figure 1. This expansion brings impediments associated with: 

  • Limited Infra Capex 
  • Control Mechanisms 
  • Fail Over
  • Observability
  • Data Purging
  • Experimentation
  • Traffic Routing and Ramp Up
  • Legacy Support

 The article walks through different data patterns, addresses associated problem sets, and gives insights into what technologies can be leveraged to scale for enterprise data sets.

Edge Data Pattern

Let’s discuss the three significant data patterns of Edge computing and user optimization.

Synchronous Data Retrieval

Most of the data in the internet space falls into this bucket — the enterprise data set comprises many interdependent services working in a hierarchical nature to extract required data sets that could be personalized or generic in format. The feasibility of traditionally moving this data to the Edge was limited to supporting static resources, header data sets, or media files to the edge of the CDN. However, the base data set was retrieved from the source DC or the cloud provider. 

When you look at user experiences, optimization surrounds the principles of critical path rendering and associated improvement in the navigation timelines for web-based experiences and around how much of the view model is offloaded to the app binary in device experiences. In hybrid experiences, the state model is updated periodically from the server push or pull. The use case in the discussion enables data retrieval from the Edge for personalized data sets.



User-experience data is segmented into non-user context (NC) and user context information (UC), where non-user context data upholds generic information across users or experiences. User context is specific to the device or user in the discussion. The non-user context data is stored, invalidated, and purged on the fly, and associated user-context information is stitched or tailored during the parent-request lifecycle. The design principle is that introducing Edge should not cripple the network and domain teams from implementing their respective control and optimization knobs.


Let’s discuss the data-center components first, as many of the teams already have the data-center services, and it is a good vantage point from which to start.

Data-Center Components

Service A

Typically, this is the front-end tier within the enterprise and needs to address a few changes to support the pattern above. 

The tier needs to: 

  • Propagate the Edge side-flow identifier header to the underlying service 
  • Handle the cookie management 
  • Determine and set the necessary cache-control values to cache or not to cache
  • Leverage the standard Cache-Control directives 
  • Be accountable to remove any global header or universal modules which are dynamic
  • Reinsert the same as part of the user-context response payload

The front-end tier is expected to address these four primary flows in the Edge ecosystem:

  • Regular traffic (non-POP) 
  • Regular experimentation controls traffic
  • Cache creates/writes calls that are the non-user context requests
  • User-context requests

Service B

This tier accounts for segmenting the data based on a user and non-user context made available over a module provider group like CACHEABLE. This allows the business team to control what segments of data need to be cached and or not, preceded by the ValidationViewModel, which allows rules and restrictions on restricted data sets that need not be cached. 

Experimentation and tracking are addressed at this tier for business impact analytics. Based on the Edge flow identifier headers, the decision is made at this tier to address the desired data responses, associated tracking for analytics, and color the data response with desired cache TTL values and revision ID for purge and pull. This gives control to the business team to still manage the data, even when moving to the Edge of the POP ecosystem.

Edge Components

As you observed above, the entry point for the data center behaves differently based on different headers propagated from the Edge and other actions based on the route in the discussion. At the same time, you must make sure the Edge datastore is compatible with the action of browser-based cache directives. To accommodate this on the Edge or POP, you need a scalable software load balancer like Envoy, which has powerful discovery services across the primary cluster, route, listeners, secrets, and the capability to add custom filters. As far as the Edge datastore cluster is concerned, given the caveat on datastore to understand the browser cache derivatives, ATS is a favorable and scalable option. 


As shown in the diagram below, the software load balancer accounts for these steps of operation:

  • Handling incoming user requests
  • Asking on the business-specific service E on the possible cache key
  • Retrieve the non-user context data to end-user if cache-hit
  • Consistent hashing-based data writes to Edge data stores if cache-miss for future invocation
  • Stitch the user context in the parent request lifecycle
  • Cache invalidation on updates or revisionID changes

Service E

This service is essential on Edge, allowing business or domain teams to feed in the necessary engineering knowledge associated with the data set in the discussion. If your data or experiences are international, service E accounts for handling different locales and additional functionalities like qualifying a user for experimentation, device detection, cache-key generation, and custom-route traversal based on URL query parameters.

Edge Data Store

The Edge datastore cluster primarily needs to address the cache-purge mechanism based on the TTL value set and do necessary invocation to the data center to retrieve the new data set. The cluster does not cache the data set even if an attempt is made when the cache-control values are set.

In our use case, ATS invokes the origin of every individual request; the ATS data store was onboarded with a custom plugin to do only when the demand has the cache-key header value, allowing the SLB to allow what and when to cache the data set.


The above approach ensures that caching the non-personalized (non-user context) on the Edge and retrieving the user-context in the request lifecycle allows the end-user to see the same non-POP experience. However, early retrieval of the non-user context to the end-user enables the browser to construct DOM, improving the Critical rendering Path performance and enabling future user data to seep into the browser rendering tier for better user perception. In our high-volume traffic pages, we could bring down the latency from > 1500ms to < 700ms, with the added advantage of handling bot traffic, centralized observability on global traffic, efficient correlation with traffic to the business.

Subsequent Data Retrieval

Unlike the synchronous data retrieval, where the power of caching is more centric to repeated calls to the data content for higher cache-hit, this may not be suitable if you have a long-tail access pattern and data retrieved is unique. The majority of these scenarios can be addressed for optimization by sending the critical content early, and then subsequent data sets can be retrieved from the Edge as required. This pattern has an added advantage to enable Edge data retrieval even when the data is unique and accessed only once, for example, in advertisements. We can validate latency budget improvement in this pattern by validating generic timelines for content retrieval for user experiences. 

In the below diagram, when a request is made from the browser (1-2), the initial page content is retrieved with associated identifiers for data content calls to be made in the future (5) (primarily triggered after the page onload events). The time taken on the browser end for DOM construction and network latency is an added advantage for parallelizing calls to retrieve data sets from the Service B tier.

As depicted in the above diagram, the potential opportunity of moving to Edge is making the content available in the Edge for different identifiers with lower TTL (short-lived transactional data set) to power the end-user experiences and, if feasible, to move the Service B to 3rd party providers closer to the 3rd party providers location for quicker data availability at Service B tier.


The data available at the data center from Service B is pushed to the respective Edge cluster. That data is available for quicker retrieval and on any miss, falls back to the traditional data from the data-center pattern. All the read and write is diverted through the same software load balancer for consistent hashing and a single point of observability. 


Let’s look at the data center and Edge components to implement the above pattern in the discussion.

Data Center Components

Service A

The Service A embeds into the existing architecture pattern to facilitate dynamic identifier creation for placements or page modules on the final response to the end-user. In a few use cases, this tier can accommodate user information to customize the page-module responses relevant to the end-user. It also mandates the propagation of the Edge flow-identifier headers downstream.

Service B

The Service B abstraction accommodates data retrieval from 3rd party systems or bidding engines. The mandate here is to have parallelized, FIFO support data retrieval.

Service C

Service C accommodates the data content written and read from the data center.

Service E

The Service E embeds Edge insights to the business teams to make data available locally to the end-user in the discussion; the tier accommodates replication and data availability based on the parent’s original request.

Edge Components


In this pattern, the Software load balancer accounts for:

  • Handling no-content scenarios with response HTTP 204
  • Addressing preflight requests and response headers for early determination of allowed domains
  • Propagation of POP cluster info for upstream services to determine session affinity for future calls
  • POST to PUSH translation for Edge Data Store (ATS)
  • Handling observability for cache-hit, cache-miss, write, read paths, data size

For example, in the below scenario where each content is unique, the hit ratio on edge is >82% with write routed to the parent request POP and not replicated to other POP in the region.


However, when the business team reduced the push of the data toward the Edge, the same was evident in the Edge side-response code for anomaly detection systems to pick it up.

Edge Data Store

In this scenario, we are leveraging the ATS in PUSH mode to store the data content of interest with associated TTL values; the critical point is the write is made through POST or PUT from the data center. However, the same is translated to the ATS-supported PUSH method to drop HTTP 201 on insertion and HTTP 200 on duplication and HTTP 204 during content miss scenarios.


The above approach opens up opportunities to move data to Edge even if the data set is accessed or used only once (short-lived transactional records), also in scenarios where the user determination is not feasible like guests or new users to the system.

Prefetch Data Retrieval

In the prefetch scenario, the focus is to have the next deterministic data set required made available. For example, consider the Service Z in the below diagram, which is the precursor to the page request in action powered by Service A, B, or C. During the funnel or workflow based on what is next, the associated (predicted or ranked) data set is prefetched and made available on Edge. This, in general, applies to scenarios like loading game tiles, recommendations, top search results, and loading media files.


The effectiveness of this pattern is more deterministic of how the associated data set is cached or stored on Edge. However, the data being made available leverages either the Synchronous Data Retrieval, Subsequent Data Retrieval, or Offline data made available.


We are now moving into an era of data explosion, which can be majorly attributed to Edge platforms. Only those organizations on Edge can transform into the successive league of innovation around Edge Intelligence. As you see in the above Edge data patterns, it’s now feasible for any organization to change its existing legacy system to take advantage of Edge computing. Because we are handling underlying data, this is foolproof for the changing technology stack; these data patterns promise localization of data-handling privacy laws.

About the Author

Rate this Article