On any given day, a typical large-scale eCommerce infrastructure is witnessing thousands of transactions happening every second, and a substantial volume of customer data being analyzed and stored. Large volumes of data such as purchasing path history, shopping cart snapshots, and externally integrated profiles are typically persisted in a Big Data store (NoSQL database for instances), in order to be analyzed for business value later on.


Meanwhile, in an omni-channel retail world the time value of data—the measure of its useful timespan—is growing shorter and shorter. What’s driving this are things like:

  • Decrease in the cumulative time spent by a customer on an eCommerce website (less than 5 minutes!)

  • Personalization of shopping experience in real-time to allow for proper customer segmentation (buyer vs. hunter vs. browser) and appropriate retargeting.

  • Time-to-Insight driven workflows (e.g: adding a wish-list item your mobile phone in-store, then expecting recommendations around it on a website channel.


Value of Data Over Time


Decreasing data, analysis, and decision latencies have a ripple effect from the frontend all the way downstream to storage architecture layers. This is a low-latency and event-driven architecture problem that is not suited to the world of traditional databases, or the volume-centric world of NoSQL databases. Consequentially, the main question is, can in-memory data grids which are originally designed for low-latency and compute-bound problems, serve as the next generation real-time infrastructure for eCommerce?


 Achieve full omni-channel retailing with XAP In-Memory Computing. Give XAP a test drive.


In-Memory Data Grids as the Next eCommerce Infrastructure

Modern in-memory data grids (IMDG), such as GigaSpaces XAP, are a solution to common low-latency / high-throughput problems in financial services, telecommunications, transportation, and other mission critical application domains. A typical IMDG is created from a cluster of machines that work together by federating their collective RAM capacity to create a resilient shared data fabric for low-latency data access and extreme transaction processing. At the heart of GigaSpaces XAP in-memory data grid is the co-location of data and business logic within the boundaries of one node, promoting maximum data locality. This unit of scale is one of many instances cooperating in a sharded or replicated topology to provide distributed computing capabilities.


Throughout our engagements with large-scale retailers, we’ve seen the in-memory data grid pattern paving its way gradually, beyond simple distributed caching scenarios, into the different layers of the retailer’s eCommerce technology stack. This is a symptom of the current transition in the retail world from a multi-channel customer interaction to a real-time and event-driven omni-channel one. While the term “in-memory” may only imply RAM, the storage fabric behind the IMDG is two-tiered: a RAM-based partitioned storage tier for extreme low latency access, followed by a Flash/SSD-based lower tier for high capacity use cases. The two tiers are combined under one data grid fabric to provide unified query and transaction semantics against both RAM and Flash/SSD.


Our technology stack for eCommerce real-time architecture, leveraged by a few of the top 10 retailers in the world, describes the essential components that can enable real-time and event-driven capabilities across different commerce domains (product, inventory, merchandising, pricing, analytics…etc):


Real-Time Omni-channel eCommerce Architecture

The reference architecture consists of four tiers:

  • Consumers tier: a stateless tier which contains all the front-end channels and customer facing components such as shopping carts, eCommerce desktop websites, mobile websites, as well as any service API providing a commerce business capability. Each system in this tier is integrated with the downstream tier (Integration) either via service API’s or data colocation/integration through special integration adapters.

  • Integration tier: the components and services in this tier run entirely in memory to provide low-latency and real-time access to data. The purpose of this tier is to integrate session, transaction, shopping, catalog, and operational data all under one shared low-latency fabric to provide a single source of truth and enterprise-wide service access and evolution.

  • Analytics tier: this is an extension of the Integration tier, where high capacity data is stored on SSD or Flash arrays, and loaded for processing in the integration tier on-demand. Both the Integration and Analytics tier provide the enterprise-wide in-memory data grid for omni-channel commerce. As the name implies, the purpose of this tier is to provide a fast access data analytics fabric for both real-time and batch analytics using a unified API.

  • Data tier: New and emerging persistence components (relational databases, NoSQL) as well as legacy systems in this tier provide the foundational data that is loaded into the Analytics and Integration tiers.


The rest of this blog post presents a collection of design patterns that show how each layer or cross-cutting concern can be implemented.


In-Memory Data Grid Architecture Patterns for eCommerce

Global Shopping Cart

How can shopping cart data be scaled-out and shared across many server instances, data centers, and channels (mobile, web, backend)?



To benefit from a resilient shopping cart as well as cross-channel interaction, components of a shopping cart are deployed to multiple application servers. Thus, the challenges arise when it comes to replicating and linking session data across heterogeneous environments, withstanding application server instance failures, as well as providing applications with real-time and low-latency access to this data.

Cooperating Tier(s)

Consumer, Integration


A Global Shopping Cart is implemented by utilizing GigaSpaces XAP HTTP Session Sharing functionality along with multi-site data replication (if geographical redundancy is required). An eCommerce frontend hosting the shopping cart would include an intercepting filter that utilizes a space a storage medium for HTTP sessions.  Any other application server sharing this data would utilize the same session sharing filter, or directly use the space object data and linking it to its own context.


Global Shopping Cart with HTTP Session Sharing


Sample Code


Real-time Inventory

How can inventory data be stored to support scale out, low latency transactional access, and cross-channel visibility without incurring the heavy I/O of a traditional database?


Inventory data services are usually endpoints where the heaviest write throughput in an eCommerce architecture takes place. To provide highly resilient and low latency access, the principle of maximizing data locality is emphasized by scaling out inventory data in a partitioned topology.

Cooperating Tier(s)



When it comes to scalability, the fundamental law is maximize locality and minimize contention. Mutable inventory data requiring transactions benefits from data locality by co-locating code and data together in one partition. Providing such locality allows for linear scaling of inventory data access. In addition, contention is reduced via an asynchronous write-behind mechanism using the mirror service.


Real-time Inventory eCommerce


Sample Code


Event Stream Personalization

How can predictive and proactive analytics be integrated with a customer shopping session in real-time?


Shopping cart and clickstream data provide an extremely valuable stream of data that eCommerce websites can use to implement product recommendations, channel retargeting (for shopping cart abandonment), and overall customer purchase path analytics. An average shopper spends no more than a few minutes on an eCommerce, which mandates reacting to a customer’s shopping session actions in real-time.

Cooperating Tier(s)

Consumer, Integration


The colocation of shopping cart session data along with operational and product data allows both to be analyzed in real-time through an event-driven container. Changes to session data (adding or removing products from a cart) will be read by a notify container, which eventually triggers a process to lookup a recommendation item or invoke a predictive analytics (e.g. markov model) to predict and act on the next potential behavior from the customer.


Customer Personalization


Sample Code


Data-Driven Pricing

How can retailers implement real-time, scenario-driven pricing by scaling their pricing engine business rules against large volumes of customer, advertising, and inventory data?


Retailers are often challenged with capturing attention of customers, who mostly navigate their way to an eCommerce website through search engines and online ads. On search engines, customers are presented with prices from several sources, which puts pressure on margins for retailers that eventually have to adjust. Implementing a pricing engine that can respond to these events requires a real-time big data architecture with special emphasis on the volume and velocity aspects.

Cooperating Tier(s)

Integration, Analytics


Building a pricing engine as a real-time big data architecture requires the combination of two types of systems: a write-heavy velocity-driven tier (RAM) to process incoming data and read-heavy volume-driven tier (Flash/Disk) to process a data sample that cannot fit in RAM. XAP MemoryXtend combines both systems by creating a unified RAM + SSD/Flash in-memory data grid that abstracts the data query semantics from where the data is located.

XAP MemoryXtend with SanDisk ZetaScale

Product Catalog Content Delivery Network

Can a CDN-style geographical edge-caching be implemented for dynamic, seldom-changing, product catalog data?


Access to an eCommerce or mCommerce website grows by at least 500% during the holiday season (e.g. “Black Friday” or “Cyber Monday”). To provide high availability and fast static content load, retailers utilize a CDN network such as Akamai or CloudFront. Implementing the same for product data, which doesn’t often change, requires multiple copies of the product catalog data to exist across many geographical regions.

Cooperating Tier(s)



Multi-site data replication through WAN gateway can be used via a Single Master / Multi Slave topology whereas the master grid holds the product data, replicating it to slave grids. Slave grids act as endpoints accessed through a geolocation DNS routing policy. Thus, each slave grid will serve users with the closest IP address.


Multi-site Data Replication


Sample Code


Patterns of Real-time Omni-channel Commerce Architecture
Ali Hodroj
Vice President, Products & Strategy @ GigaSpaces
Ali Hodroj is the Head of Product and Technology Strategy at GigaSpaces, leading in-memory computing, big data, and machine learning/AI innovation. He’s responsible for driving the technology roadmap and vision for GigaSpaces products as well as strategic technology partnerships. He also held several other strategic roles at the company, including Director of Solution Architecture and Technology Evangelist, leading high-performance computing engagements within Fortune 500 organizations in finance, retail, telecommunications, and transportation. Prior to joining GigaSpaces, he served in technical roles at companies including General Electric, Intel, and Tektronix.
Tagged on:                             

Privacy Preference Center

Close your account?

Your account will be closed and all data will be permanently deleted and cannot be recovered. Are you sure?