Designing for Real-Time Inventory in Cross-Border E-commerce to Prevent Overselling

Preventing overselling in e-commerce, particularly in cross-border scenarios, presents significant system design challenges. The core issue often stems from stale inventory data due to slow or inaccurate upstream APIs, coupled with the concurrency of customer orders. Traditional approaches like scheduled syncs or simple caching fall short when the source of truth is inherently delayed and prone to inaccuracies, such as "orderable quantity" versus actual physical stock or even inflated numbers during sales events.

The Dual Challenge: Stale Reads & Concurrent Writes

The problem can be broken down into two main parts: ensuring fresh data for inventory queries and managing concurrent deductions reliably. Simply caching data speeds up reads but doesn't resolve the underlying data staleness. Relying on scheduled batch updates means a window of vulnerability where multiple concurrent requests can see outdated stock levels, leading to overselling before deductions can be processed.

Taocarts' Two-Layer Solution Architecture

Taocarts addresses this with a two-layer architectural approach: one for queries and another for deductions, tackling both read and write concerns in a distributed environment.

• Real-Time Inventory Query Architecture: This layer focuses on providing reasonably fresh inventory for display. It combines periodic full snapshots from the upstream API into a local database with a Redis cache. The crucial innovation is *proactive cache invalidation* and *incremental syncs* triggered immediately after a successful order for that specific product. This ensures that recently purchased items reflect updated stock quickly for subsequent queries, even if the general snapshot is older.
• Inventory Deduction during Order Placement: For the critical deduction path, a Redis distributed lock is employed. This serializes order placement attempts for the same SKU, ensuring that only one request can attempt to deduct stock at a time. Within the lock, the latest available stock is re-queried (leveraging the proactive invalidation from the query layer). If stock is sufficient, the deduction proceeds, and if not, the order fails with an 'Insufficient inventory' message. This is followed by asynchronous reconciliation to ensure consistency with the upstream supplier after a local deduction.