Preparing SAP Commerce Cloud for High-Traffic Events

Black Friday does not take your site down; the preparation you skipped in September does. Peak events are the most predictable incidents in commerce: the date is known months ahead, the traffic shape is known from last year, and the failure modes are the same handful every time. This guide turns two CX Works pieces into one operational playbook: what to measure, what to tell SAP and when, what to change in the build, and the checklist that separates a record sales day from a war-room weekend.

Start With Numbers, Not Vibes#

Preparation without a baseline is guessing. Four questions to answer with data, using the Dynatrace instance every CCv2 environment already has:

1. What is normal? Document baseline load distributions: requests per minute by hour and timezone, the fastest and slowest pages, normal throughput ranges. You cannot recognize "extraordinary" without a documented "ordinary", and mid-event decisions (scale, throttle, disable) need thresholds agreed in daylight, not invented at 2 a.m.
2. What did last year look like? Hour-by-hour traffic and order curves from previous events, or from load tests if this is year one. The preparation target is a number ("3x normal peak, 5x on the hour the email lands"), not an adjective.
3. What does the business actually expect? Minimum and stretch sales goals, planned promotions and how they will be marketed, flash sale versus week-long event. A flash sale (huge volume, minutes-wide window) and a prolonged sale stress completely different parts of the stack: the former hammers cart and checkout concurrency, the latter exposes slow leaks and cache churn.
4. Where are your known weak spots? A written profile of hot spots and their early-warning signs: the features with bad performance characteristics, the external services that brown out first, the infrastructure bottlenecks from past incidents. This document becomes the triage sheet during the event.

One deliberately uncomfortable conversation belongs here: if demand exceeds capacity, what gives? Letting the whole site degrade to maximize sales, queueing traffic to protect the experience of those inside, or disabling expensive features mid-event are all legitimate answers, but only if decided and documented before the event, with the decision-makers named.

Tell SAP, Early, With Real Numbers#

CCv2 infrastructure scales, but not instantaneously, and not telepathically. When a high-traffic event is planned, open a support ticket well in advance stating dates, expected traffic multiples, and their basis. What this buys: proactive scaling ahead of the event, extra monitoring attention, and a support organization that reads your traffic spike as "the planned event" instead of "possible attack".

Guidance for the request itself, learned from how these get evaluated:

• Back the numbers with evidence. A site that normally peaks at 20 orders per minute requesting capacity for 1,200 will be asked how it produced that estimate. Marketing reach, historical conversion, and last year's curve make an approvable request; a round number does not.
• Remember you are not the only one. For calendar events (Black Friday, Singles' Day) every retail customer is asking at once. Well-founded, flexible requests get accommodated; late maximalist ones get negotiated down.
• Lead time is a real constraint. Weeks, not days; for very large multiples, more. Put the ticket-filing date into the project calendar the same day marketing fixes the event date.

The Special-Event Release#

Two release decisions define the technical preparation:

Code freeze, with margin. Freeze changes early enough that the frozen build gets fully tested and there is still room to fix what testing finds. A freeze one week before the event that discovers a regression three days before has achieved nothing. Also be on the latest patch of your update release before the freeze: performance fixes ride patches, and "we peaked on a build with a known fixed bug" is a bad retro line.

Consider a dedicated peak build. For sites with expensive features, fork the production configuration into a special-event variant: costly personalizations toned down, non-essential integrations behind kill switches, configurable behaviours tuned for throughput. Deploy it to production well before the event, tested like any release. Even if you never fork code, build the kill switches: every expensive or third-party-dependent feature should be disableable by property or CMS toggle, because "turn it off" is the single most useful emergency action and it must not require a deployment.

The Preparation Checklist#

The accumulated list, grouped by system. Each item is boring; together they are the event.

Delivery and frontend

• CDN in front of the storefront; on CCv2 additionally enable static media and UI resource offloading on the storefront endpoint in Cloud Portal, so the platform nodes spend their cycles on dynamic work.
• Lighten the heavy pages: fewer banners and carousels on the homepage, bounded product counts in carousel components, image sizes audited (the homepage hero that marketing uploaded at 8 MB is a tradition; break it).
• CMS component caching reviewed and enabled where content allows.

Third parties

• Inventory every synchronous third-party call in the shopper path (tax, payment, ratings, chat, tag soup). For each: its performance under your projected load confirmed with the vendor, a timeout that fails fast, and a kill switch. Disable the ones that are not earning their latency during the event.

Search

• Solr query and indexing configuration tuned per the search guides in this series.
• No schema, synonym, or keyword changes during the event window. These invalidate carefully warmed behaviour and have a habit of triggering full reindexes at the worst moment.

Jobs and data

• Cronjob audit: nothing non-critical runs during peak hours. Full syncs, exports, feeds, cleanup jobs move to the quiet hours or pause for the event.
• No ImpEx during business hours of the event; stock and price updates minimized to what the business genuinely needs live, batched into the quietest windows.
• Backoffice discipline: no complex ad-hoc queries or reporting from Backoffice during the event (that workload lands on the same database your checkout uses), and admin access to Backoffice and Cloud Portal trimmed to the short list of people who need it, because the fastest way to take a site down during peak remains an accidental admin action.
• Large hot tables (carts, cart entries, price rows, stock, tasks) cleaned up beforehand via the retention rules from the data maintenance guide. Table size is a latency multiplier under exactly the load you are preparing for.

Promotions

• Few, focused, tested. Every active promotion rule is evaluation work on every cart operation; stale and overlapping promotions are pure drag. Disable what is not part of the event, and load-test the ones that are (details in the promotion engine performance guide).

Monitoring and alerting

• Kibana/OpenSearch alerts configured for the failure signatures you profiled: exception bursts, error-rate thresholds per aspect, the specific log patterns of your known hot spots. Every exception class that fires in the weeks before the event is a pre-event fix, both for its own sake and because exception pressure correlates with the memory churn and long GC pauses that show up under load.
• Dynatrace dashboards for the event: the baseline views plus order throughput, so operations sees business impact, not just CPU.

Test the Event Before the Event#

Load testing is the rehearsal, and it must rehearse the right play:

• Test the event's traffic shape (the flash-sale spike or the sustained plateau, on the event's landing pages and checkout mix), not a generic soak.
• Test on production-shaped data and configuration, on a pre-production environment scaled like production, with the special-event build if one exists.
• First year of an event, or after major stack changes: run a full dry run, meaning the whole operational plan (people, dashboards, escalation, kill switches) exercised against a load test as if it were live. Teams that have rehearsed the emergency procedure execute it in minutes; teams reading it for the first time during the incident do not.
• Established events with stable stacks can scale the testing down to cover what changed since last year. "Nothing changed" is rarely true; check the integration list.

Running the Event#

Operations for the event window itself:

• Coverage roster across storefront peak hours and the after-hours batch windows, spanning all technologies (platform, Solr, database, integrations, CDN) plus marketing operations, because the team sending the promotional email at 10:00 is part of the load-generation system and must be in the loop.
• Escalation sheet circulated beforehand: who decides what, with phone numbers. Include the pre-agreed degradation decisions from the baseline section so the 2 a.m. decision is a lookup, not a debate.
• Status cadence and templates: scheduled checkpoint updates on a known channel, plus an emergency template, so communication during an incident costs seconds and reads consistently.
• After: capture the curves, the incidents, the near-misses, and the checklist gaps within a week, while memory is fresh. This document is next year's head start, and the reason established teams find peak events progressively boring, which is the goal.

The Two-Line Summary#

Baseline in Dynatrace and decide degradation policy in advance; tell SAP early with evidence; freeze and patch; kill-switch everything expensive; silence the batch layer during peak; test the actual event shape; staff the window and write down what happened. None of it is clever, all of it is calendar discipline, and the sites that do it make the news for sales records instead of outages.