Load Balancing First: Why Traditional Industry Owners Should Resist the Microservices Jump
There is a recurring pattern in enterprise software upgrades: when a system needs to scale, the conversation jumps straight from "single-server monolith" to "full microservices transformation" — skipping over the more practical middle ground of horizontal scaling with load balancing. This article examines that middle ground from the perspective of the business owner, and explains why it is often the most rational choice.
1. Architecture Solves Specific Problems — Match the Tool to the Problem
The most common source of confusion in architecture discussions is treating different architectural patterns as interchangeable upgrades, when in fact they solve fundamentally different problems.
Multi-node load balancing addresses availability and horizontal scalability: when one server fails, traffic automatically routes to others; when user volume grows, adding nodes absorbs the additional load. The application code stays largely intact.
Microservices architecture addresses organizational complexity and release independence: large teams are split into smaller groups, each owning a distinct service, capable of deploying without coordinating with every other team. Its primary value is team efficiency at scale, not raw performance.
For most enterprise internal systems — ERP, MES, OA, CRM — concurrent users number in the hundreds to low thousands. The bottleneck is rarely raw throughput. What business owners actually need is high availability and controlled scalability, which load balancing delivers directly.
2. Honest Engineering: Load Balancing Requires Real Code Changes
It would be misleading to describe the monolith-to-load-balanced transition as "no code changes required." There are genuine engineering tasks involved, and they deserve clear-eyed assessment:
Session Management Centralization
In a single-server deployment, user session state lives in local memory. In a multi-node setup, every node must be able to read the same session data. The standard solution is migrating session storage to a centralized Redis instance. This is the most frequently underestimated work item.
Distributed Lock for Scheduled Tasks
If the application runs scheduled jobs — daily reports, periodic sync tasks, batch processing — deploying multiple instances will cause duplicate execution. The fix is introducing a distributed lock mechanism (Redis-based locks, or Quartz's cluster mode) to ensure only one node executes each job per cycle.
Local Cache Consistency
In-process caches (Guava, Ehcache) are node-local by definition. Multi-node deployments create the risk of stale or inconsistent cache state across nodes. The typical resolution is migrating hot-path caches to Redis, or explicitly accepting short-term inconsistency where business logic permits.
These are real engineering tasks, but they have well-defined boundaries. For a team with reasonable experience, assessment and implementation typically take four to eight weeks — a manageable window with clear validation criteria at each step.
3. Public Cloud Has Fundamentally Changed the Infrastructure Cost Equation
One historically valid objection to load-balanced architectures was cost: in the on-premise era, hardware load balancers (F5 and equivalents) were expensive, and running multiple application servers meant proportionally higher hosting costs. That objection is largely obsolete in a public cloud context.
| Component | On-Premise Era | Public Cloud Today |
|---|---|---|
| Load balancer | Hardware F5, tens of thousands upfront | Cloud LB service, usage-based billing, from a few hundred RMB/month |
| Application servers | Hardware purchase + hosting fees, fixed cost | ECS/cloud VMs, on-demand, horizontally scalable in minutes |
| Session/cache layer | Self-hosted Redis, manual ops | Managed Redis, SLA-backed, zero ops overhead |
| Database | Local or co-located, self-managed backup | Cloud RDS with auto-backup, read replicas, HA built in |
Public cloud shifts infrastructure operations to the provider. The monthly baseline cost of a load-balanced two- or three-node deployment is well within budget for most mid-sized enterprises, with no upfront capital commitment and the ability to scale down when demand drops.
4. What Microservices Actually Requires — A Realistic Assessment
Microservices are not a bad architecture. They are the right architecture for specific conditions, and those conditions are worth stating precisely.
High Code Invasiveness
Microservices transformation requires decomposing an existing system into independently deployable services — redesigning service boundaries, defining inter-service APIs, and often splitting the database. For systems that have accumulated years of business logic, this is high-risk work with difficult-to-predict timelines. It is not uncommon for estimates of six months to extend to two years in practice.
Substantial Operational Infrastructure
A production-grade microservices environment requires: service registry and discovery (Nacos, Consul), API gateway, centralized configuration management, distributed tracing (SkyWalking, Jaeger), and typically a message broker. Each component adds operational surface area, requires dedicated expertise, and represents an additional failure point.
Team Capability Requirements
Microservices architecture is difficult to operate well. Organizations without prior experience frequently encounter subtle failure modes — cascading timeouts, partial failures, distributed transaction edge cases — that are much easier to introduce than to diagnose. When evaluating supplier proposals, requesting evidence of comparable delivered projects is a reasonable due diligence step.
5. A Decision Framework for Business Owners
Architecture selection should be driven by current business needs and team capabilities, not by trend or supplier preference. The following heuristics are a starting point:
Load balancing is likely the right choice when:
- Concurrent users are in the hundreds to low thousands
- The primary requirement is fault tolerance and automatic failover, not elastic scaling
- The development team has fewer than 20 engineers
- Delivery timeline needs to be contained to one to three months
- The organization does not have dedicated infrastructure operations capability
Microservices may be worth considering when:
- Daily active users exceed 100,000
- Specific modules require independent deployment or scaling on different cadences
- A mature DevOps function exists (separate development, operations, and SRE roles)
- Observability infrastructure (logging, tracing, metrics) is already in place
6. Recommended Path: Staged Evolution
Architecture does not need to be solved in a single transformation. A staged approach reduces risk and allows each phase to be validated before committing to the next:
Phase 1 — Load-balanced monolith:
Migrate session storage to Redis, add distributed lock for scheduled tasks, deploy two to three application nodes behind a cloud load balancer. Validate availability and performance under realistic load.
Phase 2 — Selective service extraction (if needed):
Identify modules with genuinely distinct scaling profiles or release cadences. Extract those as independent services while leaving the core monolith intact. This is the "strangler fig" pattern — incremental, reversible, and risk-proportionate.
The value of this approach is that each phase has a clear cost, a defined scope, and measurable outcomes. Business owners can make go/no-go decisions at each boundary rather than committing to a multi-year transformation upfront.
Conclusion
For traditional industry software serving enterprise-scale workloads, load-balanced horizontal scaling represents the most cost-effective upgrade path available today. The engineering work is real but bounded. On public cloud, the infrastructure costs are controlled and proportional to actual usage. The operational complexity stays within what most teams can manage.
Jumping directly to microservices typically brings organizational and operational overhead that is disproportionate to the problems being solved — at least until the business genuinely outgrows what a well-operated distributed monolith can handle.
When reviewing supplier proposals, the most useful questions are not about which architectural buzzwords appear in the document. They are: what specific problem does this architecture solve for us today, what does the engineering scope look like, and what does the supplier's track record with comparable deployments look like?
Those answers tend to be more revealing than the architecture diagram.
Top comments (1)
Load balancing first is a pragmatic recommendation. A lot of businesses do not need microservices; they need clear capacity limits, safer deploys, simpler rollback, and fewer places for ownership to disappear.