Apache HTTPD / Trust, correctness, and reviewed change / Lesson 15

Balancer members, health, and failure semantics

Choose routing and recovery contracts without assuming that retrying another backend reverses a failed business operation.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Identify balancer, protocol, scheduler, and optional health-check prerequisites.
Separate member availability, session state, and request repeatability.

A balancer is a configured set of backend choices

mod_proxy_balancer works with mod_proxy, protocol providers, and scheduler modules. A logical balancer name does not create backend capacity or prove that members are equivalent. Parcel’s two synthetic API nodes need compatible application versions, configuration, data, and public URL behavior. Review connection pools and downstream limits in the actual MPM and module context. A frontend with more routing choices can still overload a shared database or external carrier. This course configures no live pool and contacts no member.

Read a non-runnable member definition

The fragment below names two reserved nonworking HTTP backends and a byrequests scheduler choice. It assumes the relevant balancer, protocol, scheduler, and supporting modules for the actual build. No balancing result or traffic distribution is claimed. The illustrative mapping omits a complete virtual host, access policy, health strategy, session contract, and timeout design. A real owner must verify these prerequisites rather than treating two BalancerMember lines as proof of high availability.

apache A synthetic balancer fragment

<Proxy "balancer://parcel-lab">
    BalancerMember "http://node-a.example.invalid:9000"
    BalancerMember "http://node-b.example.invalid:9000"
    ProxySet lbmethod=byrequests
</Proxy>
ProxyPass "/api/" "balancer://parcel-lab/"
ProxyPassReverse "/api/" "balancer://parcel-lab/"

No DNS, pool, connection, request, session, or scheduler is executed. The sample is not a complete deployment or a universal scheduler recommendation.

Availability signals have a defined scope

Passive failure observations and optional active health checks answer different questions. mod_proxy_hcheck is documented for Apache 2.4.21 and later and requires its supporting module context; availability must be checked on the installed build. A health endpoint can pass while a purchase path fails, and a temporary dependency incident can affect every member. Define bounded checks, failure thresholds, recovery behavior, and evidence retention for the actual service. Do not prescribe one interval or threshold universally or use a health check as permission to generate uncontrolled load.

Sessions and retries can cross business boundaries

Sticky routing can help a declared session design but does not replicate state or make a failed member’s data available elsewhere. Retrying an idempotent read differs from repeating a purchase after an uncertain response. A backend can complete work before the frontend loses the reply. Preserve operation identity and the application’s deduplication or compensation contract. Long-lived or upgraded connections also have different routing and capacity behavior. Protocol support and patch-level differences must be reviewed rather than assumed from a generic HTTP proxy example.

Select declared available members without a scheduler claim

The complete local program filters a synthetic member list by declared readiness and capacity. It does not implement byrequests, weighted load balancing, Apache worker states, health probes, connection reuse, failover, or session affinity. Its narrow point is that configured membership and current eligible capability are different facts. Real validation needs the actual scheduler and workload contract through an authorized environment. Keep member failure, all-members-unavailable, recovered-member, session, and uncertain-write cases in the review plan before claiming resilient service behavior.

python A synthetic member-eligibility filter

members = [{"name": "lab-a", "ready": True, "free": 0}, {"name": "lab-b", "ready": True, "free": 2}, {"name": "lab-c", "ready": False, "free": 3}]
eligible = [m["name"] for m in members if m["ready"] and m["free"] > 0]
print(eligible)
print("selection model only")

Expected output

['lab-b']
selection model only

Only dictionaries are evaluated. No health request, backend, scheduler, balancing algorithm, or network operation is tested.

Common errors and fixes

Two configured members are described as guaranteed high availability.

Why it happens: Membership was substituted for compatibility, health, state, and shared dependencies.
How to fix it: Review the complete failure and recovery contract with backend owners.
Prevent it next time: Test member and shared-dependency failures under an authorized plan.

A timed-out purchase is automatically replayed on another member.

Why it happens: Transport failure was confused with absence of business completion.
How to fix it: Use application-level identity and safe repeatability rules before retrying.
Prevent it next time: Retain uncertain outcomes and authoritative reconciliation paths.

A simple readiness filter is claimed to validate byrequests distribution.

Why it happens: A local model was stretched into the real scheduler implementation.
How to fix it: State its limited scope and validate actual module behavior separately.
Prevent it next time: Keep eligibility and scheduling evidence distinct.

Check your understanding

1. A member is configured and healthy but has no declared free capacity in the model. Is it selected?

Show worked solution

No under this synthetic filter. That does not predict Apache’s actual scheduler or queueing behavior. Review real worker states and policy with appropriate evidence before making a capacity or failover claim.

2. Does session stickiness restore state after a node fails?