NETWORKING / LOAD BALANCER
Define how user requests reach multiple application servers. A Load Balancer architecture covers more than routing: sessions, uploaded files, health checks and consistent backend behaviour all influence whether the application works correctly across its targets.
01 / Overview
Load balancing distributes incoming traffic among defined targets. A user should receive the correct response regardless of which application server handles the request. If sessions or uploaded files exist on only one server, address that dependency as part of the architecture.
Treat traffic distribution as one part of application scaling and continuity. Verify supported protocols, routing, TLS and health-check options against the service scope. A balancer does not automatically solve database capacity or incorrect application state management.
Specify the targets and conditions for routing user requests. Separate the responsibilities of the entry point from those of the application servers.
Plan sessions, files and configuration for a multi-server deployment. Verify that the same release produces the intended result on every target.
Test adding a target or removing one for maintenance. Observe the effect on existing connections and background work.
02 / Architecture
Illustrative architecture: requests reach application targets while session and data dependencies are designed separately. Target count and failover behaviour are not service guarantees.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Protocol and connection type | Identify HTTP, TCP or long-lived connection requirements. | Supported traffic features must match application behaviour. |
| Sessions and shared data | Define where sessions, uploaded files and persistent records live. | Reaching a different server should not appear to lose user data. |
| Health checks | Define what makes a target ready to serve real requests. | An open port may not indicate that application dependencies are working. |
| TLS and client information | Confirm encryption boundaries, certificate maintenance and client-IP forwarding. | Security, logging and access rules depend on this design. |
04 / Use cases
Plan for requests reaching different application servers. Assess how sessions and user files avoid becoming tied to one machine.
Review request duration, timeouts and retries. Check the effect on data if an operation is attempted more than once.
Test the application and data layers together with representative traffic. Measure whether additional application servers address the actual constraint.
05 / From planning to operation
Inspect sessions, files and data access. Identify local assumptions that prevent the application from running across multiple servers.
Choose supported protocols, targets and checks. Record the required DNS and certificate changes.
Observe a target that fails or responds slowly. Evaluate new requests and established connections separately.
Monitor the transition. Track response time, errors and data-layer usage together while validating the new path.
Traffic distribution and provisioning servers are different operations. Confirm the scope of any scaling features separately, and plan capacity from measured application demand.
It depends on state management. Local sessions, files, scheduled jobs and shared data access must be reviewed for a multi-server design.
Choose a check that represents the ability to serve users. Consider dependencies and false failures, and verify the methods supported by the service.
That depends on the architecture and supported features. Define encryption between client, balancer and application together with responsibility for certificates and private keys.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Load Balancer
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.
