Đồng bộ Web ↔ Pancake — không bao giờ bán âm tồn kho, không bao giờ mất đơn
Bên em đã làm tích hợp Pancake cho nhiều khách thời trang & FMCG. Tồn kho 2 chiều realtime, chống race condition, khách tự tra cứu trạng thái giao hàng — tất cả built-in, không phải plugin gắn vội.
3 nỗi đau của shop bán đa kênh không đồng bộ đúng cách
Bán âm tồn kho khi sale
Web báo còn hàng, khách đặt thành công → Pancake báo hết hàng → shop phải gọi khách xin lỗi, hủy đơn, mất uy tín. Càng sale lớn càng tệ vì xác suất race condition cao.
Tồn kho lệch giữa Web và Pancake
Nhân viên chốt đơn trên Pancake không đồng bộ ngược về web → web vẫn hiển thị tồn cũ → khách đặt → lại lệch tiếp. Cuối tuần phải đối soát tay vài giờ.
Khách hỏi "đơn em tới đâu rồi?"
Mã vận đơn lưu trên Pancake nhưng web không biết. Khách gọi điện hỏi → tổng đài tra Pancake → trả lời. Vừa tốn người vừa làm khách bực, đặc biệt giờ cao điểm.
Defense-in-depth — 3 lớp đồng bộ, không tin vào một mình webhook
Webhook có thể mất. Network có thể chập. Pancake có thể bảo trì. Bên em build 3 lớp phòng ngự để dữ liệu không bao giờ lệch quá vài phút trong worst case.
Webhook real-time (primary)
~ vài giâyPancake cập nhật tồn kho → bắn webhook về website ngay. Website tạo đơn → bắn webhook ngược về Pancake. Webhook in/out đều có signature verification + idempotency check (lưu event_id 7 ngày tránh xử lý trùng), queue async để không block response.
REST polling fallback
mỗi 5 phút
Khi webhook fail (Pancake outage, network), website chủ động poll API Pancake mỗi 5 phút để check delta.
Có exponential backoff khi gặp lỗi. Cron tự kiểm tra last_webhook_received_at, nếu quá ngưỡng → kích hoạt polling.
Reconciliation cron (đối soát)
hàng đêm 02:00
Mỗi đêm: so sánh toàn bộ tồn kho Web vs Pancake. Lệch là log + alert + tự sync
(Pancake là source of truth). Mọi delta được lưu vào wp_stock_audit để truy vết
— lệch ở đâu, lúc nào, lệch bao nhiêu đều có audit log.
Reservation pattern — giữ chỗ tạm khi user bấm mua
Khi kho còn 1 sản phẩm và 2 bên cùng cố chốt, hệ thống xử lý theo timeline có thứ tự rõ ràng. Không có chuyện "tự xử lý" hay "may rủi".
- T0
Khách A vào trang sản phẩm
Tồn hiển thị 1. Chưa có ai chốt.
- T1
Khách A bấm "Mua ngay"
Website tạo reservation 15 phút trong DB transaction (
SELECT FOR UPDATErow-level lock InnoDB) + gọi Pancake reserve API. - T2
Khách B vào cùng sản phẩm
Tồn hiển thị 0 (vì A đã reserve). UI báo "Sản phẩm vừa hết" + recommend mẫu tương tự.
- T3
Nhân viên cố chốt Pancake cùng lúc
Pancake check stock = 0 → từ chối, báo "đang có khách online chốt". Pancake là source of truth cho tồn kho cuối.
- T4
Resolved
Nếu A hoàn tất: reservation chuyển thành confirmed order, Pancake nhận webhook → trừ tồn thật.
Nếu A bỏ giỏ: reservation TTL hết 15 phút → tồn về 1 → B hoặc nhân viên chốt được.
Khách tự tra cứu — tổng đài giảm 50-70% cuộc gọi "đơn em tới đâu rồi?"
Pancake
Nhận update từ GHN / GHTK / J&T / SPX qua API hoặc webhook.
Webhook về website
Endpoint /api/shipping-update nhận và lưu vào order meta (tracking code, carrier, status).
Khách tự tra cứu
Trang /tra-cuu-don-hang/ + email transactional + (optional) SMS / Zalo ZNS khi status đổi.
Câu hỏi thường gặp về tích hợp Pancake
Cơ chế đồng bộ tồn kho giữa Website và Pancake hoạt động ra sao?
Bên em dùng kiến trúc 3 lớp: webhook real-time làm chính (độ trễ vài giây), REST polling fallback khi webhook fail, và reconciliation cron đối soát hàng đêm. Không phụ thuộc vào một cơ chế đơn lẻ — webhook có thể mất, polling có thể chậm, nhưng kết hợp 3 lớp đảm bảo dữ liệu không lệch quá vài phút trong worst case.
Pancake luôn là source of truth cho tồn kho cuối — vì đó là nơi nhân viên thao tác tay nhiều. Website chỉ "giữ chỗ tạm" qua reservation pattern, không trừ tồn thật cho đến khi đơn confirm.
Nếu kho còn 1, khách đặt trên web và nhân viên chốt Pancake cùng lúc thì sao?
Bên em chống bán âm bằng reservation pattern. Khi khách add to cart hoặc bắt đầu checkout, website tạo reservation 15 phút trong DB transaction với row-level lock + gọi Pancake reserve API. Nhân viên cố chốt Pancake cùng lúc sẽ thấy stock = 0, được báo "đang có khách online chốt" → thao tác bị block.
Nếu Pancake không hỗ trợ reserve API (tùy phiên bản), bên em có thể giảm risk window xuống vài giây nhưng không thể về 0% tuyệt đối — bên em nói thẳng điều này thay vì hứa suông. Trong thực tế lượng race condition đến mức này rất hiếm; khi xảy ra hệ thống refuse đơn đến sau với HTTP 409 + tự động recommend sản phẩm tương tự cho khách.
Khách có tự tra cứu được trạng thái giao hàng từ website không?
Có. Pancake bắn webhook khi đơn vị vận chuyển update status (đã giao ĐVVC, đang giao, đã giao thành công, hoàn hàng) → website nhận và lưu vào order meta. Khách vào trang /tra-cuu-don-hang/, nhập SĐT + mã đơn, xem timeline trực quan. Đồng thời mỗi status đổi sẽ tự trigger email cho khách — giảm tải tổng đài shop đáng kể.
Fallback: nếu Pancake chưa kịp bắn webhook, website có thể gọi trực tiếp API ĐVVC (GHN, GHTK có public API) bằng tracking code đã lưu trong order, đảm bảo khách luôn có thông tin mới nhất.