Designing a Modular Retail POS System with Offline Synchronization and Search

Facing the challenges of offline cash‑register scenarios, the retail POS business needs to improve merchant checkout efficiency, guarantee operation under weak or no network, design a scalable product search solution, and decouple complex business modules.

The Youzan Retail Mobile team distilled a practical solution for product checkout through modular design, offline data handling, and integrated hardware support.

1. Modular Design

Leveraging a component‑based framework, the system splits the business into store, transaction, product, and marketing modules. Routing handles page navigation and component communication, while the product module encapsulates its own data and provides a query interface.

2. Offline Product Data

Product information is stored locally on the client, enabling checkout even without network connectivity. The solution supports pinyin‑based fuzzy search and barcode scanning via devices such as scanners and electronic scales.

3. Database Splitting

Initially, multiple business lines shared a local database accessed directly via DAO classes, causing tight coupling. The redesign separates databases per business line, provides a unified data‑access entry for each module, and uses routing to invoke methods.

After splitting:

Each database has a single responsibility, reducing coupling.

The product module becomes the unified entry for product data across business lines.

Changes in product or underlying data no longer affect other modules.

Modules exchange data via JSON or agreed‑upon protocols.

4. Offline Synchronization Design

Key requirements for the sync mechanism include minimal data transfer, trigger on network reconnection, simplicity, real‑time server‑to‑client updates, and data consistency.

Incremental sync is chosen over full sync to reduce bandwidth and latency. The sync process follows a single‑task model to avoid concurrency issues:

Client reads the latest local sync timestamp and requests incremental data from the server.

Server returns the incremental payload.

Client compares timestamps to determine if it already has the latest data.

If not up‑to‑date, the client repeats the incremental pull.

When a product is added, updated, or deleted, the backend sends a lightweight message ("light message") to the client, which parses the business type and triggers the appropriate sync task.

5. Pinyin Conversion for Product Search

Accurate Chinese‑to‑pinyin conversion is essential for fuzzy search. Existing libraries (Pinyin4J on Android, iOS API) have inconsistencies (e.g., "女" → "nv" vs "nu") and lack multi‑tone support. The team adopts a JavaScript engine (V8/JSCore) to implement a cross‑platform solution, ensuring consistent results across iOS and Android.

Sample pinyin table entries:

dict[0x96f6] = "ling";   /* 零 */

dict[0x91cd] = "zhong,chong";   /* 重 */

Multi‑tone characters are stored without tone marks; the search logic ignores tones. For multi‑tone words, a Cartesian product approach generates all possible pinyin combinations, with a length threshold to avoid excessive search strings.

6. Product Fuzzy Search

Search matches product pinyin, pinyin initials, or barcode. A simplified SQL query illustrates the approach:

SELECT title, price, code, pinyin, pinyinletter
FROM goods
WHERE pinyin LIKE '%xx%'
   OR pinyinletter LIKE '%xx%'
   OR code LIKE '%xx%'
   AND shopid = '店铺id'
ORDER BY 'sortName'
OFFSET 'pageNo' LIMIT 'pageSize';

Barcode scanning uses exact matching, supporting one‑product‑multiple‑codes ("one product, many codes"). If a scanned code is not found locally, the client falls back to a server request with a 2‑second timeout; offline it shows a "product not found" message.

7. Marketing Integration

The product, checkout, and marketing modules are decoupled. Data flows are:

Marketing → Product: marketing parameters are passed to the product page, which fetches remote data.

Product → Checkout: selected product data, possibly enriched with marketing info, is sent to the checkout cart.

Checkout → Marketing: checkout requests marketing calculations if needed and assembles the final cart model.

When marketing requests store‑product data that is not yet synced offline, the system fetches it from the server, stores it locally, and then returns it to the marketing module.

8. Outlook

After two years of iteration, the core POS modules now cover offline product management and checkout. Future work focuses on rapid business iteration while maintaining core stability, improving merchant efficiency, and enhancing logging for faster issue response.