SAP Integration Suite Scaling: How Elkjøp Handles Black Friday Traffic

SAP Integration Suite scaling involves three distinct approaches: increasing worker-node capacity within a Cloud Integration tenant, distributing suitable integration workloads across multiple tenants, and maintaining separate environments for high availability or disaster recovery.

For retailers, the challenge becomes particularly visible during Black Friday. Sudden increases in orders can multiply integration traffic across payment, inventory, order management, fulfilment and partner systems. Whether the integration platform can handle that demand depends not only on available capacity but also on message processing patterns, queue design, traffic distribution and operational readiness.

Elkjøp, one of the largest consumer electronics retailers in the Nordic region, provides a practical example. Tarento helped build its high-volume, event-driven integration architecture using SAP Cloud Integration, Confluent Kafka and Azure Service Bus. Tarento's published case study reports more than 50,000 retail orders processed daily and zero integration disruption during the Black Friday peak.

This article explains how SAP Integration Suite handles peak workloads, when additional tenants can help, what must be tested before scaling, and how tenant synchronization and resiliency management fit into the architecture.

Elkjøp's Integration Landscape at Peak

Elkjøp operates more than 400 stores across six countries. Tarento built its hybrid integration platform on SAP Cloud Integration with an event-driven architecture based on Confluent Kafka and Azure Service Bus.

According to Tarento's published Elkjøp case study, the platform runs more than 300 SAP Cloud Integration flows, handles over 30 million API calls monthly through SAP API Management, processes more than 50,000 retail orders daily and experienced zero integration disruption during the Black Friday peak.

These volumes demonstrate why integration capacity is a critical part of retail peak readiness. Depending on the order journey, a single transaction may trigger multiple downstream events involving inventory reservations, payment processing, fulfilment updates and partner communications. A sharp increase in orders can therefore create a significantly larger increase in integration traffic.

Elkjøp's architecture illustrates the value of decoupling enterprise systems through event-driven integration. For a broader explanation of the underlying architecture and its role in omnichannel retail operations, see SAP Integration Suite for Retail: Scaling Omnichannel Operations with Event-Driven Architecture.

The focus here is different: how to manage processing capacity, distribute integration workloads across tenants and prepare the platform for concentrated traffic peaks.

How SAP Integration Suite Scales, and Where the Limits Are

SAP Integration Suite includes SAP-managed high availability across multiple availability zones within a supported cloud region. This protects against certain infrastructure failures and supports the service availability commitments applicable to the subscribed edition.

High availability should not be confused with additional customer-controlled processing capacity or cross-region disaster recovery. Enterprises must assess throughput requirements, worker-node capacity and regional recovery needs separately.

SAP's guidance on high availability and disaster recovery scenarios explains the distinction between availability-zone resilience and recovery from a broader regional failure.

Capacity within a SAP Cloud Integration tenant is influenced by its worker-node configuration. SAP describes two scaling approaches.

Vertical scaling increases the memory allocated to worker nodes. SAP's April 2026 scalability guidance describes configurations ranging from the default 4 GB to 20 GB.

Horizontal scaling adds worker nodes to increase processing capacity. This can help workloads with high message volumes, demanding processing requirements or significant interaction with external systems. However, the number of worker nodes is subject to platform limits and the applicable service configuration.

Scaling changes are coordinated with SAP. Its guidance recommends load testing on a QA tenant configured similarly to production, validating the required capacity and requesting corresponding production changes before the expected traffic increase.

SAP also emphasizes that adding capacity cannot compensate for inefficient integration flow design, inappropriate message handling or avoidable processing overhead.

Lever	What it handles	What it does not handle
Multi-availability-zone HA (built in)	Certain infrastructure or availability-zone failures	Additional customer-controlled throughput capacity or full regional disaster recovery
Larger or more worker nodes (requested from SAP)	Higher processing capacity within a tenant	Capacity requirements beyond supported limits or scaling changes that require advance coordination
Additional tenants (scale-out)	Workload isolation and additional processing capacity when traffic distribution is properly designed	Automatic workload sharing, configuration consistency or safe execution without architectural preparation
Cross-region failover tenant	Recovery from a regional outage or support for planned maintenance	Additional live processing capacity unless the tenant is also configured to handle production traffic

The last two approaches introduce additional architectural and operational requirements. Provisioning another tenant is only the first step. Making it process traffic safely requires deliberate design, configuration, testing and monitoring.

What Has to Be True Before a Second Tenant Adds Capacity

Scaling out across SAP Integration Suite tenants works only when the architecture allows several tenants to process workloads without conflicting.

Five conditions are particularly important.

1. Inbound synchronous traffic is distributed. API and HTTP calls reach the tenants through a routing layer, such as DNS-based traffic management (Azure Traffic Manager or Amazon Route 53) or an API gateway. At Elkjøp, SAP API Management already fronts more than 30 million calls a month.

2. Design asynchronous processing for multiple tenants. Additional SAP Integration Suite tenants can share asynchronous workloads when the messaging architecture supports controlled distribution across consumers.

With Kafka or Azure Service Bus, work distribution depends on the configuration of consumer groups, subscriptions, acknowledgments and redelivery behavior. Integration flows must also account for duplicate delivery, message ordering, idempotency and downstream transaction handling.

JMS queues managed within an individual SAP Cloud Integration tenant do not automatically become shared across separate tenants. A multi-tenant architecture therefore needs an explicit strategy for how messages are distributed, processed, retried and monitored.

Before using additional tenants for peak capacity, validate that the selected broker configuration and integration flows preserve the required business processing semantics under load and during failures.

3. Timer and polling flows run on one tenant only. A scheduled job or an SFTP, mail or database poller deployed on two tenants will fetch the same files or records twice. These flows need to be pinned to a single tenant.

4. Artefacts and configuration are identical. Integration flows, mappings, value mappings, scripts, credentials and global variables must match across tenants, or the same order is processed differently depending on where it lands. Number ranges need a deliberate design, because two tenants issuing interchange or document numbers independently can collide.

5. Monitoring spans tenants. SAP Cloud Integration monitoring is per tenant, so operations need a combined view to see a peak building up across all of them.

How Tenant Synchronization and OneFailover Support Peak Readiness

Elkjøp's published integration case study demonstrates the value of designing for high-volume retail operations. Tarento reports that its SAP Cloud Integration architecture, supported by Confluent Kafka and Azure Service Bus, processes more than three million messages daily and operated without integration disruption during the Black Friday peak.

The case study also describes microservices tooling for primary-secondary tenant synchronization. However, the publicly available project documentation does not specify whether this implementation uses Tarento's OneFailover product.

For enterprises operating multiple SAP Integration Suite tenants, keeping integration artifacts and configurations aligned is an important part of readiness. Additional tenants can support workload isolation or distributed processing, provided the surrounding architecture handles traffic routing, message delivery, operational monitoring and tenant-specific configurations correctly.

OneFailover is Tarento's resiliency management application for SAP Integration Suite. It is designed to manage SAP Integration Suite resilience through artifact synchronization, Git-based backup, tenant management and cross-region failover coordination.

These capabilities can reduce manual effort in maintaining consistent integration environments and preparing secondary tenants for recovery. However, synchronization alone does not create additional processing capacity or ensure that a new tenant can safely accept live workloads.

A scale-out architecture also requires appropriate SAP entitlements, runtime capacity, validated integration deployments, traffic distribution and safe handling of asynchronous and scheduled workloads.

For retailers preparing for Black Friday or similar events, the practical goal is to establish a repeatable readiness process. That includes production-like load testing, configuration validation, operational monitoring and rehearsed recovery procedures before traffic volumes increase.

A separate consideration is the recovery of runtime data. Artifact synchronization does not automatically preserve messages already being processed or persisted within the primary tenant. Tenant-local JMS queues, data stores, processing logs and in-flight transactions require their own recovery planning.

External messaging platforms can support durable delivery, replay and workload distribution when configured appropriately, but business continuity also depends on acknowledgments, retry policies, duplicate handling and the recovery procedures implemented across the wider architecture.

Similarly, inbound traffic switching depends on enterprise routing components such as DNS-based traffic management or an API gateway. These capabilities need to be coordinated with the tenant synchronization and recovery processes.

A Peak-Readiness Checklist for SAP Integration Suite

Most of what protects a peak is done weeks in advance, with or without additional tenants. For a retail landscape on SAP Integration Suite, the checks that matter most are:

Load-test expected peak volumes. Use a QA tenant configured similarly to production and request any necessary worker-node changes from SAP before the event.
Establish a change freeze. Limit integration content changes during the trading window and route emergency changes through the established transport process.
Verify tenant readiness. Confirm that secondary or failover tenants have the required artifacts and configurations, and rehearse failover and failback rather than assuming they will work.
Check security dependencies. Review certificates, OAuth clients and credentials that may expire during or shortly after the peak.
Review messaging capacity. Validate retry settings, message sizes, processing concurrency and JMS queue usage against relevant tenant limits.
Prepare operational responses. Agree alert thresholds, on-call coverage and written runbooks for traffic switching and recovery.
Review actual performance after the event. Compare observed traffic, processing latency, errors and queue behavior against load-test results, then document improvements for the next peak.

Where relevant, the review should also consider processing latency, throughput, queue backlog, failure rates and dependencies on downstream systems.

These measurements help distinguish an integration platform capacity issue from delays caused by external applications, databases or network services.

When OneFailover Fits

OneFailover is relevant to enterprises where SAP Integration Suite supports business-critical operations and the cost of an outage makes recovery preparation an important architectural consideration.

Potential use cases include multi-tenant environments, cross-region resilience requirements, planned maintenance, recurring disaster recovery testing and integration landscapes with numerous critical APIs, listeners, scheduled jobs or partner connections.

Retail and e-commerce operations can be particularly sensitive to interruptions during campaigns and concentrated trading periods because inventory, order processing, fulfilment and partner integrations need to remain coordinated.

However, the need for additional resilience tooling depends on the actual architecture and business requirements.

For a single-tenant landscape with modest workloads, SAP's built-in high availability and appropriately planned worker-node capacity may be sufficient, depending on business continuity requirements, recovery objectives and measured processing demand.

For larger or more complex environments, the decision should account for tenant configuration consistency, recovery procedures, cross-region dependencies and the operational effort required to maintain a reliable secondary environment.

Frequently Asked Questions

Can Two SAP Integration Suite Tenants Run Active-Active?

Yes, but only if the architecture is designed for it. Inbound calls need a routing layer in front of both tenants, asynchronous work should be consumed from a shared broker so each message is processed once, and timer or polling flows must run on one tenant only. SAP's multi-region designs for SAP BTP are reference architectures that customers implement and operate themselves.

Is a Second Tenant for Peak Scaling the Same as Disaster Recovery?

No. A scale-out tenant shares live traffic to add capacity. A disaster recovery tenant stands ready in another region to take over if the primary region fails or is under maintenance. One tenant can serve both purposes if it is in a different region and kept in sync, but the traffic design, testing and runbooks differ for each role.

Does SAP Integration Suite Scale Automatically During a Traffic Spike?

Not in the sense most retail teams need. High availability across availability zones is built in, but throughput depends on the worker nodes provisioned for the tenant. SAP's guidance treats vertical and horizontal worker-node scaling as a change requested in advance, after load testing on a QA tenant, rather than something to rely on during the spike.

Does Edge Integration Cell Change Peak Planning?

Yes. Integration flows deployed on Edge Integration Cell run on Kubernetes infrastructure that you provide and operate, in your own data centre or private cloud. Capacity for those flows therefore depends on how you size and scale that cluster, and it needs its own load test and failover plan alongside the cloud tenants.

Does OneFailover Replace SAP's Built-in High Availability?

No. SAP's multi-availability-zone high availability continues to protect each tenant within its region. OneFailover adds a managed layer on top: keeping secondary tenants in sync, cloning tenants for scale-out, backing artefacts up to Git, and orchestrating failover and failback across regions.

How Early Should a Retailer Prepare SAP Integration Suite for Black Friday?

Early enough to finish three things before the change freeze: a load test at expected peak volumes, any worker-node scaling SAP needs to apply, and a failover and failback rehearsal. Architectural changes such as adding scale-out tenants are safer when planned after one peak for the next one.

Is Your SAP Integration Suite Ready for the Next Traffic Peak?

High-volume retail integration requires more than sufficient worker capacity. Traffic distribution, asynchronous processing, tenant consistency, monitoring and recovery procedures must work together under production-like conditions.

Tarento's enterprise integration team can help assess your SAP Integration Suite architecture, identify potential capacity constraints and review options for multi-tenant scaling and resilience.

A peak-readiness review can cover: