Skip to main content
Linking integrations to operations

How HC handles high-volume events

How HC scales during peak trading periods, and what to do to prepare for flash sales, launches, and seasonal spikes.

The short answer

Every HC customer runs on an isolated event queue, and HC adds processing capacity automatically as that queue deepens, so a spike in your order volume is contained and handled without you raising a ticket. Most delays during high-volume periods come from the systems HC posts into, such as ERP rate limits and WMS import queues, not from HC's queue. HC respects those limits, retries automatically with a backoff strategy and never drops an event: everything either succeeds or appears in the failed events list.

How it works

Dedicated per-customer queues

Every HC customer runs on an isolated event queue. A surge in one customer's order volume has no effect on processing for any other customer. If your Black Friday traffic spikes, that pressure is contained entirely within your queue.

Automatic scaling

HC scales horizontally in response to queue depth. As event volume increases, additional processing capacity is allocated automatically. You do not need to raise a support ticket or take any action: scaling is handled by the platform.

Aggregation: batching events for file-based systems

For destinations that work with files rather than APIs (a 3PL collecting a CSV from an FTP server, for example), HC can aggregate events instead of sending each one individually. Events are combined into batches of a configured size: with a page size of 10, a job that produces 50 events results in 5 aggregated files of 10 events each.

Aggregation creates additional parent events that act as the containers for each batch. These parent events appear in the Control Panel like any other event and are chargeable as normal. Whether a destination sends in real time, on a schedule, or aggregated is part of your integration's design; ask HC if you are unsure which applies to a stream.

Where pressure actually builds

Most delays during high-volume periods are not caused by HC's queue. They come from the systems HC is posting into. Common bottlenecks:

  • ERP rate limits: NetSuite and similar ERPs impose API call limits. HC respects these limits and queues events rather than dropping them, but processing will be slower if your ERP is at capacity.

  • WMS import queues: warehouse systems often process fulfilment instructions in batches. A large spike may mean orders sit in the WMS queue for longer than usual before being picked up.

HC monitors these signals and retries automatically. Events are never lost.

Retries and event durability

If a downstream system is temporarily unavailable or rate-limited, HC retries the event automatically using a backoff strategy. You can see the retry status of any event in the Control Panel. No events are silently dropped: everything either succeeds or appears in the failed events list for manual review or bulk resend.

What this means for you

  • Another customer's spike has no effect on your processing, and yours has no effect on theirs.

  • You do not need to ask HC to scale for a peak; capacity is added automatically as your queue deepens.

  • If events are slow to arrive during a peak, the bottleneck is usually your ERP's API limits or your WMS import queue rather than HC. Events are queued and retried, not dropped.

  • If a stream is aggregated, you will see parent events in the Control Panel alongside the individual events, and they are chargeable as normal.

  • You can see the retry status of any event in the Control Panel. Anything that does not succeed appears in the failed events list for manual review or bulk resend.

Preparing for a known peak

If you have advance notice of a large spike (a product launch, a flash sale, or a seasonal campaign), there are a few things worth checking beforehand:

  • Confirm all relevant streams are active and processing cleanly in the days before the event.

  • Check with your ERP or WMS provider whether any API limits apply to your account and whether these can be temporarily raised.

  • Verify that your error alerting is configured so you are notified promptly if any events fail (see Setting up error alerts).

  • Make sure you know how to use the bulk resend feature in the Control Panel in case a batch of events needs to be replayed (see Requesting a bulk resend).

Let HC know in advance if you are expecting an unusually large spike. HC can monitor more closely during the window and respond faster if anything unexpected comes up.

Was this helpful?

Still need help? Ask the team