Available to Promise

Introduction

What is the common infrastructure hurdle shared by high-frequency trading, ad bidding, and eCommerce? Accurate and real-time inventory. All these domains have a finite commodity to trade, and it’s constantly changing hands — every nanosecond, millisecond, or second.  If an overly accurate view of inventory is provided, the risk is lost business, and likewise, providing overly cautious approximate estimates results in a bad customer experience.  Optimizing this objective function at scale in real-time has been the secret sauce of pioneers – until today.  Read on to learn how bi(OS) solves this objective function with a few lines of JSON¹.

eCommerce Available to Promise (ATP)

Inventory management is a large-scale distributed counter problem across hundreds of geo-locations, thousands of product SKUs, and millions of concurrent users. Imagine a typical eCommerce flow: A consumer performs a search, browses various products, adds some to the cart, and then places an order.   Most eCommerce sites rely on ip2geo capabilities to find the closest physical location to the user to determine a real-time and user-tailored view of inventory.  This inventory value is called “Available to Promise” (ATP).  ATP is used across:

• Search:  ATP can optimize the product sort order after retrieving the search results.
• Product View:  Once a user clicks on a particular product, ATP is used to –
  • Provide an expected delivery date (EDD) based on the closest physical location.
  • Allow the user to pick up the product from the nearest store².
• Add to cart:  During the add-to-cart flow, ATP is rechecked to warn the user if it is low.
• Place Order:  ATP is updated to avoid double reservations once the order has been placed.
• Replenishment:  When retailers fulfill items, ATP bulk updates are performed (usually nightly).

Most eCommerce sites implement ATP using microservice principles, which mandate polyglot persistence (as shown in the figure above).  This architecture requires a multitude of DevOps capabilities and suffers from the following disadvantages –

• Inventory is never real-time – Read-optimized caches lag system-of-record databases by minutes to hours.  This especially hurts around boundary conditions (e.g., low inventory)
• Inventory replenishment is usually done during off-peak hours to avoid extra load on the databases serving real-time APIs.
• During multi-data store synchronization activity, consumers experience 10X+ higher p99.
• Analytics use cases (e.g. SKU velocity and forecasting) lag in real-time view for a few hours.

The bi(OS) way to ATP => 10X better p99 at 1/10th the TCO + many bonuses

Inspired by high-frequency trading (HFT) and ad-bidding algorithms, bi(OS) provides a unique approach to ATP that requires less than 150 lines of code to implement, with only data analyst skills required.  It has the following highlights:  

• Inventory updates can be recorded as deltas or absolute values.

• bi(OS) materializes inventory updates into snapshots at a user-defined interval (as low as 1s).

• Inventory reads can be served from snapshots or snapshots merged on the fly with updates.

• bi(OS) gives API vs. ETL accesses separate quality-of-services(QoS) to avoid p99 degradation.

These operations are performed in an SQL-friendly dialect, with QUORUM consistency across three zones of any cloud provider region. Further, bi(OS) has a JSON/YAML-based declarative DDL that allows for in-production changes. Some bonus advantages are:  

• bi(OS) ships with built-in ip2Geo capabilities that are updated weekly.
• All data within bi(OS) can be exported to cloud data ware/lake houses in Parquet format.
• Analytics teams can access bi(OS) without risking consumer service-level objectives (SLOs).

Thus, bi(OS) provides a 10X+ better ATP solution than the current state-of-the-art.

Results – 4vCPUs + 6GB of RAM = Fortune 25’s ATP with p99 < 10ms.

bi(OS)’s ATP approach was validated at a Fortune 25 omnichannel retailer.  bi(OS) was deployed across three zones within the West US 2 region of Azure.  An ATP micro-service simulator was executed on a single VM with four vCPUs and 6GB of RAM. A constant load was generated using Jmeter for 12+ hours. The results (as reported by Jmeter) are noted below.

Also, during this time, the bi(OS) cluster was processing live eCommerce traffic with a max of 2.1K inserts/sec, 1.2K+ selects/sec (heavy ETL select * queries running every minute), 50+ selects/sec (selects from aggregates going back 30 days), and 10’s of ad-hoc selects (reporting queries).  Underlying bi(OS) storage was 65%+ full.

Conclusion

ATP is the Achilles heel of eCommerce success and many other domains that rely on real-time data. Its use can significantly impact acquisition, personalization, fulfillment, and operational aspects.  bi(OS) provides an ATP solution that is 10X better in real-time capabilities and TCO than the alternatives.

About bi(OS)

bi(OS) is the most efficient serverless infrastructure for real-time data+AI apps in terms of watts, SLA, and labor. It contains a scale-out SQL-friendly database with zero-code capability to onboard, process, and operate data.  It also ships with reference data+AI apps for retail and eCommerce.  bi(OS) can be used for real-time data integration, feature store, data science, cataloging, observability, DataOps, and BI.  A single data analyst using bi(OS) can deliver API, AI, and BI use cases in days, with minimal ETL – if any at all.

Sign up here to take bi(OS) for a test drive.