Taming 20M Daily Calls: Bloom Filters & Redis Power JD Logistics’ Contract Center

Introduction

The Logistics Contract Center is the sole entry point for JD Logistics contract management, offering merchants contract creation, stamping, customization, archiving, and querying capabilities across many business lines. Providing highly available query services is critical, as the billing system must verify contract signatures for each logistics order to ensure accurate billing.

Business Scenario

2.1 Query Dimension Analysis

Most contract queries originate from the billing system, which checks whether a merchant has signed a contract during order settlement. Queries typically involve multiple conditions but focus on a specific merchant or merchant attribute such as a business account. Approximately 40% of queries return no results, mainly because the merchant has never signed a contract; the remaining queries return a small number of contracts (usually 3‑5 per merchant).

2.2 Call Volume Analysis

Current contract call volume is roughly 20 million requests per day. Daily call distribution peaks during working hours, especially between 9 am‑12 pm and 1 pm‑6 pm, with a maximum of 40,000 calls per minute. Monthly statistics show a relatively even distribution without sudden spikes.

Solution Design

To support the high call volume and ensure data consistency, a three‑layer protection architecture is proposed:

3.1 First Layer – Bloom Filter

Since nearly half of the queries return empty results, they represent cache‑penetration traffic. A Bloom filter is introduced to quickly reject non‑existent contracts before reaching Redis or the database. The filter is deployed locally on each service instance to avoid an extra network hop, and updates are broadcast via MQ to keep all instances synchronized.

3.2 Second Layer – Redis Cache

The second layer uses Redis to cache contract data, addressing cache‑breakdown and cache‑avalanche issues. Strategies include randomizing cache TTL, using distributed locks to prevent thundering‑herd queries, and optionally setting keys to never expire with background refresh. Queries are normalized to a merchant code key, allowing a single cache entry per merchant that contains all its contracts, thus limiting key size and avoiding large‑key problems.

3.3 Third Layer – Database

If a request bypasses the first two layers, it falls back to a direct database query. To protect the database during traffic spikes, all merchant contracts are pre‑cached, and key expirations are randomized to prevent avalanche effects. Additionally, a ducc switch can temporarily disable database access when load exceeds capacity, safeguarding the system during major promotions.

Conclusion

The article analyzes high‑concurrency call scenarios for JD Logistics’ Contract Center and proposes a layered technical solution. By combining Bloom filters, Redis caching, and controlled database access, the design reduces unnecessary database load, mitigates cache‑related issues, and maintains data consistency across the system.