Designing a Three‑Layer Protection Scheme for High‑Concurrency Contract Queries in JD Logistics

In the context of JD Logistics, contract queries are invoked by the billing system for each logistics order to verify whether a merchant has signed a contract, leading to a massive number of high‑concurrency calls.

Analysis of the business scenario shows that most queries are empty (about 40% have no result) and each merchant typically holds only 3‑5 contracts, resulting in many ineffective lookups.

Call‑volume statistics reveal an average of 20 million queries per day, with peak traffic of 40 000 queries per minute during office hours (9 am‑12 pm and 1 pm‑6 pm), and a fairly uniform distribution without sudden spikes.

To handle this load, a three‑layer protection scheme is designed:

First layer – Bloom filter: A local Bloom filter built from merchant identifiers blocks the majority of invalid requests, preventing cache penetration.

Second layer – Redis cache: Queries are cached per merchant code; a distributed lock ensures only one thread rebuilds a missing cache entry, addressing cache breakdown, while randomizing key TTL mitigates cache avalanche.

Third layer – Database fallback: If both previous layers miss, the request reaches the database, with monitoring and optional circuit‑breaker (DUCC) to protect the DB during traffic spikes.

Additional measures include broadcasting contract‑status changes via MQ to keep Bloom filters and Redis entries consistent, and pre‑caching all merchant contracts with staggered expiration to avoid cache avalanche.

The overall solution balances high availability, low latency, and data consistency for the contract‑query service under heavy concurrent load.