Giới hạn API của Shopify: Quản lý nhiều cửa hàng
Shopify Admin API rate limit hoạt động ra sao trên nhiều store: cơ chế leaky bucket, chi phí truy vấn GraphQL và cách tránh throttling.
Điểm chính — AI tóm tắt
- REST API của Shopify dùng mô hình leaky bucket theo từng store, từng app — gói tiêu chuẩn có xô 40 request rò ở tốc độ 2 request/giây, gói Plus có xô 400 rò ở tốc độ 20 request/giây
- GraphQL dùng giới hạn theo chi phí truy vấn (100 điểm/giây gói tiêu chuẩn, 200 Advanced, 1000 Plus), một truy vấn tối đa 1.000 điểm và điểm chưa dùng được hoàn lại sau mỗi lần chạy
- Chạy cùng một đợt đồng bộ trên nhiều store làm áp lực nhân lên — 30 worker chạy song song trên 30 store có thể làm cạn hết các xô cùng lúc, dù mỗi store riêng lẻ vẫn nằm trong giới hạn của nó
- Bulk operations bỏ qua trần chi phí mỗi truy vấn và, từ phiên bản API 2026-01, cho chạy tối đa năm bulk mutation đồng thời trên mỗi store (trước 2026 chỉ một), nhưng phải hoàn tất trong vòng 10 ngày
- Khắc phục throttling đa store bằng hệ thống backoff-và-hàng-đợi: tạm ngừng gọi store đã cạn xô, điều worker sang store còn dung lượng, gom theo từng store thay vì toàn cục, cache triệt để, và ưu tiên GraphQL khi cần nhiều field vì nó thường thay được nhiều lệnh REST với chi phí tương đương
AI tổng hợp từ chính nội dung bài viết; tác giả đã soát lại.
Trong bài này
- Shopify Admin API Rate Limit hoạt động ra sao: Chiếc xô Leaky Bucket
- Shopify GraphQL Rate Limit: Một chiếc xô Leaky Bucket tính theo chi phí
- Bulk Operations: Lối thoát khỏi giới hạn rate-limit
- Thách thức thực tế khi quản lý nhiều cửa hàng và cách giải quyết
- Chọn REST hay GraphQL cho vận hành đa cửa hàng
- Vì sao điều này quan trọng khi một công cụ nói chuyện với mọi store
- Nguồn
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 Shopify Admin API rate limit thực sự vận hành — chiếc xô leaky bucket của REST, mô hình chi phí truy vấn (cost) của GraphQL, và cách cả hai 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.
Shopify Admin API Rate Limit hoạt động ra sao: Chiếc xô Leaky Bucket
REST Admin API rate limit 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ó.
Shopify GraphQL Rate Limit: Một chiếc xô Leaky Bucket tính theo chi phí
GraphQL Admin API rate limit 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. Bên dưới nó vẫn là một chiếc xô leaky bucket — chỉ khác là xô của GraphQL chứa điểm (points) thay vì request, và được nạp lại đều đặn theo từng giây.
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, rò dần khỏi một xô điểm riêng của từng cửa hàng, y hệt cách request rò khỏi xô ở 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 khi một công cụ nói chuyện với mọi store
Một công cụ quản lý toàn bộ hoạt động đa cửa hàng 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.