Deployment Architecture of Apache OFBiz for B2B Manufacturing Business

Designing deployment architecture for Apache OFBiz deployments requires more than selecting cloud services or drawing architecture diagrams. At HotWax Systems, our DevOps team follows a structured process to build cloud infrastructure that scales reliably, maintains security, and performs consistently under real production workloads. This approach ensures every deployment aligns with the client's operational requirements and business processes from day one.

This document presents the technical architecture designed for a B2B industrial equipment manufacturer serving enterprise customers across North America. The architecture decisions documented here are grounded in our established infrastructure design process, detailed in two foundational engineering blogs:

• How Our DevOps Team Designs Scalable and Secure Cloud Infrastructure for Apache OFBiz – outlines the six-stage process we follow: discovery, analysis and system design, load testing, security, monitoring, and CI/CD planning.
• How the Right DevOps Discovery Questions Shape Apache OFBiz Architecture – explains the intent behind discovery questions and shows how those discussions inform infrastructure decisions around security, availability, scalability, and cost.

This document demonstrates how structured discovery and operational analysis translate into deployment architecture decisions for a B2B manufacturer with complex product configuration requirements, multi-channel ordering, and real-time manufacturing integration needs.

1.Client Overview

The client is a B2B manufacturer of configurable industrial equipment, serving enterprise customers across construction, logistics, and manufacturing sectors in North America. The business combines precision engineering with made-to-order manufacturing, supplying customized industrial equipment to corporations, distributors, and enterprise purchasing departments.

1.1 Business Model & Operations

1.2 Product Model

The manufacturer sells configurable industrial equipment built from modular components. Each product is assembled by combining a base unit, specialized components, and optional or mandatory accessories. This modular structure allows high customization while maintaining a consistent manufacturing and fulfillment process.

In addition to custom-configured equipment, the company also offers standard accessories and replacement parts through its online channel.

1.3 Sales and Ordering Channels

The manufacturer receives orders through three main channels. Each channel represents a different type of buyer and ordering method. The order flow and system activity for these channels are explained in more detail in the Load and Capacity Planning section.

• Dealer Orders Corporate customers usually place orders through authorized partner stores. The partner gathers customer requirements and enters the order in Apache OFBiz.
• Direct Online Orders Some business buyers place orders directly through the company's B2B web portal. They configure products and confirm the order using the online system.
• Large Enterprise Orders Large companies place bulk orders through their internal procurement systems. These orders typically arrive through punchout catalogs, EDI connections, or file uploads.

2. Infrastructure Requirements

To design deployment architecture for 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 Questions and Client Requirements

We will see how these details are finalized in the next sections.

3.Deployment Architecture Design and Load Analysis

Before estimating the 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.

Order Processing Flow

1. Order Entry Orders enter the system through multiple sales channels.
2. Order Transmission to Manufacturing Apache OFBiz sends the order details to a third-party manufacturing system for production.
3. Status Monitoring After the order is sent, Apache OFBiz periodically checks the manufacturing system for updates.
4. Manufacturing Status Updates The manufacturing system returns the latest order status, such as In Production, Finished, or Completed, which is then updated in Apache OFBiz.

Background Jobs Supporting the Flow

Several background services run continuously to support this process and keep systems synchronized:

• Manufacturing status processing

• Order import service

• Sales order report export to a third-party system

• Invoice export to a third-party system

• Data warehouse export

• Inventory reconciliation within Apache OFBiz

• System maintenance jobs in Apache OFBiz

• Database read and write operations during order creation and processing

Together, these processes ensure that orders move smoothly from entry to production while keeping all connected systems updated with accurate information.

3.1 Load Calculation and Capacity Planning

To design deployment architecture that performs reliablyunder real production conditions, we first analyzed how orders flow through the system across different channels. Understanding order volume, order patterns, and item quantities by channel is essential for accurate load calculation.

To start with, first order entry channels are identified and how much load each channel brings.

3.1.1 Order Entry Channels and Patterns

The manufacturer processes orders through three channels, each with distinct characteristics:

Note: A single order can contain multiple items; here items are referred to as equipment units

Channel 1 - Dealer Orders Authorized dealers place orders for business customers using the Apache OFBiz eCommerce system. This primary channel accounts for 210 orders per day, representing 70% of daily order volume. Every order has 5 to 8 equipment units.

Dealers navigate through product configuration screens to select base units, add required components, choose optional accessories, and apply corporate pricing agreements. The workflow requires multiple page loads as dealers move through configuration options and submit orders.

Channel 2 - Direct Online Orders Company buyers place orders themselves using the online portal. This channel gets about 15 orders a day. Each order has 2 to 4 equipment units. Buyers who know the products can configure them easily. The steps and pricing checks are the same as dealer orders.

Channel 3 - Large Enterprise Orders Big companies place bulk orders using punchout catalogs, EDI, or file uploads. About 75 orders arrive each day. Each order includes 15 to 25 equipment units. These orders often come in large batches and approval from the managers of the companies is needed before production starts.

3.1.2 Order Volume and Item Breakdown

For system planning, item count matters more than order count. Work increases with the number of items processed, not just the number of orders.

Daily Order Overview

What this means

• Enterprise procurement represents only 25% of orders but 51% of line items
• Partner dealer channel provides steady, predictable volume throughout business hours
• Deployment architecture must handle bulk order spikes from enterprise channel

During peak promotional periods, order volume increases to 400-500 orders per day, resulting in approximately 3,540-4,425 line items per day.

3.2 Load Calculation and System Capacity Planning

Once the total number of orders and number of items in each order is calculated, we move to how those orders are fulfilled and how much load this fulfillment generates.

3.2.1 User-Facing Request Load

User actions create page requests as they move through the Apache OFBiz web screens.

Daily order entry requests:

• B2B Partner Dealer: 210 orders × 5 page requests (search, configuration, review, submit) = 1,050 requests/day
• B2B Online: 15 orders × 4 page requests = 60 requests/day
• Enterprise Procurement: 75 orders × 3 page requests (import, validation, approval) = 225 requests/day
• Additional Activity: Product browsing, status lookups, inventory checks = ~300 requests/day

Total User-Facing Requests: ~1,635 requests/day

Each page request also runs several internal checks like pricing, inventory, and customer data. These do not create extra web requests, but they increase CPU and memory usage.

Expressed as requests per minute during business hours (8 hours):

• Normal day: 1,635 requests ÷ 8 hours ÷ 60 minutes = ~3.4 requests/minute average
• During peak window (9 AM-12 PM, 60% of traffic): ~5.5 requests/minute

3.2.2 Fulfillment and Manufacturing Integration Load

Fulfillment Processing: Handling each ordered item after the order is placed.

• Each item is handled separately.
• 2,655 items in a day create 2,655 fulfillment requests.

Manufacturing Partner Integration: After an order is placed, the system sends that order to an external manufacturing company software that will produce the items.

• Orders data sent to manufacturing partners: 300 orders create 300 requests per day.

Note: In this case, the client uses a third-party system to manage the manufacturing process. Orders created in Apache OFBiz are sent to the external manufacturing platform, which handles production and returns status updates.

However, this architecture is specific to the client's setup. In many other implementations, manufacturing is managed directly within Apache OFBiz. The platform includes built-in capabilities for manufacturing planning and execution, allowing businesses to manage production workflows, track operations, and monitor production runs within the same system.

Order status checks: The system keeps asking the manufacturing partner for updates on each order.

• The system checks status every 5 minutes during an 8-hour workday.
• This results in 96 requests per day.

Status updates from partners: After an order is sent to the manufacturing partner, they send updates back to the system.

• Each order sends about 2 updates.
• That adds up to 600 requests per day.

Total fulfillment and integration load: 2,655 Fulfillment requests + 300 Order creation requests + 96 Order status requests + 600 Status update requests = ~3,651 requests per day

Expressed as requests per minute:

• Total integration and fulfillment: 3,651 requests ÷ 8 hours ÷ 60 minutes = ~7.6 requests/minute

3.2.3 Background Job Execution

Background jobs are measured by execution time and throughput, not requests per minute.

Peak Batch Window (Midnight - 4 AM): Four major jobs run sequentially, requiring approximately 165 minutes (2 hours 45 minutes) of continuous processing.

3.2.4 Total System Load Summary

Normal Day (300 Orders, 2,655 Items):

Peak Day (450 Orders, 3,990 Items):

Total HTTP traffic increases to ~7,929 requests/day (~17 req/min average, ~30 req/min peak), while batch processing increases to ~6.4 hours/day.

Order Management Flow Load:

During business hours (8 hours), the order management workflow handles:

• User-facing order entry: ~1,635 requests
• Fulfillment processing: ~2,655 requests
• Combined order management load: ~4,290 requests during 8-hour window
• Peak rate: ~9 requests/minute average, ~18 requests/minute during peak hours

3.3 Peak Load Analysis: Operational Hours and Request Rates

Daily totals don't reveal real-time load infrastructure must handle. During operational hours, traffic concentrates during specific time windows.

3.3.1 Load Pattern During Business Hours

Most orders are placed during business hours, from 9 AM to 5 PM. Almost all daily system activity is packed into this 8-hour window.

• On a normal day, the system handles about 5,286 requests during these hours.
• This averages to about 661 requests per hour, or ~11 requests per minute

Dealer activity is highest in the morning, between 9 AM and 12 PM. Around 60 percent of daily orders come in during these three hours.

During this morning peak:

• On normal days, the system handles about 891 requests per hour, or ~15 requests per minute
• During promotions, this rises to about 1,337 requests per hour, or ~22 requests per minute

Concurrent user activity

At peak times, 15 to 25 users are active at the same time. This usually includes:

• 8 to 12 dealer users
• 3 to 5 customer service users
• 2 to 4 warehouse or logistics users
• 2 to 4 enterprise buyers

Each active user keeps memory, database connections, and search queries open inside the Apache OFBiz system. Together, this requires roughly 75 to 100 database connections during peak hours.

3.3.2 Database Transaction Impact

Apache OFBiz's entity engine translates each user action into multiple database operations. A single order creation involves 50-150 database transactions (inserts to ORDER_HEADER, ORDER_ITEM, PRODUCT_CONFIG, INVENTORY_RESERVATION, plus validation queries and status updates).

Database Load:

• Normal day (300 orders, 2,655 items): ~57,000 operations/day (~1,425 operations/minute at peak)
• Peak day (450 orders, 3,990 items): ~85,500 operations/day (~2,138 operations/minute at peak)

These database transaction patterns (not HTTP request counts) drive deployment architecture sizing decisions around database memory allocation, connection pooling, and Multi-AZ deployment.

3.4 Monolithic Architecture Strategy: Unified Server Design

For this deployment handling 300 orders per day with controlled batch processing windows, a unified server architecture efficiently manages both user-facing operations and background jobs on a single application instance.

3.4.1 Why a Unified Server Works for This Deployment

Traffic Pattern Separation: User-facing traffic concentrates during business hours (9 AM - 5 PM), handling order entry, product searches, and status lookups with peak activity during morning hours. Background jobs execute primarily during off-peak hours (midnight - 4 AM), processing reports, data exports, and system maintenance when user activity is minimal.

Resource Utilization: With 300 orders per day and 4.25 hours of daily batch processing, the workload fits comfortably within a single server's capacity. User-facing operations during the day utilize 20-30% of server resources, leaving ample headroom. Nightly batch jobs execute during a dedicated maintenance window when the system experiences minimal user traffic, preventing resource contention.

Load Characteristics: Peak user-facing load reaches approximately 22 requests per minute during promotional periods—well within the capacity of a properly sized compute-optimized instance. Background jobs run sequentially during the 4-hour nightly window, processing 300-450 orders without competing with real-time user operations.

When Workload Separation Becomes Necessary: At significantly higher volumes (1,000+ orders/day), continuous batch processing throughout business hours, or when background jobs exceed 6-8 hours daily, separating workloads across dedicated servers becomes advisable to maintain consistent user-facing performance.

3.4.2 Manufacturing Integration and Search Isolation

Manufacturing Integration: Manufacturing work is split based on timing requirements. New orders are sent to the third-party manufacturing system immediately after approval, ensuring production begins without delay. Order status checks run every 5 minutes as scheduled jobs during business hours, updating order progress without impacting user-facing performance.

Apache Solr: Apache Solr runs on a dedicated server to maintain fast search response times. Indexing operations are CPU-intensive and would impact query response times if running on the same JVM as OFBiz. This isolation ensures equipment searches remain fast (50-150ms) even during large catalog updates and enables Solr-specific JVM tuning.

3.5 Proposed Deployment Architecture

Based on load analysis and the monolithic architecture strategy, we propose the following deployment architecture for the production environment. This monolithic architecture deployment consolidates user-facing operations and background processing on a single unified application server.

3.5.1 Application and Search Servers

Scaling rules:

• The unified application server is upgraded to c6i.2xlarge (16 vCPU, 32 GB RAM) if CPU usage goes above 70 percent during normal business hours or if more than 40-50 users are active at the same time.
• This setup keeps user actions fast, background work stable, and gives enough room for growth without oversizing the system.

3.5.2 Database Configuration

Why 2 vCPUs are enough?

Even with 300 orders per day (450 during peaks), the database handles around 2,138 operations per minute at peak. CPU usage stays moderate during normal days and reaches 40-50% during promotional peaks. The database workload depends more on memory and disk speed than CPU, so adding more CPUs would not help much. The current configuration provides comfortable headroom for the projected load.

Storage planning:

The database starts with 100 GB of storage and grows automatically as needed.

• Expected data growth:
• About 15 GB in the first year
• Around 30 GB by the third year
• Another 20 to 30 GB for history and indexes

After three years, total usage is expected to stay within 60 to 80 GB, well within the 100 GB allocation with auto-scaling enabled.

Backup Policy: Automated daily backups (2-4 AM), 7-day retention, point-in-time recovery enabled, encrypted at rest (AWS KMS).

3.6 Network and Security Architecture

The system is split into three clear security layers:

• Public layer This includes the load balancer and a bastion host. Only the load balancer is open to the internet.
• Application layer This includes the unified application server, search server, and build server. These servers are not directly exposed to the internet.
• Data layer This includes the main database and the read replica. It is fully private and cannot be accessed directly.

Security controls are strict and minimal: The load balancer can talk only to the application servers using secure web traffic. The bastion host can access application servers only for secure login. Application servers can access the database only for database traffic. The database does not allow outbound access.

A web firewall protects the system from common attacks like SQL injection and script attacks. It also limits traffic spikes to prevent overload. All data is encrypted while moving between systems and while stored.

3.7 Monitoring and Observability

The full setup is monitored using AWS CloudWatch.

• Application servers are monitored for high CPU use, memory pressure, and disk usage.
• The database is monitored for CPU load, connection limits, storage usage, and replication delays.
• The load balancer is monitored for slow responses and error rates.
• All application logs are collected in one place for easy troubleshooting.

Alerts follow two paths:

• Non-urgent issues go to email.
• Critical issues trigger calls or messages through PagerDuty.

3.8 Scalability and Cost Optimization

Current capacity comfortably supports between 300 and 500 orders per day.

The unified application server runs at moderate CPU usage during normal days, leaving plenty of room for growth. Background jobs complete within the planned 4-hour nightly window. The database runs well below its limits for CPU and connections.

Scaling happens only when needed:

• The unified application server is upgraded to c6i.2xlarge (16 vCPU, 32 GB RAM) if CPU stays high during business hours or user load increases significantly beyond 40-50 concurrent users.
• The database is upgraded if CPU or connection usage rises consistently above recommended thresholds.

More servers can also be added if many users are active at the same time or if background jobs grow beyond the 6-hour safe limit.

Costs are controlled by reserving production servers for long-term use and using lower-cost instances for development and testing. Auto-scaling is used to handle busy seasons without paying for unused capacity.

4. Conclusion

The deployment architecture proposed for this B2B industrial equipment manufacturer demonstrates how structured discovery and operational analysis translate into production-ready deployment decisions for a 300 orders-per-day operation.

The unified server architecture efficiently handles both user-facing operations and background processing, with clear separation between business hours traffic and nightly batch windows. The infrastructure is optimized for the actual load patterns observed in B2B manufacturing operations, providing 3-4x headroom for growth while maintaining cost efficiency.