In short and in plain language
Black Friday is at the end of November. On these days, a lot of people shop online.
The shop sends each order to a second program. This program knows the stock, the prices and the bills. On such days it often cannot keep up.
The article shows what you do five weeks before. You count how many orders come in each hour. You move big tasks that run at night to other days.
A waiting list holds all orders. If the list gets too long, you get a warning. There is a fixed plan for an emergency.
We help you with this.
Black Friday falls on Friday, 27 November 2026, and Cyber Monday on the following Monday, 30 November. For the two promotion days in 2025, the German Retail Federation had forecast revenue of 5.8 billion euros, a decline of almost two percent on the previous year; the forecast was published on 17 November 2025 (HDE), and no figure for 2026 was available at the time of writing. If your online shop is connected to an ERP, these days often play out differently than planned: the storefront holds up, but the order export to the ERP, the stock feedback and the shipping status fall behind. Customers have their confirmation, the warehouse sees the orders hours later, and by Saturday morning the enquiries pile up. This article describes how to prepare the order flow between your shop and ERP in the five weeks before Black Week: measure order rate and backlog, move nightly bulk jobs out of the promotion window, set up a queue with an alert threshold, buffer promotional items, freeze the interfaces and define a fallback.
Key takeaways
- For Black Friday and Cyber Monday 2025, the HDE forecast 5.8 billion euros in revenue (HDE). In 2026 the days fall on 27 and 30 November; preparing the ERP interface starts five weeks ahead.
- The backlog is inflow minus outflow per hour: orders placed in the shop against orders the ERP acknowledges. Data from last year's promotion week shows from which hour the level rises.
- Nightly price imports, full syncs and exports belong outside the promotion window. Business Central allows 6,000 OData requests per user in five minutes, shared by every job of that user (Microsoft Learn).
- The queue alerts on the age of the oldest open order. As a starting point for paging alerts, Google suggests 2 percent of the error budget consumed in one hour (Google SRE Workbook).
- Retry in one place: three layers with three retries each turn one action into up to 64 attempts (Google SRE Book). Symfony Messenger retries three times by default (Symfony documentation).
- From 23 November to 1 December, a change freeze applies to the interface. The fallback keeps accepting orders and signals overload with 503 and Retry-After (RFC 9110).
Where Black Week really backs up
Demand is predictably high. In a survey of more than 1,000 online shoppers conducted by IFH Köln for the HDE in October 2025, 48 percent planned to go bargain hunting on Black Friday and more than a third on Cyber Monday (HDE). In a representative survey of 1,120 internet users aged 16 and over, the German digital association Bitkom found that 52 percent wanted to use the reduced prices around Black Friday and Cyber Week; 69 percent of them planned to look for offers exclusively online (Bitkom). Official statistics show the month as well: according to provisional, calendar and seasonally adjusted results, German online and mail-order retail turned over 5.9 percent more in real terms in November 2025 than in November 2024 (Destatis).
For the technology this means many orders in a few hours, often bunched around the start of a promotion and the evenings. You can prepare the storefront with caches, additional servers and a load test. The ERP, by contrast, is designed for day-to-day operations. It books orders one by one, checks credit limits, reserves stock, assigns document numbers and writes to the same tables the warehouse and accounting are working with. Cloud ERP systems add hard limits: Microsoft Dynamics 365 Business Central processes at most 5 OData requests per user at the same time; further requests wait in a queue and time out after 8 minutes with status code 503 (Microsoft Learn).
This is why operations back up in three places that hardly anyone notices day to day:
- Order export from shop to ERP: orders are confirmed in the shop but not yet created in the ERP. The warehouse does not see them, and picking starts later.
- Stock feedback from ERP to shop: sales are deducted late, so promotional items remain orderable although they sold out long ago.
- Shipping status from ERP to shop: delivery notes and tracking numbers come back late and in bulk, the shipping email is delayed, and customer service enquiries rise.
All three flows run through the same interface, often through the same middleware and the same technical user in the ERP. If you monitor and prioritise them separately during the promotion week, a large part of the preparation is already done.
Measuring order rate and backlog
Preparation starts with figures from your own system, not with assumptions. You need four values per hour, ideally from last year's Black Week, otherwise from a normal week and a load test: How many orders does the shop accept? How many orders does the ERP acknowledge? How long does the handover take from order to acknowledgement? And how old is the oldest order that has not yet been acknowledged?
These values follow the four golden signals Google names for monitoring services: latency, traffic, errors and saturation (Google SRE Book). Saturation deserves the most attention during the promotion week, because many systems slow down before they reach 100 percent utilisation (Google SRE Book). An ERP that keeps up easily on a quiet Tuesday may manage fewer orders per hour on Friday evening, because warehouse, accounting and customer service are all working on it at the same time.
| Signal | In the order flow | Measuring point | What the value shows |
|---|---|---|---|
| Traffic | orders per hour | checkout completion in the shop | how strongly the promotion pulls |
| Latency | time until ERP acknowledgement | timestamps of order and acknowledgement | whether the handover is falling behind |
| Errors | rejected handovers | ERP API responses, the queue's failure store | whether data or limits are the problem |
| Saturation | open orders in the queue | queue depth and age of the oldest entry | whether the level is rising or falling |
A worked example with assumed values shows why the backlog is the decisive measure: if the shop accepts 900 orders per hour on Friday evening and the ERP acknowledges 600, the level grows by 300 orders per hour. After three hours, 900 orders are waiting. If inflow then drops to 400 per hour, the ERP only reduces the backlog by 200 per hour and needs four and a half hours until the queue is empty again. Customers have long had their order confirmation, while the warehouse is still working with the state of the early evening.
From last year's data you derive an expected level for every hour of the promotion week. If the highest expected backlog exceeds what the ERP can clear by the next morning, two levers remain: more outflow, for example through batch postings, parallel processing or a second technical user, or less competition for the same outflow. The second lever is usually the cheaper one, and the following sections are about it. How batching and parallelism work with cloud ERP APIs is covered in our article on API limits for bulk imports.
The queue as a buffer between shop and ERP
A shop that writes every order synchronously to the ERP waits for the slowest link. If the ERP responds sluggishly, checkout hangs and in the worst case fails. Decoupling is more robust: the shop places the order in a queue and confirms it to the customer, and a worker transfers it to the ERP at its own pace. The queue absorbs the peak and the ERP works through it. The basics are covered in the article on event-driven architecture and message queues.
In Shopware, the message queue does this job. For production systems the documentation recommends processing it with workers on the command line instead of the admin worker in the browser (Shopware documentation). Order also matters in the promotion week: if a worker is given several transports, it processes them in exactly that order (Symfony documentation). The order export therefore belongs in a transport of its own that comes before all others.
# Worker for the order flow: orders first, then feedback, then everything else, finally the failure transport
ExecStart=php /var/www/html/bin/console messenger:consume \
erp_orders erp_feedback async low_priority failed \
--time-limit=60 --memory-limit=512M
Restart=alwaysThe order export needs two properties before it goes into the peak. First, idempotency: a message can be delivered more than once in normal operation, for example when a worker processes it and crashes before acknowledging it (Symfony documentation). The ERP must therefore recognise an order by the shop's order number and must not create it a second time. Second, a failure store: after three unsuccessful retries, Symfony Messenger discards a message by default or moves it to a failure transport if one is configured (Symfony documentation). Without a failure transport an order disappears silently, and the failure transport needs a running worker too (Shopware documentation). What idempotency keys and deduplication look like in detail is covered in the article on idempotency and retry strategies.
Limit retries instead of multiplying them
At the peak, retries are more dangerous than errors. Google describes the effect using three layers that each retry three times: a single user action turns into up to 64 attempts on the overloaded database (Google SRE Book). Applied to the order flow: if shop plugin, middleware and ERP connector retry independently of each other, an ERP that is already slow receives a multiple of the actual load. Retries therefore happen in exactly one place, the queue worker, with growing intervals and a random component. Google also suggests a retry budget, in its example 60 retries per minute and process; once it is used up, the request fails instead of running again (Google SRE Book).
If the ERP API responds with status code 429, the client has sent too many requests in a given period (RFC 6585). The response may state in a Retry-After header how long to wait. The worker reads this value before starting the next attempt, and it pauses the whole transport, not just the one message.
Alert threshold: the level, not the single error
An alert rule that fires on every transmission error gets muted within an hour during Black Week. The water level of the queue is more meaningful, in three forms: the age of the oldest order not yet acknowledged, an outflow that drops to zero while orders keep coming in, and a queue depth well above the expected level for that hour. Age is the most important value, because regardless of volume it tells you how long a customer waits for their order to be processed.
These rules complement an alert that fires when no orders come in at all. That one catches a broken checkout or a disrupted payment integration. The level rules catch the opposite case: orders arrive, but they do not arrive in the ERP. Both alerts belong in the promotion week, and neither replaces the other.
To set the threshold, it helps to have a target you can state in one sentence, for example: 99 percent of orders are in the ERP within 15 minutes. Anything beyond that consumes an error budget. As starting points, Google recommends paging the on-call person when 2 percent of the budget is consumed in one hour or 5 percent in six hours, and opening a ticket for 10 percent in three days (Google SRE Workbook). Relative to a monthly budget, the first level means that at this pace the entire budget would be used up after 50 hours, before the promotion week is over.
# Alert rules for the order queue
- alert: OldestOrderTooOld
expr: erp_orders_oldest_unacked_seconds > 1200
severity: page
- alert: OrderOutflowStopped
expr: rate(erp_orders_acked_total[15m]) == 0 and rate(shop_orders_placed_total[15m]) > 0
severity: page
- alert: QueueAboveExpectedLevel
expr: erp_orders_queue_depth > 2 * erp_orders_queue_expected_depth
severity: ticketWho receives the alert matters just as much. Between Thursday and Tuesday you need a named on-call person for the interface who has access to queue, middleware and ERP logs and knows whom to reach at the ERP provider. Which metrics belong on a dashboard for this is described in the article on observability for interfaces.
Moving nightly bulk jobs out of the promotion window
Many interfaces have their quiet time at night, and that is exactly where the big jobs sit: price import, full stock sync, catalogue export to marketplaces and price comparison sites, customer master sync, document export to accounting. During the promotion week the night is not quiet. If you start your promotion at midnight, the price import runs straight into the first wave of orders.
The problem is shared capacity. Business Central allows 6,000 OData requests per user in a sliding five-minute window; if the limit is exceeded, the service responds with 429 (Microsoft Learn). If the price import runs under the same technical user as the order export, both share this quota and the five concurrent requests. ERP systems without fixed API limits still have competition for database, locks and computing time. The same rule therefore applies to a Dynamics integration as to an SAP integration: during the promotion week the order export has priority, and everything else gives way.
| Job | Usual timing | During the promotion week | Reason |
|---|---|---|---|
| Price import | at night | load promotional prices with validity dates in advance, pause the import until Tuesday | prices change without a job run during the order wave |
| Full stock sync | at night | pause it, transfer changes only | a full sync overwrites reservations and loads the API |
| Catalogue and feed export | at night | finish before Thursday, then only price and stock changes | large exports tie up the user for hours |
| Customer master sync | hourly or at night | keep running, throttled | new customers need a customer number for the order |
| Document export to accounting | at night | move to a quiet time in the morning | the order is time-critical, the booking entry tolerates a few hours of delay |
| Media and image import | as needed | pause it | no relation to the order flow |
Separate technical users per flow
For promotional prices this means: prices with a start and end date are loaded the week before and checked in the shop. No job then has to run at midnight, because the shop switches by date. Only when the promotion is over does the price import resume its schedule, ideally with a supervised run on Tuesday morning rather than at night.
Buffering stock for promotional items
Stock feedback is the flow most likely to fall behind at the peak, because it follows the order: only once the ERP has booked the order is stock reduced and can be reported back to the shop. If the order export is backed up, stock in the shop is too high as well. For promotional items with small quantities, that is the direct route to overselling.
- Reservation in the shop: the shop deducts stock itself at checkout and does not wait for feedback from the ERP.
- Safety buffer per promotional item: a fixed deduction from the reported stock that covers one hour of expected backlog.
- Allocations instead of total stock: a promotional quantity is released for each promotional item; once it is sold, the promotion ends for that item.
- Priority for changes: stock changes for promotional items run ahead of all other items in the feedback transport.
- No full sync during the promotion: it overwrites the shop's reservations with a state that is already outdated when it arrives.
How reservations, safety stock and thresholds work together across several warehouses is described in the article on inventory sync across multiple warehouses.
Spreading out shipping status and feedback
The third flow runs in the opposite direction and has its own timing: the warehouse does not ship the promotional orders on Friday evening, but from Saturday and above all in the days after Cyber Monday. That is when delivery notes, tracking numbers and invoices come back from the ERP in large volumes, and the shop sends shipping emails based on them. This feedback belongs in a transport of its own with lower priority than the order export but higher than catalogues and feeds. If the shipping email does not arrive, customers ask, and every enquiry ties up customer service in the week when it is already at capacity.
Transfer feedback in batches instead of sending every tracking number individually, and check whether the shop delays shipping emails at the peak because it sends them through its own queue. If status changes arrive in the wrong order, such as the invoice before the delivery note, the interface holds them back until the previous step has arrived. The right place for these ordering rules and the mapping of documents is API development, not a script that compares tables at night.
Change freeze on interfaces
Under load, any change that was not tested shows up first. That is why a change freeze applies to the order flow: from the Monday before the promotion week, 23 November, to the Tuesday after Cyber Monday, 1 December, middleware, the interface's shop plugins, mappings and customising in the ERP stay unchanged. This also applies to updates installed by a service provider. Check with your ERP provider and your hosting provider whether maintenance windows or version upgrades are planned for this period, and have them rescheduled.
Exceptions are security fixes and bug fixes to the order flow itself, with a test, approval by a second person and a prepared way back. After every deployment of new code the workers must restart so that they load it at all (Symfony documentation) – a step that is easily forgotten under time pressure.
Last date for changes
The fallback when the ERP cannot keep up
Despite all preparation, the ERP may fail or slow down so much that the backlog is not cleared by the morning. For this case you need a fallback that has been agreed beforehand and rehearsed once. The shop keeps accepting orders, and the queue holds them. The middleware passes the state on with a clear response: status code 503 indicates that a service cannot handle a request right now because of a temporary overload or maintenance (RFC 9110). With the Retry-After header it states how long the service is expected to be unavailable (RFC 9110), and the workers pause instead of retrying in loops.
- Decide: who declares the fallback, from which age of the oldest order, and who informs warehouse and customer service?
- Stop the workers, keep the queue: do not delete orders and do not trigger manual retries.
- Set priorities: orders with express shipping or click and collect first, the rest in order of arrival.
- Switch over if it takes longer: export orders from the shop as a list, pick them in the warehouse and enter them in the ERP later.
- Restart with duplicate protection: while working through the queue, the ERP recognises orders already entered manually by the shop's order number.
What a complete ERP outage requires beyond this, such as stock values with an age stamp and credit checks without an ERP response, is covered in the article on fallback operation during an ERP outage.
Five weeks to Black Week: the schedule
Preparation from 19 October 2026
- 1
Week 43: take stock
Evaluate last year's data: orders and acknowledgements per hour, handover time, oldest open order. List every job on the interface with time, user and runtime.
- 2
Week 44: harden the queue
A transport of its own for orders with priority, check idempotency via the shop's order number, set up a failure transport with a worker, limit retries to one layer.
- 3
Week 45: alerts and on-call
Set up alert rules for age, outflow and level and trigger them as a test. Define the on-call plan with names, availability and contacts at the ERP provider.
- 4
Week 46: load test
Run the interface against a test system with last year's hourly profile plus a margin. Measure outflow, name the bottleneck, implement the countermeasure.
- 5
Week 47: job plan and fallback
Load promotional prices with validity dates, pause or move night jobs, rehearse the fallback once from start to finish, complete all changes by Friday.
- 6
23 November to 1 December: promotion week
Change freeze, status review morning and evening, record the backlog after every peak.
- 7
From 2 December: review
Switch jobs back on, save the measurements, compare expected and actual levels and file the values for next year.
The load test in week four takes the most preparation and reveals the most. It does not need a large tool, but it needs an ERP test system with realistic data and a script that feeds in orders following last year's hourly profile. Without it, every alert threshold remains an estimate. We review the order flow of your ERP and inventory integration as part of our services, build missing components such as transports, idempotency or alert rules and coordinate the job plan with your ERP provider. For an initial assessment, a short enquiry listing the systems you connect is enough.
Related Articles
RMA Process: Managing Returns Between Shop and ERP
Manage return requests, RMA numbers, inspection, restocking and credit notes bidirectionally between shop and ERP – without double entry of returns.
Net terms and early payment discounts in B2B checkout
Read the payment terms code from the ERP, show it as a date at checkout, settle the early payment discount only on receipt and check the statutory limit on payment periods.
Stocktaking and Year-End: Prepare ERP Shop Interfaces
Counting method, freeze window and number ranges at year-end: how to prepare the interface between shop and ERP for the balance sheet date without downtime.