Design of a Billion‑Scale Vehicle‑Part Matching Cache Using Bitmap and Lua in JD's Backend

This article introduces JD's approach to storing and querying a hundred‑billion‑scale vehicle‑part matching dataset with minimal memory consumption and millisecond‑level query latency.

Background : Automotive parts have model‑specific specifications, requiring a "person → car → product" relationship to recommend the correct parts based on a user's vehicle. JD builds a user‑car profile and cleans billions of vehicle‑part mappings to form this relationship.

Data Model : The core link consists of three entities—user, passenger car, and SKU. Users bind their vehicle information in the JD app, creating a "person‑car" record. Operators then bind products to vehicle models, producing a billion‑scale "product‑vehicle" relationship.

Cache Structure Design : Two main challenges are (1) designing a storage structure for the massive product‑vehicle mapping with minimal resource cost, and (2) ensuring the query interface meets a TP999 response time in the millisecond range. JD selected JimDB’s bitmap functions for storage.

Bitmap (Bitmap) Structure : A bitmap uses a single bit to represent 0 or 1, allowing each bit to store one piece of information (2 possible values). The smallest units are bits and bytes (1 byte = 8 bits).

Bitmap Write Process : The bitmap is built on JimDB’s SDS (Simple Dynamic String) type. An SDS can grow up to 512 MiB, storing up to 2³² bits. The SDS pre‑allocation strategy reserves extra space to avoid frequent reallocations.

Compression of Product‑Vehicle Relationship : The cache stores SKU as the key and the offset of the full vehicle‑ID list as the value. Offsets are segmented (e.g., 1‑50 000 → SKU+0, 50 001‑100 000 → SKU+1) to prevent large keys. Offsets are stored as auto‑increment IDs rather than the full 7‑digit vehicle IDs, drastically reducing memory usage.

Cache Architecture Design : The architecture consists of three layers—frontend, product‑vehicle relationship layer, and storage layer. It supports horizontal and vertical scaling, cluster routing, shard routing, and cross‑region disaster recovery. Different cache clusters handle POP and self‑operated products via distinct routing keys.

High‑Performance Search : The product‑vehicle bitmap is queried via a Lua script that runs inside the cache, reducing network round‑trips. The interface receives a list of full vehicle IDs (≈5) and a list of SKUs (up to 200+), combines them, and searches the billion‑scale mapping.

The Lua script reduces application‑to‑cache communication, achieving a TP999 latency of less than 13 ms, as shown in the performance monitoring chart.

Conclusion : By employing bitmap storage, SDS pre‑allocation, segmented offsets, and Lua‑based query logic, JD built a scalable, memory‑efficient cache that supports billion‑scale vehicle‑part matching with sub‑13 ms query latency, offering guidance for similar high‑performance caching scenarios.