Local Rules and Emergent Behavior

By the end of this lesson, you will be able to...

• Trace how simple local rules can create a system-level pattern.

• Predict how topology and timing change the aggregate behavior of a system.

• Explain why no single actor needs to plan an emergent outcome for it to appear.

Idea in one sentence: Emergent behavior appears when many parts repeatedly follow local rules and their interactions create a larger pattern.

Core Insight

A checkout service is slow for a few minutes.

Each client follows a small rule:

If my request times out, retry after one second.

That rule is local. The client sees only its own request, its own timeout, and its own retry timer. It does not see the full queue inside the service. It does not know how many other clients are waiting.

Now many clients follow the same rule at the same time.

The first retry wave adds more work. The extra work makes the queue slower. The slower queue creates more timeouts. More clients retry. A pattern appears at the system level: synchronized retry waves and rising congestion.

No client planned the congestion. No coordinator selected it. The pattern came from repeated local decisions interacting through a shared queue.

That is emergence.

The previous lesson showed that complexity comes from interaction, not just size. This lesson makes one interaction mechanism visible:

local rule + repeated interaction + shared structure -> aggregate pattern

To reason about complex systems, you often need to ask a different question. Not "What did one part intend?" but "What pattern appears when many parts apply the same rule near each other?"

The Naive Idea

The naive idea is:

If every local rule is simple, the whole system should be simple.

This feels reasonable. A single client retry is easy to understand. A single driver changing lanes is easy to understand. A single seller lowering a price is easy to understand.

The problem is that a local rule does not run in empty space.

It runs inside a structure:

• a queue
• a road
• a market
• a chat group
• a network
• a deployment pipeline

The structure decides who affects whom. It decides which effects spread, which effects stay local, and which effects return later as feedback.

A local rule can be simple and still produce a hard-to-predict pattern when many actors apply it through the same structure.

Plain to Precise

Plain meaning:

An emergent behavior is a larger pattern that appears from many small interactions.

In this scenario:

No client chooses "create a retry wave." Each client only chooses "try again after my timeout." The retry wave is the larger pattern that appears when many clients apply that rule against the same slow service.

Technical name:

This is emergent behavior. It is behavior of the whole system that is produced by local rules and interactions, even though the behavior is not explicitly stored inside any one part.

Emergence is not magic. It is not a license to stop explaining.

It means the explanation is in the trace:

what each part can see
what rule each part follows
who each part affects
how the effects accumulate
what larger pattern appears

A Worked Trace: Queue Congestion

Start with a tiny service.

There are four clients and one worker. The worker can complete two requests per second. Each client has the same timeout rule:

If I do not get a response in 2 seconds, retry once.

The initial input is a short slowdown. For one second, the worker completes only one request instead of two.

Here is the trace.

The input was a temporary slowdown.

The transition was a local timeout rule.

The intermediate state was a queue containing original work and duplicate retry work.

The output was congestion that lasted longer than the original slowdown.

The naive failure contrast is the important part. If you inspect one client, retrying once looks reasonable. If you trace all clients through the same queue, the retry rule changes the environment it reacts to. The rule helps one request sometimes, but it can harm the system when many clients apply it together.

So far, emergence means that the whole-system pattern is not stored inside one actor. It appears in the repeated interaction.

Topology Changes the Result

Local rules do not create the same pattern everywhere. The structure connecting the parts matters.

Imagine the same retry rule in two shapes.

Shape A: shared bottleneck

client A \
client B  -> one checkout queue -> one dependency
client C /

Shape B: partitioned queues

client A -> queue A -> worker A
client B -> queue B -> worker B
client C -> queue C -> worker C

In Shape A, retries from many clients meet at one bottleneck. Their effects add together. One local rule can create a visible system-level wave.

In Shape B, retries are separated. A retry storm can still happen inside one partition, but it is less likely to hit every worker at once unless another shared dependency exists below the partitions.

The local rule did not change. The topology changed. The aggregate behavior changed with it.

This is why systems thinking cares about connections. The same actor behavior can produce congestion, convergence, lock-in, or stability depending on who can influence whom.

Check: A team says, "Our retry policy is safe because each client retries only once." What question should you ask next?

Think first, then reveal.

Answer: Ask where those retries meet. One retry per client may still be unsafe if thousands of clients retry against the same queue, database, or dependency at the same time.

Another Small Mechanism: Convergence

Emergence is not only about failure.

Consider a group of services choosing a cache endpoint. Each service follows this local rule:

Every minute, measure the three nearest endpoints.
Pick the endpoint with the lowest latency.

That rule sounds efficient. Each service is only trying to reduce its own latency.

But if all services measure at the same minute, they may all see endpoint B as slightly faster and move there together. Endpoint B gets crowded. Its latency rises. On the next measurement, endpoint C looks faster. Many services move again.

The emergent pattern is not "better placement." It may be synchronized herd movement.

Change one parameter: add jitter, so services measure at slightly different times.

Now only some services move at once. The endpoints still receive local decisions, but the decisions are spread over time. The aggregate pattern can become smoother.

The rule is still local. The timing changed. The emergent behavior changed.

This gives you three levers to inspect:

• the local rule
• the topology of interaction
• the timing of repeated decisions

Trade-offs and Limits

Reading systems through local rules helps because it gives you a concrete way to explain surprising behavior. Instead of saying "the system became unstable," you can trace who saw what, what rule fired, and how the effects accumulated.

The trade-off is visibility versus modeling cost. You gain a better explanation of the aggregate pattern, but you must model enough of the interaction structure to make the pattern visible. Counting components is easier. Tracing influence is more work.

It does not make every outcome predictable. Small timing differences, hidden shared dependencies, and noisy measurements can still change the result. Emergence often gives you conditional predictions:

If many actors apply this rule against this shared structure,
then this aggregate pattern becomes more likely.

The signal that you have reached the boundary is when the same local rule produces different outcomes under different topology or timing. That is not a failure of the idea. It is the idea telling you what else must be included in the model.

This helps when you need to explain aggregate behavior. It does not replace measuring the real system.

Common Confusions

Confusion: Emergent means unexplained

Why it is tempting:

Emergent patterns can surprise people. If no single actor planned the pattern, it can feel mysterious.

Better model:

Emergent behavior is explained by local rules, interaction structure, and repeated effects. The explanation is not inside one part. It is in the relationship among parts.

Confusion: If every actor is rational, the global result should be good

Why it is tempting:

Local rationality is easier to inspect. If every actor makes a reasonable decision, the system feels like it should improve.

Better model:

Locally reasonable decisions can compete through shared constraints. Every client retrying can be reasonable for that client and harmful for the shared service.

Confusion: Emergence only happens in huge systems

Why it is tempting:

Many examples involve cities, markets, ecosystems, or large platforms.

Better model:

Emergence needs interaction, not massive size. A small queue, a few clients, and one timeout rule can already produce a pattern that is not visible from one client alone.

Check Your Understanding

Check: Three deployment jobs all use this rule: "If the shared test cluster is busy, wait exactly 60 seconds and try again." What aggregate pattern might appear?

Think first, then reveal.

Answer: The jobs may synchronize. They all wait the same amount of time, then try again together, making the cluster busy again. Adding jitter or separate queues could change the aggregate pattern.

Check: In a marketplace, sellers lower prices when they lose ranking, and buyers click more often on cheaper listings. What should you trace to explain the system-level pattern?

Think first, then reveal.

Answer: Trace what sellers can see, how ranking changes their price rule, how buyer clicks feed ranking, and whether the loop creates convergence, oscillation, or lock-in.

Practice

Choose one of these situations and trace the emergent behavior.

1. A road has three lanes. Drivers move to the lane that looked fastest during the last 10 seconds.
2. A chat group boosts messages that receive quick reactions, and users react more often to messages that are already boosted.
3. A set of services all choose the cache endpoint with the lowest latency at the same measurement time.

For your chosen situation, write:

• the local rule each actor follows
• what each actor can and cannot see
• the shared structure where effects meet
• the intermediate state after one or two rounds
• the aggregate pattern that appears
• one small change that might alter the pattern

Model answer for the cache endpoint case:

Each service can see recent latency to endpoints, but not the future choices of all other services. The local rule is "pick the endpoint with the lowest measured latency." The shared structure is the set of cache endpoints. After one round, many services may move to the same endpoint. The intermediate state is increased load on that endpoint. The aggregate pattern may be herd movement or oscillation between endpoints. Adding jitter, placement limits, or a cost for moving could smooth the behavior.

Resources

• [BOOK] Complexity: A Guided Tour - Melanie Mitchell
  • Link: https://academic.oup.com/book/51004
  • Focus: Read for clear examples of how local interactions can produce system-level behavior.
• [BOOK] Thinking in Systems - Donella Meadows
  • Link: https://www.chelseagreen.com/product/thinking-in-systems/
  • Focus: Pay attention to structure, feedback, and why behavior comes from relationships among parts.
• [VISUAL] NetLogo Models Library
  • Link: https://ccl.northwestern.edu/netlogo/models/
  • Focus: Explore simple local-rule models and notice how changing one rule or connection changes the aggregate pattern.

Key Takeaways

1. Emergent behavior appears when repeated local rules interact through a shared structure.
2. A local rule can be reasonable in isolation and still create a harmful aggregate pattern.
3. Topology and timing can change the whole-system result without changing the local rule.
4. To explain emergence, trace what actors see, what rule fires, where effects meet, and what pattern accumulates.