In our previous deployment architecture case study, we examined how structured discovery and capacity planning guided infrastructure decisions for a B2B industrial equipment manufacturer operating at 300 orders per day. That deployment employed a monolithic architecture — a unified application server handling both user-facing operations and background processing — which efficiently served the client's operational patterns where batch jobs ran during dedicated off-peak windows.
This document presents a contrasting scenario: a B2C operation processing up to 11,500+ orders per day during peak seasons, where continuous order influx, warehouse operations with concurrent users across multiple fulfillment centers, and batch processing running alongside user-facing operations during business hours necessitate a distributed architecture that separates user-facing workloads from resource-intensive batch processing.
The architecture decisions documented here follow the same structured methodology detailed in our foundational engineering blogs:
This case study demonstrates how business model differences — B2C vs. B2B, continuous operations vs. batch windows, inventory-intensive fulfillment vs. manufacturing operations — translate into distinct deployment architecture patterns. While the discovery methodology remains consistent, the infrastructure recommendations diverge based on actual operational load patterns, user concurrency, and processing requirements.
The client operates a high-volume B2C business delivering products requiring complex inventory tracking and multi-facility fulfillment. Operations span two fulfillment centers with significant seasonal demand variation and just-in-time fulfillment requirements.
| Field | Details |
|---|---|
| Business Type | Selling products on B2C e-commerce with multi-facility fulfillment |
| Core Operations (Apache OFBiz) | Warehouse management focused on D2C order fulfillment, including pickwave planning engine, internal stock replenishment engine, picking, packing, shipment, stock transfers, and inventory management. |
| Markets | North America (United States) |
| Order Volume | ~900–11,500 orders/day (seasonal variation) |
| Sales Channels | E-commerce storefront (B2C direct orders) |
| Fulfillment Model | Multi-facility fulfillment with complex inventory management |
| Key Integrations | Data hub layer, e-commerce platform, GCP Pub/Sub (messaging), ERP (planned) |
| Cloud Platform | Amazon Web Services (AWS) |
The business manages products requiring component-level inventory tracking to enable strict lot management, quality control, and operational compliance throughout the fulfillment process. This granular inventory management is essential for business requirements and customer satisfaction.
During peak seasons (major holidays), the company expands its product line with seasonal offerings and themed packages. Products require assembly operations through work orders before final shipment.
Orders arrive exclusively through the e-commerce storefront. Orders flow through a centralized data hub before reaching Apache OFBiz for fulfillment.
Order Flow Architecture:
The data hub acts as the system of record for all data exchanges. All inventory updates, fulfillment statuses, and product information flow through the data hub before reaching the e-commerce platform or other integrated systems.
To design deployment architecture for this client, we first needed to understand the expected load and usage patterns through a structured discovery process. The senior architecture designer and developers from the HotWax team held detailed discussions with the client, exploring requirements through a comprehensive set of discovery questions.
Below is a summary of key questions explored and the finalized deployment requirements. To learn more about this discovery process and the methodology behind these questions, click here.
| Discovery Area | Key Questions | Client Requirements |
|---|---|---|
| Order Volume | Expected transaction volume during normal and peak periods? | 900–11,500 orders/day. Low Season: Mon 7,000 / Wed 2,600 / Fri 900. Peak Season: Mon 11,500 / Wed 5,200 / Fri 4,400. Peak hours: 10 AM–2 PM |
| Services & Operations | Which services are used? Number of fulfillment centers? | WMS (primary), Inventory Master with lot tracking, Manufacturing/Work Orders. Two fulfillment centers in different US regions |
| Sales Channels | Order entry methods and volumes per channel? | E-commerce storefront (B2C). Orders through data hub → Apache OFBiz via GCP Pub/Sub. Import every 10 min (8 AM–5 PM) |
| Users & Concurrency | Number of warehouse and admin users? | 70+ warehouse users (PWA apps), 20+ admin users. Operations 9 hrs/day, 7 days/week |
| Availability | Expected uptime and SLA? | Highly available with zero downtime during operational hours |
| Infrastructure | Required servers and hosting? | 2 OFBiz servers (primary + batch), 1 Solr, 1 RDS (MySQL), 1 Jenkins. Hosted on client's AWS account |
| Platform | Cloud platform and region? | AWS, US region. Restricted-access WMS tool |
| Batch Processing | Batch requirements and job schedules? | Order import (every 10 min), routing (every 15 min), pick waving (every 20 min, 6 AM–4 PM), replenishment (every 30 min), inventory sync (hourly), fulfillment updates (every 5 min) |
| Database | Database availability and disaster recovery policy? Reporting requirements? | Amazon RDS (MySQL), Multi-AZ, automated backups (7-day retention), Read Replica for reporting |
| Integrations | External system integrations? | Mostly outbound to data hub via GCP Pub/Sub: order fulfillment, inventory updates, order update/rejection |
Before estimating system load, it is important to first understand how orders flow through the system and how Apache OFBiz operates behind the scenes for this client.
Together, these processes ensure that orders move smoothly from entry to fulfillment while keeping all connected systems updated with accurate information.
To design deployment architecture that performs reliably under real production conditions, we first analyzed how orders flow through the system across different operational patterns.
The company experiences significant seasonal variation in order volume, with major holiday periods driving peak demand:
| Season | Day | Orders/Day | Items/Order (avg) | Total Items/Day |
|---|---|---|---|---|
| Low Season | Monday | 7,000 | 8 | 56,000 |
| Low Season | Wednesday | 2,600 | 8 | 20,800 |
| Low Season | Friday | 900 | 8 | 7,200 |
| Peak Season | Monday | 11,500 | 8 | 92,000 |
| Peak Season | Wednesday | 5,200 | 8 | 41,600 |
| Peak Season | Friday | 4,400 | 8 | 35,200 |
What this means:
Once the total number of orders and items per order is calculated, we move to how those orders generate system load across different operational areas.
User actions create API requests as warehouse staff and admin users interact with PWA apps and the commerce platform.
Warehouse User Load:
Admin/Commerce User Load:
Total User-Facing Requests:
Expressed as requests per minute during operational hours (9 hours, 8 AM – 5 PM):
Peak Window (10 AM – 2 PM, 5 hours, 60% traffic concentration):
Background jobs are measured by execution time (how long they run) and frequency (how often they run), not requests per minute. The "Daily Total Execution Time" column shows total execution time per day — how many minutes or hours these jobs consume processing orders and data.
| Job Name | Frequency | Exec Time | Daily Total | Calculation |
|---|---|---|---|---|
| Order Import (GCP Pub/Sub) | Every 10 min (8 AM–5 PM) | 2–10 min | 54–270 min | 54 runs/day × (2–10 min/run) = 108–540 min. Actual: ~54–270 min based on order volume |
| Order Routing | Every 15 min (continuous) | Variable (50 orders/sec) | ~15–230 min | 7,000 ÷ 50/sec = ~2.3 min; 11,500 ÷ 50 = ~3.8 min; 96 runs/day |
| Pick Waving | Every 20 min (6 AM–4 PM) | 4–10 min/batch | 120–300 min | 30 runs/day × 4–10 min/run |
| Replenishment | Every 30 min (5 AM–5 PM) | Variable (45/sec) | 24–48 min | 24 runs/day × 1–2 min/run |
| Inventory Sync | Hourly | 15 sec | 6 min | 24 runs/day × 15 sec |
| Fulfillment Status Updates | Every 5 min | Variable | 10–20 min | 288 runs/day × 2–4 sec/run |
| TOTAL | — | — | ~229–1,074 min/day (3.8–17.9 hrs/day) | 3.8–17.9 hours/day of batch processing |
Order Routing Execution Time Calculation:
Replenishment Execution Time Calculation:
Peak Batch Processing Window:
Unlike the B2B manufacturing case study where batch jobs ran during dedicated off-hours (midnight–4 AM), the B2C operation runs batch processing during operational hours:
Batch jobs overlap with warehouse operations, creating resource contention during business hours. This overlap is the primary driver for distributed architecture.
| Load Type | Daily Volume | Requests per Minute |
|---|---|---|
| User-facing requests | 32,000 requests | ~59 req/min avg, ~64 req/min peak |
| Background job execution | 3.8–6.5 hours/day | Batch processing |
| Load Type | Daily Volume | Requests per Minute |
|---|---|---|
| User-facing requests | 355,000 requests | ~658 req/min avg, ~710 req/min peak |
| Background job execution | 13–17.9 hours/day | Batch processing |
Critical Observation: Unlike the B2B manufacturing deployment where batch processing consumed 4.25 hours daily during dedicated off-hours, this B2C operation runs 13–17.9 hours of batch processing during operational hours, creating continuous resource contention with user-facing operations.
Daily totals don't reveal the real-time load infrastructure must handle. During operational hours, multiple workloads compete for system resources simultaneously.
Warehouse operations run 9 hours daily (8 AM – 5 PM), 7 days per week, with peak activity concentrated during the 5-hour window from 10 AM to 2 PM.
Concurrent User Activity:
Each active user maintains 2–3 database connections for PWA app operations, open pick lists, pack stations, replenishment tasks, and real-time inventory reservations. Combined concurrent activity requires approximately 140–210 database connections during peak hours.
Apache OFBiz's entity engine translates each user action into multiple database operations. The inventory tracking requirements amplify database load.
Order Processing – a single order involves:
Total: 50–70 database operations per order
Fulfillment – pick-pack-ship process for one order (8 items):
Total: 34–54 database operations per order fulfillment
| Scenario | Daily Volume | Operations/Minute |
|---|---|---|
| Normal day (900 orders) | ~93,600 operations/day | ~173 ops/min |
| Peak day (11,500 orders) | ~1,196,000 operations/day | ~2,280 ops/min at peak |
These database transaction patterns drive deployment architecture sizing decisions around database memory allocation, connection pooling, Multi-AZ configuration, and the critical decision to separate batch processing from user-facing operations.
This blog covers the client profile, the discovery process, and the load analysis — establishing what the system needs to handle and why a standard single-server deployment is not viable for this operation.
In another blog, we cover the actual deployment architecture that follows from this analysis: the distributed server setup, EC2 and RDS instance sizing and the reasoning behind it, network and security configuration, monitoring thresholds, and the scalability plan. To read it, see Designing the Distributed Deployment Architecture for High-Volume B2C Fulfillment.