Tự động đẩy vận đơn, in phiếu gửi hàng loạt và đồng bộ trạng thái giao nhận qua Webhook

Kiến trúc đẩy vận đơn tự động và xử lý hàng loạt qua hàng đợi bất đồng bộ (Message Queue)

Trong các đợt cao điểm khuyến mãi hoặc Flash Sale, website thương mại điện tử có thể ghi nhận hàng trăm đến hàng nghìn đơn hàng cần xuất kho chỉ trong vài giờ. Nếu nhân viên kho tích chọn 200 đơn hàng và bấm nút “Đẩy sang đơn vị vận chuyển”, việc thực hiện 200 cuộc gọi API tuần tự trong cùng một luồng HTTP Request sẽ dẫn đến lỗi quá thời gian chờ (504 Gateway Timeout) hoặc bị máy chủ của hãng vận chuyển chặn truy cập do vượt ngưỡng giới hạn tần suất (Rate Limiting).

Để xử lý trơn tru bài toán này, kiến trúc Backend sử dụng hệ thống hàng đợi tin nhắn (Message Queue như BullMQ, RabbitMQ hoặc Redis Streams). Khi quản trị viên kích hoạt lệnh đẩy đơn hàng loạt — hoặc khi hệ thống cấu hình tự động đẩy đơn ngay sau khi cổng thanh toán báo thu tiền thành công — máy chủ lập tức tạo một tác vụ nền (Background Batch Job), trả về mã tiến trình cho giao diện quản trị và hiển thị thanh tiến độ theo thời gian thực qua kết nối WebSocket hoặc Server-Sent Events (SSE).

Các tiến trình xử lý ngầm (Worker Nodes) sẽ lấy từng lô đơn hàng ra khỏi hàng đợi, áp dụng bộ điều tiết tốc độ (Token Bucket Rate Limiter) khớp với hạn mức API của từng đối tác vận chuyển (ví dụ tối đa 20 yêu cầu mỗi giây). Đặc biệt, mỗi yêu cầu tạo vận đơn đều đính kèm khóa chống trùng lặp (Idempotency-Key sinh từ mã đơn hàng nội bộ và lần tạo) để phòng trường hợp mạng chập chờn phải gửi lại yêu cầu thì hãng vận chuyển cũng không sinh ra hai mã vận đơn trùng lặp cho cùng một đơn hàng.

• Kiểm tra hợp lệ trước khi đẩy (Pre-dispatch Validation): tự động rà soát độ dài số điện thoại, tính đầy đủ của mã phường, xã, trọng lượng tối thiểu và hạn mức tiền thu hộ COD trước khi đưa vào hàng đợi.
• Cơ chế thử lại thông minh (Exponential Backoff Retry): nếu API hãng giao vận tạm thời báo lỗi máy chủ bận, Worker tự động xếp lịch thử lại sau 10 giây, 30 giây và 2 phút mà không cần nhân viên can thiệp.
• Phân tách kết quả lô (Partial Batch Success): trong 100 đơn đẩy đi, nếu 97 đơn thành công và 3 đơn lỗi do sai địa chỉ, hệ thống vẫn xuất mã vận đơn cho 97 đơn để kho đóng gói trước và gom riêng 3 đơn lỗi kèm thông báo nguyên nhân rõ ràng.
• Hỗ trợ quy tắc tự động chọn hãng vận chuyển theo kịch bản định sẵn (Auto-carrier Assignment) dựa trên khu vực nhận hàng và loại sản phẩm trong đơn.

Vuốt ngang để xem đủ bảng →

Kiến trúc cổng nhận tín hiệu Webhook đồng bộ trạng thái giao nhận theo thời gian thực

Ngay khi kiện hàng rời khỏi kho và được bưu tá quét nhận, vòng đời của đơn hàng chuyển sang giai đoạn vận chuyển ngoài hệ thống. Để khách hàng và bộ phận chăm sóc khách hàng trên website nắm bắt chính xác kiện hàng đang ở trạm trung chuyển nào, bưu tá nào đang đi giao hay đơn hàng gặp sự cố khách hẹn lại ngày nhận, website cần thiết lập các điểm cuối nhận tín hiệu (Webhook Endpoints) mở kết nối 24/7 cho máy chủ của các hãng vận chuyển gọi vào.

Một kiến trúc Webhook đạt chuẩn công nghiệp bắt buộc phải tuân thủ nguyên tắc “Xác thực nhanh – Ghi nhận tức thời – Xử lý bất đồng bộ” (Verify, Acknowledge, Process Async). Khi hãng vận chuyển bắn một gói tin JSON báo thay đổi trạng thái vào đường dẫn /api/webhooks/shipping/{carrier}, máy chủ website trước tiên kiểm tra chữ ký bảo mật HMAC-SHA256 hoặc Token trong Header để xác nhận gói tin thực sự xuất phát từ đối tác hợp lệ, ngăn chặn tấn công giả mạo trạng thái đã giao hàng.

Ngay sau bước xác thực chữ ký, hệ thống lưu nguyên bản gói tin (Raw Payload) vào bảng nhật ký shipping_webhook_logs, đẩy sự kiện vào hàng đợi nội bộ và lập tức trả về mã phản hồi HTTP 200 OK trong vòng dưới 100 mili giây. Tuyệt đối không thực hiện các tác vụ nặng như gửi email, gửi tin nhắn thông báo cho khách, cộng điểm thưởng thành viên hay hạch toán kế toán ngay trong luồng nhận Webhook, bởi nếu xử lý chậm quá 3 giây, máy chủ hãng vận chuyển sẽ coi như gửi thất bại và bắn lặp lại gói tin đó nhiều lần.

• Chuẩn hóa bảng ánh xạ trạng thái (Status Mapping State Machine): quy đổi hàng chục mã trạng thái chi tiết của các hãng khác nhau về 8 trạng thái chuẩn của website (Chờ lấy hàng, Đã lấy hàng, Đang trung chuyển, Đang giao hàng, Giao thành công, Giao thất bại - Chờ giao lại, Duyệt hoàn, Đã trả hàng về kho).
• Kiểm soát thứ tự sự kiện (Out-of-order Event Handling): trong môi trường mạng phân tán, gói tin “Đã lấy hàng” đôi khi đến sau gói tin “Đang trung chuyển” vài giây; bộ máy trạng thái (State Machine) phải dựa vào dấu thời gian thực tế (event_timestamp) và cấp độ ưu tiên trạng thái để không ghi đè lùi trạng thái đơn hàng.
• Tự động kích hoạt thông báo đa kênh: khi trạng thái chuyển sang “Đang giao hàng” hoặc “Giao thành công”, Worker nền tự động gửi thông báo đẩy hoặc tin nhắn kèm thông tin liên hệ của bưu tá cho người mua.
• Chạy tác vụ đối chiếu bù (Reconciliation Polling Cronjob) mỗi 6 giờ một lần cho các vận đơn đang nằm ở trạng thái trung gian quá 48 giờ mà không nhận được Webhook mới, phòng trường hợp đứt kết nối mạng tạm thời.