Giới hạn API của Shopify: Quản lý nhiều cửa hàng
Cách hiểu giới hạn tần suất gọi (rate limit) của Shopify REST và GraphQL API khi vận hành nhiều cửa hàng, bao gồm cơ chế leaky bucket, mô hình chi phí truy vấn và các chiến lược tránh bị throttling.
Vận hành nhiều cửa hàng Shopify từ một nền tảng duy nhất tạo ra một thách thức rất riêng: bạn không chỉ chạm đến giới hạn API của một cửa hàng, mà còn dồn áp lực rate-limit lên hàng chục, thậm chí hàng trăm cửa hàng cùng lúc. Hiểu rõ cách các hệ thống giới hạn tần suất gọi API của Shopify hoạt động — và cách chúng cộng dồn khi bạn quản lý nhiều cửa hàng — là điều thiết yếu để giữ cho đơn hàng chảy đều, tồn kho đồng bộ và mọi vận hành trơn tru.
Cơ chế giới hạn của REST API Shopify
REST Admin API của Shopify dùng thuật toán leaky bucket (xô rò rỉ) để quản lý dung lượng request. Hãy hình dung nó như một chiếc xô: mỗi lần gọi API là đổ thêm nước vào, và nước rò ra ngoài đều đặn theo thời gian.
Cơ chế cụ thể như sau:
- Dung tích xô: Gói tiêu chuẩn được cấp một xô chứa 40 request cho mỗi app trên mỗi cửa hàng. Tài khoản Shopify Plus được 400 (gấp 10 lần).
- Tốc độ rò: Request thoát khỏi xô theo tốc độ cố định — 2 request mỗi giây với gói tiêu chuẩn, hoặc 20 request mỗi giây với gói Plus.
- Cho phép gọi dồn (burst): Nếu bạn gọi chậm rãi và xô gần như đang rỗng, bạn có thể gọi dồn một lúc tối đa 40 request mà không chạm giới hạn, vì xô vẫn còn chỗ trống. Khi xô đầy, bạn sẽ nhận lỗi
429 Too Many Requests.
Shopify trả về header X-Shopify-Shop-Api-Call-Limit: 32/40 trong phản hồi, cho biết mức sử dụng hiện tại so với dung lượng còn lại.
Vấn đề khi có nhiều cửa hàng: Khi quản lý 30 cửa hàng, bạn có 30 chiếc xô riêng biệt — mỗi cửa hàng một xô cho mỗi app. Nếu các worker chạy nền của bạn đồng thời đồng bộ tồn kho, kéo đơn hàng hay cập nhật sản phẩm trên cả 30 cửa hàng, bạn có thể làm cạn cả 30 chiếc xô cùng lúc và bị throttling trên toàn bộ hệ thống, dù từng cửa hàng vẫn nằm trong giới hạn riêng của nó.
GraphQL Admin API: Giới hạn dựa trên chi phí truy vấn
GraphQL Admin API của Shopify dùng một mô hình khác: chi phí truy vấn (query cost). Thay vì đếm từng request riêng lẻ, mỗi truy vấn được gán một mức chi phí dựa trên độ phức tạp và lượng dữ liệu mà nó yêu cầu.
Nguyên tắc cơ bản của mô hình chi phí:
- Mỗi field trong GraphQL schema có một giá trị chi phí là số nguyên.
- Field kiểu vô hướng (như chuỗi hoặc số) tốn 0; field kiểu object tốn 1; field kiểu connection (danh sách) tốn nhiều hơn tùy theo số bản ghi bạn yêu cầu.
- App của bạn được cấp một lượng điểm mỗi giây, chia thành xô riêng cho từng cửa hàng giống như REST.
Giới hạn theo từng gói:
- Gói tiêu chuẩn: 100 điểm mỗi giây
- Advanced Shopify: 200 điểm mỗi giây
- Shopify Plus: 1000 điểm mỗi giây
Một truy vấn đơn lẻ không thể vượt quá 1.000 điểm, bất kể bạn đang dùng gói nào. Sau khi truy vấn chạy xong, Shopify tính lại chi phí thực tế và hoàn lại số điểm chưa dùng vào xô của bạn.
Vì sao điều này quan trọng với app đa cửa hàng: Một truy vấn tốn 50 điểm ở cửa hàng này thì vẫn tốn 50 điểm ở cửa hàng khác. Nếu bạn chạy cùng một bộ báo cáo, đồng bộ hay thao tác hàng loạt trên 20 cửa hàng, bạn sẽ ngốn hết lượng điểm mỗi giây rất nhanh. Với số điểm hạn chế, bạn buộc phải hoặc điều tiết request, hoặc trải đều chúng theo thời gian, hoặc dùng bulk operations để bỏ qua hoàn toàn giới hạn của từng truy vấn.
Bulk Operations: Lối thoát khỏi giới hạn rate-limit
Bulk operations được thiết kế để xử lý khối lượng dữ liệu lớn mà không chạm trần chi phí của một truy vấn đơn lẻ. Chúng không bị tính vào giới hạn rate-limit mỗi giây theo cách thông thường — thay vào đó, chúng được xếp hàng xử lý bất đồng bộ và chạy ngầm ở chế độ nền.
Từ phiên bản API 2026-01, bạn có thể chạy tối đa năm bulk mutation đồng thời trên mỗi cửa hàng. Trước 2026, bạn chỉ chạy được một thao tác mỗi lần. Đây là thay đổi đáng kể cho người vận hành nhiều cửa hàng: bạn có thể xếp hàng các tác vụ cập nhật, đồng bộ hay nhập dữ liệu hàng loạt trên nhiều cửa hàng mà không phải xử lý tuần tự từng cái một.
Bulk operations phải hoàn tất trong vòng 10 ngày. Nếu bạn đang đồng bộ sản phẩm, khách hàng hay đơn hàng trên hàng chục cửa hàng, bulk operations cho phép bạn bắn request đi mà không phải lo bị rate-limit phản đòn ngay lập tức.
Thách thức thực tế khi quản lý nhiều cửa hàng và cách giải quyết
Khi bạn vận hành một nền tảng quản lý 10, 50 hay thậm chí 150 cửa hàng, giới hạn API trở thành nút thắt cổ chai trong vận hành. Lý do là:
Vấn đề tải tích lũy: 30 worker chạy nền cùng gọi API Shopify song song trên 30 cửa hàng có thể làm cạn toàn bộ hạn mức gần như ngay tức khắc. Một worker cho mỗi cửa hàng, mỗi cái kéo đơn hàng hoặc đồng bộ tồn kho, cộng lại là 30 request trải trên 30 chiếc xô riêng biệt. Nếu xét riêng lẻ thì không sao. Nhưng khi cần phối hợp xuyên cửa hàng — kéo đơn từ cả 30, rồi cập nhật tồn kho trên cả 30, rồi đẩy sang hệ thống vận hành của bạn — thì cần điều phối rất cẩn thận.
Giải pháp: Triển khai một hệ thống backoff và hàng đợi (queue). Khi hạn mức API của một cửa hàng cạn kiệt:
- Ngừng gọi đến cửa hàng đó trong vài giây.
- Điều hướng worker sang các cửa hàng khác mà xô vẫn còn dung lượng.
- Tiếp tục hàng đợi của cửa hàng đó khi xô leaky bucket đã rò bớt đủ để nhận request mới.
Ngoài ra, hãy cân nhắc:
- Gom theo từng cửa hàng, đừng gom toàn cục: Xử lý trọn vẹn việc đồng bộ của một cửa hàng (đơn hàng, tồn kho, khách hàng) rồi mới chuyển sang cửa hàng tiếp theo, thay vì cố đồng bộ tất cả cửa hàng song song.
- Tận dụng caching triệt để: Nếu bạn lấy dữ liệu khách hàng hoặc sản phẩm nhiều lần trong mỗi chu kỳ đồng bộ, hãy cache cục bộ trong vài phút hoặc vài giờ thay vì liên tục gọi API.
- Tối ưu truy vấn: Với GraphQL, chỉ yêu cầu đúng những field bạn thực sự cần. Mỗi field đều cộng thêm chi phí. Với REST, dùng bộ lọc tài nguyên và giới hạn phân trang để giảm dung lượng phản hồi.
Chọn REST hay GraphQL cho vận hành đa cửa hàng
REST API đơn giản hơn để hiểu và triển khai. Cơ chế xô và tốc độ rò dễ dự đoán. Nó phù hợp với những thao tác đơn giản, nhẹ nhàng như kéo đơn hàng hoặc cập nhật trạng thái đơn.
GraphQL linh hoạt hơn và cho phép bạn lấy đúng những gì cần trong một request duy nhất. Truy vấn phức tạp có thể giảm số lần phải đi vòng (round-trip). Tuy nhiên, chi phí truy vấn đòi hỏi bạn phải lên kế hoạch và kiểm thử kỹ hơn để tránh bất ngờ.
Với nền tảng đa cửa hàng, GraphQL thường thắng thế vì bạn có thể lấy dữ liệu liên quan (đơn hàng, dòng sản phẩm, thông tin khách hàng) trong một truy vấn duy nhất thay vì phải gọi REST ba lần. Một truy vấn GraphQL được tối ưu tốt có thể tốn chi phí ngang ba request REST nhưng hoàn tất nhanh hơn và sử dụng hạn mức của bạn một cách dễ dự đoán hơn.
Vì sao điều này quan trọng với người dùng StoreFleet
StoreFleet quản lý toàn bộ hoạt động đa cửa hàng của bạn từ một dashboard duy nhất — đơn hàng, doanh thu, vận chuyển và tài chính trên tất cả cửa hàng. Để làm được điều đó một cách đáng tin cậy, chúng tôi đã xây dựng các API có nhận thức về rate-limit, giúp:
- Xếp hàng request xuyên cửa hàng để tránh làm cạn xô của bất kỳ cửa hàng nào.
- Dùng GraphQL và bulk operations để giảm thiểu số lần gọi API cho mỗi lần đồng bộ.
- Gom thao tác một cách thông minh để bạn thấy dữ liệu thời gian thực mà không bị throttling.
Nếu bạn đang quản lý 10 cửa hàng theo cách thủ công trong các tab Shopify admin riêng biệt, bạn đang tự nhân lên độ phức tạp trong vận hành của mình. Một nền tảng đa cửa hàng hợp nhất sẽ lo việc điều phối rate-limit thay cho bạn, để bạn tập trung phát triển cửa hàng thay vì gỡ lỗi API.
Muốn xem cách StoreFleet xử lý rate-limit và đồng bộ trên các cửa hàng của bạn? Dùng thử bản demo miễn phí ngay trên tài khoản Shopify của chính bạn. Chỉ cần liên hệ qua [email protected] hoặc đặt lịch demo trên trang chủ của chúng tôi.