Data Pipeline Architecture for Omnichannel Retail APAC: A Step-by-Step Guide

Quick Answer: A data pipeline architecture for omnichannel retail in APAC requires hybrid ingestion (managed connectors plus custom workers for regional marketplaces), Apache Kafka for real-time streaming, Apache Iceberg for lakehouse storage, dbt for transformations, and regional data landing zones for compliance with APAC data residency laws.

According to CBRE's 2024 APAC Retail report, five of the world's ten most e-commerce-penetrated markets — Korea, mainland China, Indonesia, Australia, and Taiwan — are in Asia-Pacific. Yet most omnichannel retailers in the region still operate with fragmented data stacks: a POS system that talks to nothing, marketplace feeds dumped into spreadsheets, and mobile app analytics siloed in a dashboard nobody checks. The result? Inventory mismatches, delayed customer insights, and promotional spend that evaporates across channels.

Related reading: Composable Commerce vs Monolithic Platform TCO Analysis: A 3-Year APAC Model

Related reading: Data Governance Framework for APAC Retail Multi-Market Ops: A 7-Step Guide

Related reading: Building AI-Augmented Customer Support for Retail APAC: A Step-by-Step Guide

Related reading: React Native Performance Optimisation for APAC Low-Bandwidth Networks

Related reading: AI-Powered Inventory Replenishment for APAC 3PLs: A 7-Step Implementation Guide

I've spent the last eight years building data pipeline architecture for omnichannel retail APAC clients — from Chow Sang Sang's 100+ store network across Hong Kong and mainland China to regional D2C brands expanding into Southeast Asia. This guide shares the reference architecture we use at Branch8, covering event streaming from POS, marketplace, and app touchpoints, with specific notes on latency trade-offs, cost optimisation, and the regulatory realities of operating across multiple APAC jurisdictions.

This isn't a theoretical overview. It's a build guide with real tool choices, configuration patterns, and the mistakes we've learned to avoid.

Prerequisites: What You Need Before You Start

Before touching any infrastructure, you need three things sorted. Skip these and you'll be rebuilding within six months.

A Clear Data Source Inventory

List every system that generates customer or transaction data. For a typical APAC omnichannel retailer, this includes:

• POS systems — Oracle MICROS, LS Retail, or local providers like EPOS in Hong Kong
• Marketplace feeds — Shopee, Lazada, Rakuten, Tmall (each with different API rate limits and data formats)
• E-commerce platform — Shopify Plus, Magento/Adobe Commerce, or VTEX
• Mobile app events — Firebase, Amplitude, or Mixpanel
• CRM / loyalty — Salesforce, HubSpot, or custom-built loyalty engines
• Logistics / WMS — warehouse management systems, 3PL APIs

Document the data volume per source. A 50-store retail chain in Hong Kong generates roughly 2-4 GB of raw transactional data per day. Add Shopee and Lazada marketplace feeds across three Southeast Asian markets, and you're looking at 8-12 GB daily. This matters for cost modelling later.

Defined Latency Requirements by Use Case

Not everything needs real-time. One of the most expensive mistakes we see is over-engineering for sub-second latency across the board when most retail analytics use cases need minutes, not milliseconds.

Map your use cases to latency tiers:

• Real-time (< 5 seconds): fraud detection, dynamic pricing, stock availability on product pages
• Near-real-time (1-15 minutes): inventory sync across channels, promotional spend dashboards
• Batch (hourly to daily): financial reconciliation, demand forecasting, customer segmentation

According to McKinsey's 2023 "State of Retail Technology" report, only 12% of retail data use cases genuinely require sub-second latency. Design accordingly.

Budget and Team Constraints

Be honest about your engineering capacity. A fully managed stack (Fivetran + BigQuery + dbt Cloud) costs more in licensing but less in engineering hours. A self-managed Apache Kafka + Apache Spark stack gives you control but requires at least two dedicated data engineers. In APAC, where senior data engineers command USD $8,000-15,000/month in Singapore and Hong Kong (according to Robert Half's 2024 Salary Guide), this trade-off is not trivial.

Step 1: Design Your Ingestion Layer for APAC's Fragmented Source Landscape

The ingestion layer is where APAC retail gets uniquely complicated. You're not pulling from three or four standardised APIs — you're dealing with dozens of sources across markets with different data formats, authentication methods, and rate limits.

Choose Between Managed Connectors and Custom Ingestion

For marketplace data, managed ELT tools like Fivetran or Airbyte cover Shopify, Stripe, and Google Analytics out of the box. But they have limited or no connectors for Shopee Seller API, Lazada Open Platform, LINE Official Account API, or Taiwan's momo shopping platform.

At Branch8, we typically run a hybrid approach:

• Fivetran for standardised Western SaaS sources (Shopify Plus, Stripe, HubSpot, Google Ads)
• Custom Python ingestion workers deployed on Cloud Run or AWS Lambda for APAC-specific marketplaces

Here's a simplified example of a Shopee order ingestion function:

1import requests
2import hashlib
3import hmac
4import time
5import json
6from google.cloud import pubsub_v1
7
8def ingest_shopee_orders(partner_id, partner_key, shop_id, access_token):
9    timestamp = int(time.time())
10    path = "/api/v2/order/get_order_list"
11    base_string = f"{partner_id}{path}{timestamp}{access_token}{shop_id}"
12    sign = hmac.new(partner_key.encode(), base_string.encode(), hashlib.sha256).hexdigest()
13    
14    params = {
15        "partner_id": partner_id,
16        "timestamp": timestamp,
17        "access_token": access_token,
18        "shop_id": shop_id,
19        "sign": sign,
20        "time_range_field": "create_time",
21        "time_from": timestamp - 86400,
22        "time_to": timestamp,
23        "page_size": 100,
24        "order_status": "COMPLETED"
25    }
26    
27    response = requests.get(f"https://partner.shopeemobile.com{path}", params=params)
28    orders = response.json().get("response", {}).get("order_list", [])
29    
30    # Publish to Pub/Sub for downstream processing
31    publisher = pubsub_v1.PublisherClient()
32    topic_path = publisher.topic_path("your-project", "shopee-orders-raw")
33    
34    for order in orders:
35        future = publisher.publish(topic_path, json.dumps(order).encode("utf-8"))
36    
37    return f"Published {len(orders)} orders"

Handle Marketplace API Rate Limits Gracefully

Shopee's Partner API allows roughly 10 requests per second per shop. Lazada's Open Platform caps at 40 requests per minute for certain endpoints. If you're managing 15 shops across five markets, you need a rate-limiting queue.

We use Cloud Tasks (GCP) or SQS (AWS) with exponential backoff to manage this. The alternative — hammering APIs and getting temporarily banned — costs more in recovery time than the 30 minutes it takes to set up proper queuing.

POS Event Streaming: The Edge Computing Challenge

Physical retail POS data presents a specific challenge in APAC: network reliability. A store in a Hong Kong shopping mall has stable connectivity. A pop-up in a Jakarta market may not. According to Akamai's 2024 State of the Internet report, average internet latency in Indonesia is 28ms compared to 8ms in Singapore — and that's for stable connections.

For clients with unreliable store connectivity, we deploy a lightweight edge buffer using Apache Kafka Connect with local disk persistence. If the network drops, events queue locally and sync when connectivity resumes. This pattern adds about USD $50/month per store in compute costs but eliminates data loss.

Step 2: Build Your Streaming and Batch Processing Layers

Once data is ingested, you need to route it through the right processing path. This is where the latency tier mapping from your prerequisites pays off.

Set Up Apache Kafka for Real-Time Event Streams

For the real-time tier (inventory sync, fraud detection), Apache Kafka remains the standard. In APAC, we typically deploy Confluent Cloud because managing Kafka clusters yourself in multiple regions is an operational burden that doesn't make sense for most retail organisations.

Key configuration for APAC multi-region:

1# Confluent Cloud cluster config for APAC omnichannel retail
2cluster:
3  cloud: gcp
4  region: asia-southeast1  # Singapore as primary
5  type: dedicated
6  cku: 2  # Start with 2 CKUs for ~200 MB/s throughput
7
8topics:
9  - name: pos-transactions-raw
10    partitions: 12  # Match to number of store regions
11    retention.ms: 604800000  # 7 days
12    
13  - name: marketplace-orders-raw
14    partitions: 6
15    retention.ms: 604800000
16    
17  - name: inventory-updates
18    partitions: 12
19    retention.ms: 86400000  # 24 hours — consumed quickly
20    cleanup.policy: compact  # Keep latest state per SKU

Singapore (asia-southeast1) is the natural hub for Southeast Asian operations. For clients with significant operations in North Asia (Hong Kong, Taiwan, Japan), we add a second cluster in asia-east1 (Taiwan) or asia-northeast1 (Tokyo) and use Confluent's Cluster Linking for cross-region replication.

Apache Spark for Batch Transformations

For the batch tier — financial reconciliation, demand forecasting, customer lifetime value calculations — Apache Spark on Dataproc (GCP) or EMR (AWS) handles the heavy lifting. A typical daily batch job for a 200-store retailer processes 15-25 GB of data and completes in 20-40 minutes on a 4-node cluster.

We've increasingly moved batch workloads to dbt running on BigQuery or Snowflake, which eliminates cluster management entirely. For most APAC retailers doing under 50 GB of daily batch processing, dbt + BigQuery is more cost-effective than maintaining Spark infrastructure. According to Snowflake's 2024 Data Trends report, retail organisations using ELT-first architectures reduced their data engineering overhead by 35% compared to ETL-centric approaches.

When to Use Apache Flink vs. Kafka Streams

For stream processing logic (enriching events, windowed aggregations), you have two practical choices:

• Kafka Streams — best for simple transformations, runs as a regular Java/Kotlin application, no separate cluster needed. We use this for inventory count aggregation.
• Apache Flink — necessary for complex event processing with large state, multi-stream joins, or exactly-once processing guarantees. We use this for real-time fraud detection where you need to correlate POS transactions with loyalty card usage patterns.

Flink is more powerful but operationally heavier. For 80% of APAC retail use cases, Kafka Streams is sufficient.

Step 3: Architect Your Storage Layer with Apache Iceberg

The storage layer is where cost optimisation matters most. APAC omnichannel retailers typically accumulate 5-15 TB of historical data within the first year. Poor storage decisions compound into significant cloud bills.

Why Apache Iceberg Fits APAC Retail

Apache Iceberg has become our default table format for the data lakehouse layer. The reasons are specific to omnichannel retail:

• Time-travel queries — when a marketplace retroactively adjusts commission rates (Shopee does this quarterly), you can query historical data states without maintaining separate snapshots
• Schema evolution — APAC marketplaces change their API schemas with minimal notice; Iceberg handles column additions and type changes without rewriting entire tables
• Partition evolution — as you expand to new markets, you can change partition strategies without migrating data

For a client expanding from Hong Kong into three Southeast Asian markets, we structured the lakehouse as:

1-- Apache Iceberg table for unified order events
2CREATE TABLE warehouse.orders_unified (
3    order_id STRING,
4    source_platform STRING,     -- 'shopify', 'shopee_sg', 'lazada_my', 'pos_hk'
5    customer_id STRING,
6    order_timestamp TIMESTAMP,
7    currency STRING,
8    total_amount DECIMAL(12,2),
9    total_amount_usd DECIMAL(12,2),  -- Normalised for cross-market reporting
10    items ARRAY<STRUCT<
11        sku STRING,
12        quantity INT,
13        unit_price DECIMAL(10,2),
14        discount_amount DECIMAL(10,2)
15    >>,
16    shipping_country STRING,
17    fulfillment_status STRING,
18    ingested_at TIMESTAMP,
19    processed_at TIMESTAMP
20)
21PARTITIONED BY (days(order_timestamp), source_platform)
22LOCATION 's3://retail-lakehouse-prod/orders_unified/'
23TBLPROPERTIES (
24    'write.metadata.delete-after-commit.enabled' = 'true',
25    'write.metadata.previous-versions-max' = '50'
26);

Storage Tiering for Cost Control

Not all data deserves hot storage. We implement a three-tier approach:

• Hot (0-90 days) — Standard storage class, fully queryable. This is where active reporting and real-time dashboards pull from.
• Warm (90-365 days) — Nearline/Infrequent Access. Queryable but with slightly higher retrieval costs. Used for quarterly reporting and YoY comparisons.
• Cold (365+ days) — Archive/Glacier. Kept for compliance and annual audits.

For a client with 12 TB of historical data, this tiering reduced monthly storage costs from USD $420/month to USD $185/month on GCP — a 56% reduction (Branch8 internal benchmarking, 2024).

Multi-Currency and Multi-Timezone Handling

This is an APAC-specific pain point that most generic architecture guides ignore. When your POS in Hong Kong records HKD, your Shopee Singapore store records SGD, and your Lazada Malaysia store records MYR, you need a consistent approach:

• Store amounts in the original transaction currency
• Add a normalised USD column using the exchange rate at transaction time (we pull from the European Central Bank's daily reference rates via their free API)
• Store all timestamps in UTC with a separate local_timezone field

Skipping this normalisation step means your cross-market revenue dashboards will be wrong, and fixing it retroactively across millions of records is painful.

Step 4: Implement Transformation with dbt and Enforce Data Quality

Raw data is useless until it's transformed into analysis-ready models. This is where dbt (data build tool) has become indispensable for our APAC retail pipeline architecture.

Structure Your dbt Project for Multi-Market Retail

We organise dbt models in four layers:

• Staging (stg_) — one-to-one mappings from raw sources, light cleaning, type casting
• Intermediate (int_) — cross-source joins, identity resolution, currency normalisation
• Marts (mart_) — business-ready tables organised by domain (orders, inventory, customers)
• Metrics (metric_) — pre-aggregated KPIs for dashboard consumption

Example dbt model for cross-platform order unification:

1-- models/intermediate/int_orders_unified.sql
2
3{{ config(
4    materialized='incremental',
5    unique_key='order_id',
6    partition_by={'field': 'order_date', 'data_type': 'date'},
7    cluster_by=['source_platform', 'shipping_country']
8) }}
9
10WITH shopify_orders AS (
11    SELECT * FROM {{ ref('stg_shopify__orders') }}
12),
13
14shopee_orders AS (
15    SELECT * FROM {{ ref('stg_shopee__orders') }}
16),
17
18pos_transactions AS (
19    SELECT * FROM {{ ref('stg_pos__transactions') }}
20),
21
22unified AS (
23    SELECT
24        order_id,
25        'shopify' AS source_platform,
26        customer_email,
27        order_timestamp,
28        currency,
29        total_amount,
30        {{ convert_to_usd('total_amount', 'currency', 'order_timestamp') }} AS total_amount_usd
31    FROM shopify_orders
32    
33    UNION ALL
34    
35    SELECT
36        order_sn AS order_id,
37        CONCAT('shopee_', shop_region) AS source_platform,
38        buyer_username AS customer_email,
39        create_time AS order_timestamp,
40        currency,
41        total_amount,
42        {{ convert_to_usd('total_amount', 'currency', 'create_time') }} AS total_amount_usd
43    FROM shopee_orders
44    
45    UNION ALL
46    
47    SELECT
48        transaction_id AS order_id,
49        CONCAT('pos_', store_region) AS source_platform,
50        loyalty_card_id AS customer_email,
51        transaction_timestamp AS order_timestamp,
52        store_currency AS currency,
53        total_amount,
54        {{ convert_to_usd('total_amount', 'store_currency', 'transaction_timestamp') }} AS total_amount_usd
55    FROM pos_transactions
56)
57
58SELECT * FROM unified
59{% if is_incremental() %}
60    WHERE order_timestamp > (SELECT MAX(order_timestamp) FROM {{ this }})
61{% endif %}

Data Quality Gates with dbt Tests and Elementary

APAC marketplace data is notoriously inconsistent. Shopee's order status taxonomy differs from Lazada's. Product category codes don't map cleanly across platforms. We enforce quality at the transformation layer:

1# models/intermediate/schema.yml
2models:
3  - name: int_orders_unified
4    tests:
5      - dbt_utils.unique_combination_of_columns:
6          combination_of_columns:
7            - order_id
8            - source_platform
9    columns:
10      - name: total_amount_usd
11        tests:
12          - not_null
13          - dbt_utils.accepted_range:
14              min_value: 0
15              max_value: 100000  # Flag anomalies above $100K
16      - name: source_platform
17        tests:
18          - accepted_values:
19              values: ['shopify', 'shopee_sg', 'shopee_my', 'shopee_th',
20                       'lazada_sg', 'lazada_my', 'pos_hk', 'pos_sg']

We also run Elementary (an open-source dbt-native data observability tool) for anomaly detection — catching volume drops, schema changes, and freshness issues before they hit dashboards. According to Gartner's 2024 Data Quality Market Guide, organisations that implement automated data quality monitoring reduce data incident response time by 60%.

Step 5: Set Up Cross-Border Data Compliance and Governance

Data pipeline architecture for omnichannel retail APAC operations must account for the region's fragmented data protection landscape. This isn't optional — it's a legal requirement that affects your architecture decisions.

Navigate APAC's Data Residency Requirements

Key regulations that affect pipeline design:

• China's PIPL — personal information of Chinese citizens must be stored within mainland China. Cross-border transfers require a security assessment by the Cyberspace Administration of China.
• Vietnam's PDPD — effective from July 2023, requires data localisation for certain categories of personal data.
• Indonesia's PDP Law — enacted in October 2022, mandates data breach notification within 72 hours.
• Singapore's PDPA — relatively permissive on data transfers but requires contractual safeguards.
• Australia's Privacy Act — recent amendments strengthen cross-border data transfer requirements.

Architecturally, this means you may need regional data landing zones. For our client with operations in Hong Kong, Singapore, and mainland China, we deployed separate GCP projects in asia-east2 (Hong Kong) and a Tencent Cloud instance in Shanghai, with only aggregated and anonymised data flowing to the central analytics warehouse.

Implement Consent-Aware Data Pipelines

Every ingestion pipeline should check consent status before processing personal data. We tag records at the ingestion layer with consent flags and filter at the transformation layer. This adds approximately 5-8% processing overhead but prevents compliance violations that carry fines of up to 5% of annual revenue under China's PIPL.

Step 6: Deploy Monitoring, Alerting, and Cost Controls

A data pipeline without monitoring is a liability. In our experience at Branch8, the pipeline itself takes 60% of the build effort, and the monitoring layer takes the remaining 40%. Most teams underinvest here.

Build a Three-Layer Monitoring Stack

• Infrastructure monitoring — Datadog or Grafana Cloud tracking Kafka consumer lag, Cloud Run instance health, BigQuery slot utilisation
• Data freshness monitoring — Elementary or Monte Carlo tracking table update frequencies against SLAs
• Business metric monitoring — custom alerts when order volumes deviate more than 2 standard deviations from the trailing 7-day average (this catches ingestion failures that infrastructure monitoring misses)

Cost Optimisation Patterns for APAC Data Volumes

Cloud costs in APAC regions are 10-20% higher than US regions for equivalent compute (Google Cloud's published pricing, 2024). Specific optimisation patterns we apply:

• BigQuery flat-rate slots — for predictable workloads exceeding USD $3,000/month in on-demand query costs, commit to slot reservations. We saved one client 40% on their monthly BigQuery bill by switching to 500 flat-rate slots.
• Committed use discounts on Confluent Cloud — Kafka costs are the largest line item for most streaming architectures. A 1-year commitment typically saves 20-25%.
• Right-size Kafka partitions — over-partitioning is the most common cost mistake. You need roughly 1 partition per 10 MB/s of throughput. Most retail topics need 6-12 partitions, not the 50+ we sometimes see.

Common Mistakes and How to Avoid Them

After building data pipelines for omnichannel retailers across seven APAC markets, these are the failures we see most frequently.

Mistake 1: Treating All Data as Real-Time

Streaming everything through Kafka when 70% of your data only needs daily batch processing inflates costs by 3-5x. We audited one prospect's architecture and found they were spending USD $4,200/month on Confluent Cloud to stream data that was only queried in daily reports. Moving those feeds to a scheduled Fivetran sync reduced their ingestion costs to USD $800/month.

Mistake 2: Ignoring Marketplace API Deprecations

Shopee and Lazada deprecate API versions with as little as 30 days' notice. Tokopedia in Indonesia has changed its authentication method three times since 2022. Build version checks into your ingestion layer and subscribe to marketplace developer newsletters. Better yet, abstract your marketplace connectors behind a unified interface so swapping versions doesn't cascade through your pipeline.

Mistake 3: Single-Region Deployment for Multi-Market Operations

Running your entire pipeline from us-central1 because it's the default GCP region adds 150-250ms of latency to every API call to APAC marketplaces. It also potentially violates data residency requirements. Always deploy ingestion workers in APAC regions — Singapore for Southeast Asia, Hong Kong or Taiwan for North Asia.

Mistake 4: Skipping Identity Resolution

A customer who buys in your Hong Kong store, orders from your Shopify site, and purchases through your Shopee Singapore shop appears as three separate customers without identity resolution. This makes customer lifetime value calculations meaningless. Invest in probabilistic matching (email hash + phone number normalisation + address fuzzy matching) during the transformation layer. It's not glamorous work, but it's the difference between a data warehouse and a data swamp.

Mistake 5: No Disaster Recovery Testing

We've seen pipeline outages during major APAC shopping events — Singles' Day (11.11), Shopee's 9.9 Sale, year-end promotions — when data volumes spike 5-10x. According to Adobe Analytics' 2023 Holiday Shopping report, APAC e-commerce traffic surged 8.2x during peak promotional events compared to baseline. If you haven't load-tested at 10x your normal volume, you're not ready.

Branch8 Implementation: A Real-World Reference

To make this concrete: in Q2 2024, we built a unified data pipeline for a Hong Kong-based jewellery retailer expanding into Singapore and Malaysia. The client had 86 physical stores, a Shopify Plus e-commerce site, Shopee and Lazada storefronts in two markets, and a custom loyalty app.

The stack:

• Ingestion: Fivetran for Shopify Plus and Google Analytics 4; custom Cloud Run workers for Shopee and Lazada APIs; Kafka Connect for POS event streaming from Oracle MICROS terminals
• Streaming: Confluent Cloud (Singapore region), 2 CKUs, Kafka Streams for inventory aggregation
• Storage: BigQuery with Apache Iceberg-managed tables via BigLake
• Transformation: dbt Cloud (Team plan) with Elementary for data quality monitoring
• Orchestration: Cloud Composer (managed Apache Airflow) for batch scheduling
• Serving: Looker for executive dashboards, reverse-ETL via Census to push segments back to Klaviyo

Timeline: 11 weeks from kick-off to production. Monthly infrastructure cost: approximately USD $3,400 at launch, scaling to USD $5,100 as we onboarded the two new markets. The client's previous approach — manual CSV exports and an analyst spending 3 days per week on reconciliation — was costing them roughly USD $6,500/month in labour alone, plus the opportunity cost of delayed insights.

Decision Checklist: Is Your Pipeline Architecture Ready?

Use this checklist before going to production:

• Source coverage: Have you mapped and connected every data source, including APAC-specific marketplaces?
• Latency tiers: Have you classified every use case into real-time, near-real-time, or batch — and built accordingly?
• Data residency: Does your architecture comply with PIPL, PDPD, PDP, and Privacy Act requirements for every market you operate in?
• Identity resolution: Can you link a single customer across all channels and markets?
• Currency normalisation: Are all monetary values stored in both local and normalised currencies?
• Monitoring depth: Do you have infrastructure, data freshness, and business metric alerting in place?
• Cost controls: Have you implemented storage tiering, committed-use discounts, and right-sized your streaming infrastructure?
• Load testing: Has your pipeline been stress-tested at 10x normal volume for peak shopping events?
• API resilience: Do your marketplace connectors handle rate limits, deprecations, and schema changes gracefully?
• Recovery plan: Can you rebuild your pipeline state from source within 24 hours if the worst happens?

If you can check all ten boxes, your data pipeline architecture for omnichannel retail APAC operations is production-grade. If you can't, you know where to focus next.

Need help designing or auditing your omnichannel data pipeline? Talk to the Branch8 data engineering team — we've built these systems across seven APAC markets and can scope your project in a single working session.

Sources

• CBRE, "Omnichannel Retail and its Impact on Asia Pacific Real Estate" (2024): https://www.cbre.com/insights/reports/omnichannel-retail-asia-pacific
• McKinsey & Company, "State of Retail Technology" (2023): https://www.mckinsey.com/industries/retail/our-insights
• Robert Half, "2024 Salary Guide — Technology" (2024): https://www.roberthalf.com/salary-guide
• Akamai, "State of the Internet Report" (2024): https://www.akamai.com/internet-station/cyber-attacks/state-of-the-internet-report
• Gartner, "Data Quality Market Guide" (2024): https://www.gartner.com/en/documents/data-quality
• Snowflake, "Data Trends Report" (2024): https://www.snowflake.com/data-trends/
• Adobe Analytics, "Holiday Shopping Report — APAC" (2023): https://business.adobe.com/resources/holiday-shopping-report.html
• Google Cloud Pricing, APAC Region Comparison (2024): https://cloud.google.com/pricing