Hi everyone — I’m a Shopify app developer and I’d like to raise an issue that feels like an unintentional “friendly DDoS” caused by the current webhook behavior around GDPR redaction events.
In normal conditions (including peak periods like Black Friday), my app handles Shopify traffic reliably. However, when a merchant performs a large bulk action on customers (e.g., deleting tens of thousands of customer records), Shopify appears to immediately fan out customer/redact requests to every connected app for each customer. This can create an avalanche of webhook deliveries in a very short time window.
A real example: on January 23, one merchant deleted 80,000+ customers over a couple of hours. Right after that, my app became overwhelmed and effectively got stuck trying to process the backlog. Nearly all of those customer/redact payloads were effectively identical, and importantly the orders_to_redact field was null or [] (no orders to redact).
This seems like an ecosystem-level scalability problem: bulk operations by one merchant can generate an extreme webhook burst to apps, even when there is no actionable data beyond the customer record itself.
Suggestion / request for Shopify to review policy and delivery behavior:
Do not send customer/redact when orders_to_redact is null or [], since there are no orders requiring redaction.
Alternatively (or additionally), introduce batching, backpressure, or stronger throttling/queuing guarantees for these GDPR-related webhooks when bulk operations occur, so apps aren’t forced into overload conditions.
Has anyone else seen this behavior? And is there a recommended best practice on the app side beyond building a large queue + aggressive rate limiting to survive extreme bursts like this?
Thanks in advance — I’d really like to hear Shopify’s guidance here, because this can take down otherwise healthy apps during rare bulk delete events.
Yikes, that’s a lot to deal with. It does seem like something Shopify could better address at the platform level, but for app-side work arounds the queue + rate-limiting approach you mentioned seems like the right approach. I’d add:
Early exit for no-op payloads - If orders_to_redact is null or [] then exit immediately after a quick check.
Separate queues by priority - Route the GDPR webhooks to a dedicated queue with its own worker pool, so they don’t starve your order webhooks or other time-sensitive operations.
Queue isolation / priority
GDPR webhooks are already routed to a separate, non-priority queue on our side, so they don’t block higher-priority work. The problem is the avalanche itself: at peak it was on the order of ~1,000 requests/minute (and sustained). That may not sound huge for a large-scale system, but for a typical Shopify app stack it’s enough to saturate Redis and spike CPU (we saw both).
Yes, we could provision a much bigger VM / Redis tier, but this happens only a couple times — so it becomes paying for peak capacity that sits idle 99% of the time, which is hard to justify.
Early exit for no-op payloads
We already implemented an early return when orders_to_redact is null or []. It helps, but it’s still not “free” — the app still has to accept the request, parse/deserialize the body, run middleware/auth checks/logging, and then respond. When you multiply that overhead by sustained bursts (10+ TPS and above), it adds up quickly.
That’s why I think the ideal fix is platform-side: if there are no orders to redact, don’t fan out customer/redact at all (or provide a batched / rate-limited delivery mechanism for extreme bulk events). It would reduce load not just for apps, but for Shopify infrastructure too.
Also, from a docs/compliance perspective, it’s a bit unclear what the intended action is when orders_to_redact is empty — if there’s nothing to clean up in orders, why force every app to process a webhook that becomes a no-op?
It’s important to remember that other apps may have different data and use cases. For example, apps may have actual customer account data that needs to be redacted, even if no orders exist for that customer.
Shopify’s recommendation for making sure you can handle large webhooks loads is to use Amazon EventBridge or Google PubSub so it may be worth looking into a solution like that if you’re not already doing so. You could also look into if there are any options for your system to be able to auto-scale up and back down when these sort of peaks come in so that you can handle them without having to stay at peak capacity full time.
It’s definitely possible that there’s a platform improvement that could be made here, maybe some sort of rate-limiting, but with the legal liabilities involved here it’s really best for both Shopify and app developers to over-scope things rather than pigeon hole or accommodate edge case exceptions.
Totally fair point — and sorry about that. I honestly didn’t fully consider that it’s not just orders referencing the customer, but the customer profile itself that must be redacted. What you’re saying makes complete sense, and I fully agree.
From a scalability standpoint, building in stronger throttling/queuing is also a valid solution, and I’ve already started some preparations in that direction. That said, this is really something we’d only need for customers/redact. It will introduce additional cost/overhead either way, and it wasn’t something we had planned for the near future, since we typically handle other webhooks with plenty of spare capacity.