Many Apache OFBiz deployments in production were built on a monolithic architecture. When these systems were set up, typically five to eight years ago, that decision was reasonable. Transaction volumes were lower, integrations were limited, and a single well-sized machine could handle everything the business required.
Over time, businesses grow. Order volumes increase, new integrations come online, background jobs multiply, and data accumulates. The architecture does not change with it. The same machine that worked well under moderate load is now carrying significantly more, and the risks that come with a monolithic server setup become harder to ignore.
This blog explains what those risks are, how they manifest in a production Apache OFBiz environment, and what a distributed architecture addresses in response.
What is a monolithic server architecture?
In a monolithic server setup, all major system components run on a single machine. This includes the web layer, application services, database, background job processing, and third-party integrations. All of these share the same CPU, memory, and storage resources.
For example:
A typical early-stage Apache OFBiz deployment on AWS might run on a single instance provisioned with adequate CPU and memory resources. For an environment with moderate order volumes and a limited number of integrations, this configuration is sufficient. The problem is not the initial decision. It is what happens when operational demands grow beyond what the architecture was designed to handle.
Operational risks in a monolithic server setup
Single point of failure across all components
When applications like Apache OFBiz, Tomcat, MySQL, Solr, and background jobs all run on the same machine, any failure on a single application/process can take down all other applications and if that requires a server restart takes every component down simultaneously. This is due to no separation between the application layer, the database, and background jobs. A restart to resolve one issue stops all of them.
In a distributed setup, a failure in the background jobs running on separate machines does not affect the application server or the database. On a monolithic server, the boundary between components does not exist at the infrastructure level.
Shared resources create contention across workloads
Every process running on the machine draws from the same pool of CPU and memory. When multiple processes are active at the same time, they compete for available resources.
An application for search indexing operation can spike memory usage and slow down application response.
A long-running background job that does not complete, holds memory in JVM/ System while user-facing transactions continue queuing.
A heavy MySQL query places additional pressure on the same memory the application depends on. These are not independent problems. They are the same underlying problem: a single machine carrying workloads that have different resource profiles and different criticality levels, with no isolation between them.
In practice, a background service that runs continuously can consume enough memory to make the application layer unresponsive. Resolving this requires logging into the server, identifying the stuck process, and restarting the affected services manually.
The time between an issue starting and an engineer receiving a notification, identifying the root cause, and resolving it can be significant. During that window, operations continue to be affected.
These issues rarely occur in isolation. Resource contention slows down the system, queues begin to build, memory pressure increases, and background jobs take longer to complete. What starts as a localized issue can quickly escalate into a system-wide failure.
Disk saturation affects the entire server
On monolithic systems, logs, temporary indexing files, and application data all occupy the same storage volume. All components write to the same disk without isolation, so storage used by Solr, the database, and the application accumulates in a single shared volume.
A 300 GB disk can fill up due to temporary files from applications like Solr that are not cleaned up at regular intervals, eventually exhausting disk capacity and causing the server to stop responding to queries. Recovery requires identifying the source of the consumption, clearing enough space to bring services back online, and then completing a full cleanup pass.
Most monitoring setups in monolithic systems alert only after the server goes down, not when disk usage is approaching a critical threshold. By the time the alert is triggered, the machine has already stopped.
Recovery depends on manual intervention
Managed database services and container orchestration platforms handle restart logic, failover, and recovery automatically as part of the infrastructure. Monolithic server setups can support recovery mechanisms too, watchdog processes, init system restarts, and external monitoring tools can all be configured to detect failures and bring services back up. The difference is not capability, but complexity and operational overhead.
In a distributed system, recovery is a first-class concern built into the platform itself. In a monolithic setup, it has to be deliberately engineered and maintained on top of the infrastructure. When something goes wrong in a less mature or manually managed monolithic environment, recovery often falls back on an engineer logging in, reading logs, identifying the root cause, and restarting services by hand, a process that adds to downtime and operational burden at scale.
Disaster recovery has limited options
A monolithic system without any backup instance / machine on different regions has a single point of failure at the infrastructure level. If the region experiences a hardware failure or a network disruption, there is no replica to recover the data loss. A backup system can take over as the primary system in the event of a failure. Without one, recovery is slower, operational disruption is longer, and the risk of data loss increases.
Some deployments carry regulatory constraints that affect how this risk can be mitigated. Australian data residency requirements, for example, restrict where application data can be stored, which limits the option of cross-region replication. These constraints are real and need to be accounted for in the architecture design. For deployments without such restrictions, keeping both production and the only available backup in the same physical region is a risk that increases as the business scales.
Scaling requires upgrading the entire instance
When a monolithic server needs more capacity, the only option is to upgrade the full instance. More cores, more RAM, a larger disk. This operation scales every component together, regardless of which one is actually under load.
In a distributed architecture, individual tiers can be scaled independently. If asynchronous processing is consuming too much CPU, capacity can be added to that node without touching the application server or the database. If database query volume increases, the database can be scaled or replicated without affecting the compute tier. A monolithic server does not support this kind of targeted scaling.
Network segmentation is not practical on a single machine
In a distributed architecture, components are isolated by default. The database runs in a private subnet with no public internet access. The application layer sits behind a load balancer and a web application firewall (WAF). The background jobs communicate only with the services it needs to fetch or send the queries.
On a monolithic server, the database, application layer, and background job processing environment all share the same network boundary. Access can be controlled through ports, but there is no internal network segmentation. Fine-grained isolation of sensitive components is not practical without separating them into different environments.
Deployments affect the entire running environment
Most monolithic server deployments use script-based deployment processes. The engineer provides branch or tag details, runs the script on the server, and the change is applied directly to the live environment. A staging setup can be used, and rollback is possible, but rolling back is a manual and tedious process. There is also no isolation between the deployment process and the services currently handling production traffic.
If a deployment introduces a problem, every component on the machine is affected immediately. In a distributed setup with structured CI/CD pipelines, staging validation is built into the pipeline before changes reach production, rollback is automated, and a failed release in one layer does not affect others running alongside it.
What a distributed architecture changes
Moving to a distributed architecture addresses the risks above by separating components that currently share the same machine into dedicated environments. This separation introduces isolation between workloads, ensuring that failures in one layer do not impact others.
A typical distributed setup for Apache OFBiz separates workloads as follows:
- Load balancing and entry point isolation: A load balancer handles incoming traffic and provides a first layer of redundancy
- Dedicated application layer: Primary, user-facing transactions run on a dedicated application server
- Isolated background processing: Background job processing runs on a separate node, isolated from live transaction traffic
- Managed and resilient database layer: The database runs on a managed service such as AWS RDS, which handles automated backups, read replicas, and failover
- Separation of supporting services: Third-party integrations like Apache Solr run on separate machines to prevent additional load on the application layer
- Perimeter security: A web application firewall sits in front of public-facing endpoints
- Component-level monitoring: Monitoring tracks disk usage, memory pressure, queue depth, and service health at the component level
This separation ensures that each component operates independently. Disk exhaustion in one layer does not affect the database. A stuck background job does not make the application unresponsive. A database failure triggers automated failover rather than a manual restore process.
The infrastructure cost of this setup is slightly differ from a monolithic system deployment. A managed RDS instance, a separate background jobs node, and supporting services increase the monthly bill. The increase in cost is predictable. The cost of downtime is not.
Deciding to move to a distributed architecture is one step. Designing that architecture correctly — including workload analysis, load testing, security boundaries, monitoring, and CI/CD planning — is a separate and equally important process. The HotWax Systems DevOps team has documented that process in detail: How our DevOps team designs scalable and secure cloud infrastructure for Apache OFBiz.
Conclusion
If your Apache OFBiz deployment was designed several years ago on a monolithic system, the architecture itself may not have changed even as the operational load on it has grown considerably. The risks described in this blog are not theoretical. They reflect failure patterns that appear consistently in long-running monolithic deployments as business volume increases.
The questions worth asking are straightforward: What is the recovery path if the server goes down tonight? Is there a database replica? Is monitoring covering component-level health or just server availability? Are deployments isolated from the live environment?
HotWax Systems has worked on Apache OFBiz infrastructure across a range of deployment configurations, including assessments and migrations from single-server setups to distributed architectures. If you are evaluating your current infrastructure and want to understand what an upgrade path looks like for your environment, we are glad to walk through it with you.
Book a consultation with the HotWax Systems team
