Design and Refactoring of the Book Outbound Service with SN Allocation and Concurrency Management

The book business includes two scenarios: purchasing books and returning defective books, both requiring outbound processing. Each book is identified by an ISBN and a unique SN code, which serves as the actual inventory accounting unit; outbound processing matches SNs, packs items based on address and business type, and creates outbound orders via a central platform.

Business difficulties

1. Outbound requests currently lock the database on a per‑ISBN basis to fetch and reserve an SN, causing long wait times and timeouts under high concurrency.

2. Strict consistency is required across purchase records, SN occupancy, and outbound logs; any mismatch forces extensive manual investigation and data repair.

Refactoring directions

1. Separate outbound logic from purchase logic, allowing the outbound service to focus solely on inventory release while delegating business‑specific concerns back to the originating service.

2. Standardize the outbound API so that all outbound operations are invoked only through defined methods, preventing code intrusion.

3. Convert synchronous workflows into asynchronous steps, breaking each process into minimal units that transition from one state to the next while guaranteeing data consistency at each step.

SN allocation strategy

The initial design used modulo of ISBN to route matching to a single thread, achieving lock‑free matching. Subsequent iterations introduced asynchronous processing and data sharding, but revealed a risk of overselling when third‑party integrations waited for SN allocation after inventory deduction.

To address concurrency without locks, a Redis‑based solution was explored. A simple list caused blocking during initialization; switching to a Redis set eliminated duplicates and allowed atomic pop operations, but introduced race conditions when multiple threads initialized the set simultaneously.

The final solution employs two sets per ISBN: one "deduplication" set and one "consumption" set. An SN is popped from the consumption set only if it does not exist in the deduplication set, ensuring uniqueness without locking.

When the consumption set becomes empty, the deduplication set is cleaned up via a delayed‑queue mechanism; however, edge cases still exist where concurrent threads may re‑insert stale SNs.

Further refinement uses a Redis ZSET for deduplication and a delayed‑queue to purge stale entries after six minutes, while atomic layer calls remove the SN from the deduplication set upon successful processing.

After refactoring, outbound matching latency stabilized at a few milliseconds even for requests involving dozens of ISBNs, and the architecture now supports horizontal scaling.

Business architecture

State flow

Additional notes: after SN reservation, a confirmation API moves the SN to a "pending merge" state; outbound callbacks and cancellations involve complex branching logic; and merge‑job algorithms are omitted for brevity.

Other issues

Because the system must support both cancellation of outbound requests and re‑outbound after cancellation, repeated forward and reverse operations can cause race conditions where a retry of a cancelled job overwrites a later user‑initiated re‑outbound, potentially leading to inconsistent outcomes.

The article focuses on overall design thinking and SN matching implementation; other challenges will be documented in future posts.

Author

Jia Zhiwen, Open Business Technology Department, ZheZhe.