Commerce Platform: Scalability Design for Peak Traffic in B2B Trade

B2B commerce platforms live or die on peak traffic days. Unlike consumer e-commerce, where traffic peaks are broadly predictable (Black Friday, holiday season), B2B commerce peaks are driven by business cycles: end-of-quarter procurement rushes, annual contract renewals, trade show order events, and seasonal campaigns that can arrive with days rather than months of notice. Deka Technology's Commerce platform is engineered for these patterns — and the scalability architecture we describe here was validated against a 10x traffic event during a client's annual procurement campaign.

Understanding B2B Traffic Patterns

B2B commerce traffic is spikier and more predictable in aggregate than consumer traffic, but less predictable in timing. A manufacturer's purchasing department may generate 80% of its monthly order volume in the last three days of the month. A distributor's annual conference generates 5x normal order volume in a 48-hour window. An ERP-integrated procurement portal may experience traffic spikes not from human users but from automated procurement systems placing batch orders simultaneously.

Our platform instrumentation collects traffic patterns per client, identifies peak event signatures, and uses this data to tune autoscaling parameters proactively. We do not wait for peaks to discover they exceed capacity.

Auto-Scaling Architecture on Kubernetes

The Commerce platform runs on Kubernetes with a three-layer auto-scaling strategy:

• Horizontal Pod Autoscaler (HPA): Scales individual service deployments based on CPU and custom application metrics (request queue depth, active sessions). HPA operates with a 15-second evaluation interval and a 3-minute scale-down stabilization window to prevent thrashing.
• Cluster Autoscaler (CA): Adds and removes nodes from the underlying Kubernetes cluster based on pod scheduling pressure. We use node pools with different instance sizes — baseline pool for steady-state traffic, burst pool with larger instances for peak events.
• KEDA (Kubernetes Event-Driven Autoscaling): For order processing workers that consume from message queues, KEDA scales worker pods directly based on queue depth. When a bulk order import event drives queue depth above threshold, KEDA scales workers within 30 seconds.

Redis Caching Layers

The Commerce platform implements three Redis caching layers, each with distinct TTL and invalidation strategies:

• Product catalog cache: Catalog data, pricing, and availability — TTL of 5 minutes with event-driven invalidation on admin updates. This layer absorbs the majority of read traffic under peak load.
• Session and cart cache: Active user sessions and shopping carts — TTL of 30 minutes with sliding expiry. Redis Cluster for HA; cart data is also persisted to the primary database asynchronously.
• Computed aggregates cache: Order history summaries, account-level pricing rules, approval workflow state — computed on write and cached until invalidated by the relevant write event.

Our cache hit ratio under peak load averages 94% for catalog reads. At 10x normal traffic, this ratio prevents roughly 90,000 additional database reads per minute from reaching the primary database layer — the difference between graceful handling and cascading failure.

Database Read Replicas and Connection Management

The primary database cluster (PostgreSQL on managed cloud infrastructure) is fronted by PgBouncer connection pooling, with read replicas handling all non-transactional reads. During peak traffic events, read replica count scales automatically via cloud provider APIs triggered by CloudWatch/Azure Monitor metrics. Write operations go exclusively to the primary, protected by connection limits and query timeout enforcement. Long-running reports and exports are queued and executed against dedicated read-only replicas that are isolated from the transaction path.

CDN Strategy and Load Testing

Static assets and catalog images are served exclusively from CDN edge nodes (Cloudflare), with cache-control headers tuned to maximize CDN cache hit rates. API responses that are safe to cache (product search results, category trees) carry Cache-Control: public, max-age=300 headers for CDN caching at the edge.

Before every major peak event, we run load tests using k6, simulating 10x expected concurrent users with realistic order placement flows. The test suite includes ramp-up scenarios, sustained peak scenarios, and spike scenarios (instantaneous jump to peak). Our load test target for the Commerce platform is 100% of expected peak traffic handled within P95 latency SLAs, with zero 5xx responses. The 10x event referenced above was preceded by a load test that predicted the exact bottleneck — a connection pool limit on a third-party payment gateway — which was resolved before the event began.