Load Balancers

Hook

A dispatcher shares a line across healthy counters while all counters still depend on the same stockroom.

Watch

Spread work without inventing downstream capacity. Use the validated parameter controls or edit the JSON scenario, then select Load input to recompute the trace.

How it works

Watch round-robin app processing, per-replica work counts and the separate database budget. Losing one app instance reduces available app capacity; extra instances do not make a failed database healthy.

Every visible outcome comes from the displayed state model. Timings, capacities and failures are illustrative assumptions, not cloud benchmarks or production-protocol guarantees.

Try it

Predict the next admission, delivery, cache, ownership or coordination decision. Introduce one failure at a time and account for every accepted, rejected, pending or committed outcome.

Complexity

The player separates operation counters from architectural trade-offs. State size follows the active keys, tasks, nodes or retained history; the references use bounded scenarios. Container choices and presentation scans can affect simulator costs.

Code

The four references implement the core model or its decision round. Queue/inbox and local ledger atomicity are explicit assumptions. Distributed deployment additionally needs durable shared state, complete protocol rules and operational validation. Reference inputs are fully validated/defaulted by the lesson; standalone callers must provide the shown fields.

When to use

Use to reason about healthy-target routing, capacity and where a balancing layer belongs.

Interview pitfalls

This model demonstrates round-robin healthy-target distribution, not every provider’s connection, session-affinity or least-load policy.

Quiz

Justify the model’s decision and name one production concern outside its scope.