Capacity planning for B2B traffic peaks

An EDI hub runs flawlessly 99.9% of the time — then chokes on 30 June at 11pm during the month-end peak, or 1 July 2030 during the ViDA cut-over. EDI capacity planning must anticipate peaks, not just the average.

Which peaks to anticipate in 2026 EDI

An EDI hub load profile is very uneven:

End of month: all ERPs emit their monthly INVOIC between the 25th and the 31st. Peak ~5x above baseline.
End of quarter / year: peak ~8-10x, strongly concentrated on the last business day.
Black Friday / Cyber Monday: for retail, 10-50x ORDERS multiplication over 4-5 days.
Seasonal promotion cycles: French winter/summer sales, US Sales, Amazon Prime Day, Alibaba Singles Day (11 Nov).
Regulatory cut-over: 1 July 2030 for ViDA, other dates for national mandates. Sustained peak over weeks.
Incident peak: after a 6h partner outage, the catch-up sends 6h of backlog in minutes. Thundering herd effect.

Modelling with Little's Law

Little's Law (John Little, 1961) is the foundational brick of capacity planning:

L = λ × W

L : average number of in-flight requests
λ : request arrival rate (msg/s)
W : average end-to-end time in system (latency)

Practical example for an EDI hub: processing 500 msg/s baseline with 200ms average latency = 100 in-flight messages average. If the peak is 5x (2 500 msg/s) at unchanged latency, you need to sustain 500 in-flight messages. With only 200 concurrency slots, you saturate — new messages queue up (backlog) or get rejected (HTTP 429, AS4 503).

For each hub component (AS4 ingestion, parser, validator, mapping, broker publisher), compute current and projected L, λ, W. Identify the bottleneck (component with the highest L/capacity ratio).

Defining appropriate headroom

Headroom is the capacity margin available above average load. Too low: saturation on the slightest peak. Too high: permanent over-cost. Reference rules:

30% headroom (target load ≤ 70%): for predictable flows (e.g. end-of-month INVOIC), without abnormal peak.
50% headroom (target load ≤ 50%): for flows with regular peaks (Black Friday), absorbs without complex autoscaling.
100-200% headroom (target load ≤ 33%): for flows with unpredictable peaks or very critical (real-time HL7v2 healthcare).
N+1 or N+2 redundancy: one or two more instances than the minimum, to absorb a failure without service degradation.

Brendan Gregg (USE method, 2012) recommends alerting at 70% utilisation and going critical at 80%. Above 90%, queue length grows non-linearly (M/M/1 queueing theory).

Autoscaling for EDI: limits and patterns

Cloud autoscaling (AWS ASG, GCP MIG, K8s HPA/KEDA) works well for stateless REST APIs. For EDI, three limits:

Scale-up latency: 30-90 seconds to provision a new K8s pod or EC2 instance. During this delay, the peak saturates the existing pool. For brief peaks (< 1 min), autoscaling arrives after the battle.
Stateful partner connections: AS4 and OFTP2 maintain persistent TLS sessions. A new pod must renegotiate the handshake, adding 50-200ms without session resumption configured.
Brokers: Kafka, RabbitMQ do not scale in minutes (adding a broker = partition rebalance). Must be provisioned ahead for the anticipated peak.

Recommended patterns:

Predictive scaling: scheduled scale-up before known recurrent peaks (month-end, Black Friday) via cron or AWS Predictive Scaling.
Queue depth based scaling: scale Kafka/SQS consumers based on lag, not CPU. More predictive.
Pre-warmed pool: keep 2-3x baseline capacity permanently, fast scale only on the residual factor.

Realistic load tests

An EDI load test must reproduce partner reality:

Message mix: not just ORDERS, but the right ORDERS/DESADV/INVOIC/CRDADV ratio observed in production.
Payload size: real distribution (average INVOIC 50 lines, but 5% of INVOIC have 5 000+ lines — these are the ones that break the parser).
Temporal distribution: do not send in smooth constant flow, but with bursts (Poisson distribution, parameter λ adapted).
Concurrent connections: if you have 200 AS2 partners, simulate 200 distinct TLS sessions, not a single session in a loop.

Tools 2026: k6 (Grafana Labs, Go-based, JS scriptable), Gatling (Scala, enterprise suite), Locust (Python), Apache JMeter (legacy but widely deployed), Vegeta (Go CLI, simple). For specific EDI protocols (AS2, AS4, OFTP2), no mainstream tool covers — write custom injectors based on production libs (phase4 for AS4, Mendelson SDK for OFTP2).

Broker, DB, network sizing

Three resources that typically saturate before compute:

Kafka

Compute: 2-4 cores per broker for 10 000 msg/s per broker. Reserve 30% CPU for compaction and rebalance.
Disk: IOPS critical. On AWS, recommend gp3 EBS with provisioned IOPS or io2 for very high throughput. Capacity = retention days × daily volume × replication factor.
Partitions: max 1000-2000 per broker (beyond that, degraded controller latency). For partner-order, partition by partner_id.
Network: 1-10 Gbps per broker. Replication traffic = N-1 × produce traffic.

PostgreSQL

Connections: max 200-300 active connections per instance, put PgBouncer in front to multiplex.
WAL: if using CDC (Debezium), keep WAL retention ≥ max consumer lag + 24h margin.
IOPS: 5 000-20 000 IOPS for a hub at 10M msg/month.
Read replicas: 1-3 replicas for CQRS projections and BI queries.

Network egress

EDI hubs consume significant egress bandwidth (cross-region broker publishing, AS4 sending to partners). On AWS, egress cost to internet is ~USD 0.09/GB for first TB, decreasing afterwards. For 100M msg/month × 5 KB average = 500 GB/month, i.e. ~USD 45/month. But with Kafka cross-region replication 3 inter-AZ replicas, cost can multiply tenfold.

Specific case: ViDA 2030 peak

On 1 July 2030 at midnight, ViDA Pillar 3 directive applies to all intra-EU B2B transactions. Consequences:

Tens of thousands of companies switch simultaneously to EN 16931 structured e-invoicing.
PEPPOL operators (Pagero, Storecove, Comarch, Sovos, B2Brouter) see their traffic potentially 5-10x in 24 hours.
Large group internal hubs (which until then emitted in PDF or bilateral EDIFACT) must switch their flows to PEPPOL.

Recommended anticipation plan:

2027-2028: pilots at 10% volume in parallel.
2029: gradual ramp-up to 50% volume.
H1 2030: 80% volume, full infrastructure regime.
30 June 2030: controlled maintenance window, reinforced on-call team, capacity at 200% nominal.
1 July: 24/7 monitoring, capacity at 300% of forecasts during the first week, decreasing thereafter.

Foundations

Standards

Flagship messages

Tools