Understand exponential backoff before you watch it happen.
Exponential backoff is a collision recovery strategy used when many nodes compete for one shared communication channel. Instead of retrying immediately after a failure, each node waits for a random number of time slots. As repeated collisions happen, the retry window grows larger, which lowers the chance of another clash.
Shared Medium
Several senders attempt to use the same line, so simultaneous transmission can corrupt every packet involved.
Collision Detection
When two or more nodes send at once, the network detects a collision and the current attempt fails.
Randomized Retry
Each node independently chooses a random delay so future attempts become spread out instead of synchronized.
Exponential Window
After every additional collision, the waiting range becomes larger, which reduces repeated collisions under load.
The algorithm lowers repeated collisions by making retries less predictable.
Without backoff, nodes that collide once are likely to collide again because they often retry at nearly the same time. Exponential backoff solves this by adding randomness and gradually increasing the possible wait interval. That tradeoff sacrifices a little delay in exchange for much better stability when the channel is busy.
k is the number of collisions seen by the node so far.
random(0, 2^k - 1) selects a slot count from the current contention window.
slot_time is the base time unit used before the next retransmission attempt.
How a backoff cycle unfolds on a shared channel.
A node becomes ready to transmit and checks whether it can use the shared medium.
If only one node transmits, the receiver gets the packet successfully and may send an acknowledgement.
If several nodes transmit in the same slot, a collision occurs and none of those packets are delivered.
Each colliding node increments its collision count and selects a random wait from 0 to 2^k - 1 slots.
After its countdown reaches zero, the node retries. The wider retry window now makes another collision less likely.
The same idea appears far beyond classic Ethernet.
It is a foundational idea for collision handling in shared-medium networking.
It inspires retry strategies in distributed systems where many clients compete for the same resource.
It also appears in API retry logic, where repeated failures should lead to larger delays between attempts.
The key tradeoff is simple: a small amount of waiting after failure can make the entire system much more efficient under contention.