Load Balancing
Multiple instances need suitable distribution of new requests and work.
- Target poolTarget pool: Three illustrative shop instances provide the same service.
- Distribution policyDistribution policy: Round robin selects the next healthy target for each new request.
- HealthHealth: The simplified health check immediately removes a failed target from the pool.
Context
Why this is important
Load balancing keeps new shop requests flowing when multiple instances provide the same service. The distribution policy and health check jointly determine which target receives the next request.
Distribute new work across suitable available targets.
Distribute new requests with round robin
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. The shop runs three web instances behind a load balancer. New cart requests are distributed, and instances with failing health checks temporarily receive no new traffic. In-flight payment requests remain traceable by business identifiers even if an instance fails. A load test checks distribution, zone loss, and restoration of healthy targets. The instance count is a test configuration, not a production capacity claim.
This is how you read the picture
- Target pool three shop instances
- Distribution policy A → B → C
- Health Health Check
- Shop Ahealthy · next target0assigned
- Shop Bhealthy · in target pool0assigned
- Shop Chealthy · in target pool0assigned
Simplified health checkAll three targets are considered healthy and receive new requests.
Ready. Next target: Shop A.
Model boundaryThis model distributes new requests. It does not recover in-flight requests or resolve the shared database bottleneck.
Topology and values are illustrative
Benefits & limitations
Helps if:
- Distribute new work across suitable available targets.
- Test health checks, distribution policy, and session requirements together.
Boundaries
- Poor health checks can remove healthy targets or retain unhealthy ones.
- Distribution improves use of suitable targets but fixes neither a shared database bottleneck nor poor session state.
In practice
- Check whether the health check detects a real web-instance failure and whether the load balancer removes failed targets without mistaking brief load spikes for failure.
- Compare the routing policy under even load and zone loss; verify that cart state is not accidentally tied to one instance.
- Run order and payment requests during failure and recovery, and check that domain identifiers keep outcomes traceable despite target changes.
Read the detailed explanation
Load balancing distributes requests or units of work across multiple available targets. Selection policies such as round robin, weighted distribution, or least connections suit different traffic patterns.
Health checks can remove targets from traffic, while session affinity, zones, capacity, and failure domains shape distribution. A balancer creates no capacity; downstream services must be able to handle the load.
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. The shop runs three web instances behind a load balancer. New cart requests are distributed, and instances with failing health checks temporarily receive no new traffic. In-flight payment requests remain traceable by business identifiers even if an instance fails. A load test checks distribution, zone loss, and restoration of healthy targets. The instance count is a test configuration, not a production capacity claim. gateway and failure detection help compare this decision with adjacent concerns.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which instance receives the fourth request when all three targets are healthy?
View the solution with justification
Shop A. After A, B, and C, round robin returns to the first healthy target.
ApplyingTransferred to a new situation
What sequence results once Shop B is removed from the target pool?
View the solution with justification
New requests alternate between Shop A and Shop C. The previous assignment counts remain visible as history.
EvaluateWeighing an alternative
Which two simulation boundaries belong in a real failure test?
View the solution with justification
Recovering in-flight requests and assessing shared database capacity require separate mechanisms and measurements.
Ten times more orders
Compare capacity, distribution and bottlenecks in the shared learning example.
Explore scaling in the shopExplore further
These building blocks continue the thoughts of this page.