Load Balancer
A load balancer spreads traffic across service endpoints that are ready to work. It uses rules for server health, capacity, routes, and uptime.
Another example
A ticket launch gets 18,000 requests each second. The balancer ends TLS, keeps trace context, and sends only idempotent health checks. It removes a server after repeated failures. During deploys, it drains 90-second connections. Retry limits stop one slow service from multiplying traffic.
Main parts
- 01Listener and routing rules
- 02Healthy backend pool
- 03Distribution and failure policy
Use it when
Use it to share demand and keep traffic away from unhealthy servers. Test health checks, draining, timeouts, retries, and observability rules.
Do not use it when
Balancing does not create more capacity. Do not depend on sticky sessions without failure rules or let retries repeat non-idempotent writes.
Name used in code
listener + routing policy + backend pool + active/passive health + drain/retry budgets Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Load Balancer for this system while keeping data correct, secure, and easy to operate. User context: A ticket launch gets 18,000 requests each second. The balancer ends TLS, keeps trace context, and sends only idempotent health checks. It removes a server after repeated failures. During deploys, it drains 90-second connections. Retry limits stop one slow service from multiplying traffic. Technical concept or control: Load Balancer. Why it fits: Use it to share demand and keep traffic away from unhealthy servers. Test health checks, draining, timeouts, retries, and observability rules. Do not use it when: Balancing does not create more capacity. Do not depend on sticky sessions without failure rules or let retries repeat non-idempotent writes. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Load Balancer. Definition: A load balancer spreads traffic across service endpoints that are ready to work. It uses rules for server health, capacity, routes, and uptime. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.