Tồn kho hiển thị trên website không luôn bằng dữ liệu đang có trong kho vận hành. Một số sản phẩm có lượng đã giữ cho đơn, hàng đang chuyển hoặc cập nhật chưa tới hệ thống bán. Với cửa hàng và đối tác được cấp quyền, giải pháp theo dõi cần API hoặc webhook làm nguồn rõ ràng. Proxy chỉ được thêm khi kiến trúc mạng yêu cầu, không phải để săn hàng hoặc đi vòng giới hạn mua.
Xác định câu hỏi và đơn vị theo dõi
Trước khi viết bộ kiểm tra, chọn trạng thái cần biết: còn khả dụng để bán, lượng vật lý trong kho hay hàng đang chuyển. Gắn mỗi quan sát với mã hàng hoặc ID biến thể, ID kho và thời điểm nguồn cập nhật. Một SKU có thể xuất hiện ở nhiều kho; cộng mọi con số mà không hiểu ý nghĩa dễ làm cảnh báo sai. Cũng cần xác định ai xử lý cảnh báo và độ trễ chấp nhận được trong nghiệp vụ.
Vai trò của API, webhook và Proxy
API phù hợp để lấy trạng thái hiện tại hoặc đối soát, còn webhook thông báo sự kiện khi nhà cung cấp hỗ trợ. Ví dụ, API inventoryItem của Shopify cung cấp dữ liệu liên quan mặt hàng tồn kho và yêu cầu quyền phù hợp. Proxy có thể cung cấp tuyến đầu ra đã thỏa thuận hoặc hỗ trợ QA khả năng truy cập; nó không cấp quyền đọc kho, không làm dữ liệu tự đồng bộ và không biến một lần đọc thành cam kết còn hàng lúc mua.
Kiến trúc đề xuất: sự kiện cộng đối soát
Dùng một bộ nhận webhook, hàng đợi xử lý, kho trạng thái quan sát và công việc đối soát định kỳ. Mỗi bản ghi có nguồn, đối tượng, thời gian nguồn, thời gian nhận và trạng thái độ mới. Bộ nhận kiểm tra tính hợp lệ trước khi đưa sự kiện vào hàng đợi. Worker cập nhật theo quy tắc đã duyệt; nếu không xác định được thứ tự, lấy lại trạng thái hiện tại từ API thay vì áp dụng mù một sự kiện cũ.
Các bước triển khai với quyền tối thiểu
- Xin phạm vi đọc cần thiết cho cửa hàng hoặc nguồn đối tác, ghi endpoint và hạn mức.
- Ánh xạ SKU, biến thể và kho bằng định danh ổn định, không dựa riêng vào tên sản phẩm.
- Chụp trạng thái ban đầu qua API và lưu thời gian quan sát.
- Đăng ký webhook được nguồn hỗ trợ, xác thực trước khi xử lý và lưu mã chống trùng.
- Thêm công việc đối soát để phát hiện sự kiện bị bỏ lỡ hoặc trạng thái không còn mới.
- Thử các ca dữ liệu trùng, đến chậm và lỗi mạng trong môi trường thử.
Hướng dẫn xác minh webhook của Shopify nêu việc kiểm tra HMAC trên body thô và khả năng nhận lại cùng một webhook. Khi tích hợp nguồn khác, dùng cơ chế xác thực và định danh do nguồn đó quy định, không sao chép tên header sang mọi API.
Ví dụ giả định: cảnh báo hết hàng nhưng sự kiện đến trễ
Giả sử cửa hàng quản lý một mặt hàng tại hai kho. Hệ thống nhận sự kiện “hết khả dụng” của kho thứ nhất sau sự kiện nhập thêm hàng. Nếu ghi đè theo thứ tự nhận, dashboard có thể báo sai. Nhóm xử lý lưu cả thời gian nguồn và thời gian nhận, kiểm tra phiên bản khi nguồn hỗ trợ, rồi đối soát API lúc có mâu thuẫn. Thông báo chỉ được gửi sau bước xác nhận; không có đặt hàng tự động hay giữ hàng cho tài khoản thử.
Đo độ tin cậy thay vì chỉ đo số request
- Độ trễ từ cập nhật nguồn tới trạng thái quan sát.
- Tỷ lệ SKU và kho có dữ liệu còn trong ngưỡng độ mới.
- Số sự kiện trùng được bỏ qua, số mâu thuẫn được đối soát.
- Tỷ lệ lỗi quyền, lỗi giới hạn và công việc không hoàn thành.
- Số cảnh báo đúng sau khi nhân viên xác minh với nguồn.
Tiêu chí đạt cần gắn với nhu cầu cửa hàng. Một nguồn cập nhật theo lô không thể được quảng bá là thời gian thực chỉ vì hệ thống kiểm tra liên tục. Khi quá ngưỡng độ mới, hiển thị trạng thái “dữ liệu cũ” cùng lần cập nhật cuối, không suy ra lượng hàng bằng không.
Giới hạn, bảo mật và xử lý lỗi mạng
Giữ token ở máy chủ, phân quyền đọc và không ghi body chứa dữ liệu khách vào log không cần thiết. Đặt giới hạn worker, timeout và retry có ngân sách; tôn trọng Retry-After khi được nguồn gửi. Xem thêm cách quản lý retry. Nếu cần IP allowlist, xác nhận IP đầu ra thực tế với chủ API trước khi vận hành, không đổi IP để tránh hạn mức.
Câu hỏi thường gặp
Webhook có đủ để bỏ hoàn toàn việc đọc API không?
Không nên mặc định. Cần cơ chế phục hồi khi sự kiện bị bỏ lỡ, dữ liệu cũ hoặc logic xử lý lỗi. Đối soát theo hạn mức là lớp kiểm tra bổ sung.
Thấy còn hàng qua API thì có bảo đảm mua được không?
Không. Kết quả là quan sát tại một thời điểm; lượng khả dụng có thể thay đổi. Việc mua và giữ hàng phải theo quy trình của cửa hàng, không theo suy đoán của bộ theo dõi.
Kết luận
Giải pháp tồn kho tốt giữ đúng định danh, độ mới và nguồn dữ liệu, đồng thời xử lý trùng và đối soát. Chỉ thêm Proxy khi có yêu cầu mạng cụ thể; độ tin cậy không đến từ việc tăng số IP.