Back homeIndustry

E-commerce & retail

Inventory as one keyed row per SKU that several systems write, and every order line priced at the price that was valid when it was placed, in one engine behind the storefront.

The problem

Where the usual stack breaks

01
A retail system juggles three shapes at once: inventory that has to reflect the last sale, an order stream that never stops, and catalog data that changes underneath both. The typical stack is an OLTP database for orders, a cache for inventory and a warehouse for analytics, with the cache and the database racing to agree on stock.
02
Overselling is the classic symptom: the cache says in stock after the database sold the last unit. Revenue reports disagree with orders because each line was priced against whatever the catalog said when the report ran.
03
You want inventory as one keyed row per SKU that the catalog and the stock system each own a part of, orders processed as a stream in the same engine, and each order line priced at the product price valid when it was ordered.

Where NYXDB fits

Use-case journeys

Inventory & current state

Stock per SKU as one keyed row, with a slice for each system that writes it.

Blockchain & on-chain analytics

Order-stream processing

Orders are written once; revenue totals maintain themselves.

Observability & logs

Storefront analytics

Operational tables and analytical scans on one engine.

HTAP & operational analytics

Architecture

How NYXDB fits e-commerce & retail

Inventory is a versioned table keyed by (warehouse, SKU) whose slices are written by different producers; a grouped transformation keeps totals per warehouse; an ASOF LEFT JOIN transformation prices each order line at the product version valid at order time.

01
Inventory
One row per SKU; the catalog owns the item group, the stock system owns the level group.
02
Totals
Quantity per warehouse stays current as group writes arrive, maintained by a grouped transformation.
03
Orders
Order events land in an append-only table and drive the transformations.
04
Price as of order
Each order is matched to the product version whose priced_at is not after the order, with ASOF LEFT JOIN.

In practice

Representative statements

The examples use the same two tables on every page. See the SQL reference for full syntax.

Activity per balance, kept current by a transformation

CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity AS
SELECT
  chain_id,
  recipient AS address,
  token,
  COUNT(*) AS transfer_count,
  MAX(transferred_at) AS last_transfer_at,
  MAX(_index) AS activity_index
FROM transfers
GROUP BY chain_id, recipient, token;

Capabilities

What you get out of the box

Keyed stock

One row per SKU; attribute groups per producer.

Order streams

Totals stay current from the order table, maintained by transformations.

As-of pricing

Each line is priced at the version valid when it was ordered, with ASOF LEFT JOIN.

One engine

Retire the cache-and-warehouse split behind the storefront.

Learn more

Attribute groups

Several producers per row.

Joins

ASOF LEFT JOIN and LOOKUP JOIN.

Transformations

Order-stream processing.

One engine behind the storefront

Explore HTAP & operational analytics or run a node.

Get startedRead the docs