Forem: munyoki_kilyungi

Exponential Back-off with Jitter: Retries

munyoki_kilyungi — Thu, 02 Apr 2026 14:51:03 +0000

(Originally posted here)

TL;DR: Add random jitter to exponentially increasing retry delays to prevent synchronized client retries from overwhelming struggling services during outages.

Transient failures happen alot in production systems. Transient failures can come from:

Network instability
Service overload
Resource contention
Dependency flakiness
Timeouts

When an operation fails transiently, immediate retries can be tempting. However, this (moreso repeatedly) can amplify load at the worst possible moment, turning a temporary disruption into a cascading failure.

Consider a script that queries a Virtuoso triple store. Under heavy load, the database may start returning HTTP 504 (Gateway Timeout) errors.

A naive retry loop might look like this:

for attempt in range(max_retries):
    try:
        return sparql.queryAndConvert()
    except HTTPError as e:
        if e.code == 504:
            continue  # retry immediately

If the server is already struggling, immediate retries only add more pressure, making recovery harder. Even if you add a fixed delay, all retries from all clients (or even a single client) will occur at the same intervals, possibly colliding with the server’s own cool-down periods.

Exponential Back-off

Exponential back-off increases the delay between retries exponentially. For example:

First retry: 2 seconds
Second retry: 4 seconds
Third retry: 8 seconds

This gives the server a growing window of relief. But there’s still a problem: if the delays are deterministic, a single client’s retries may consistently land on a server state that’s still recovering. Worse, multiple clients would retry in perfect synchrony.

Exponential Back-off with Jitter

Jitter adds a small random value to each calculated delay. This:

Prevents retries from aligning across clients (thundering herd)
Avoids deterministic collisions with server‑side recovery windows
Spreads the load more evenly

In a single‑client scenario, jitter still helps by avoiding the situation where you always retry at times that happen to coincide with the server’s internal cooldown cycles.

Here’s a function that implements exponential back-off with jitter for a SPARQL query. It retries only on HTTP 504 errors and uses a configurable base delay and maximum retries.

import time
import random
from typing import Optional, Dict
from SPARQLWrapper import SPARQLWrapper
from urllib.error import HTTPError

def fetch_with_retry(
    sparql: SPARQLWrapper,
    max_retries: int = 3,
    base_delay: float = 2.0
) -> Optional[Dict]:
    """Execute SPARQL query with retry logic and exponential back-off."""
    for attempt in range(max_retries):
        try:
            return sparql.queryAndConvert()
        except HTTPError as e:
            if e.code == 504 and attempt < max_retries - 1:
                # Exponential back-off with jitter
                delay = base_delay * (2 ** attempt) + random.uniform(0, 1)
                print(f"    Timeout (attempt {attempt + 1}/{max_retries}), retrying in {delay:.1f}s...")
                time.sleep(delay)
            else:
                raise
    return None

Key Elements:

Exponential factor: base_delay * (2 ** attempt)
- Attempt 0 → 2 seconds
- Attempt 1 → 4 seconds
- Attempt 2 → 8 seconds
Jitter: + random.uniform(0, 1) - adds a random value between 0 and 1 second. This small variance is enough to break any undesired alignment.
Selective retry: Only HTTP 504 triggers a retry. Other errors are raised immediately, as they likely require different handling.
Retry limit: The loop stops after max_retries, ensuring the operation eventually fails instead of retrying forever.

Some pointers:

Use jitter even for a single client - it avoids deterministic collisions with server recovery periods.
Set a maximum number of retries - infinite retries can mask underlying failures.
Retry only idempotent operations - repeating non‑idempotent actions (e.g., writes) may cause data corruption.
Log retries - in production, log each attempt with the delay used to aid debugging.
Match base delay to your service - 1-2 seconds is a common starting point, but adjust based on typical recovery times.

Suffering = Pain * Resistance (and the Role of Self-Compassion)

munyoki_kilyungi — Tue, 06 Jan 2026 12:16:03 +0000

Everyone talks code, few talk stress. Here’s my take: original article

TL;DR: Pain is unavoidable. Resistance multiplies it. Acceptance and Self-compassion reduces the damage.

Where This Landed for Me

Over the New Year, I went to the 2025/2026 Beneath the Baobab Festival¹ with a close friend. Here, I mostly solo raved, finding myself quietly (at least most of day one) reflecting on some heavier chapters of my life: dark themes around death/grief; the abrupt end of a long-term commitment last February; the persistent cloud of depression in my community; and my own on-going struggle for mental/emotional stability.

One moment stood out. A homie shared some game that stayed with me long after the music died out²³⁴:

\times Resistance

How Pain Becomes Suffering

In meditation circles, you often hear: "Pain is inevitable. Suffering is optional."³

Here, pain is what we cannot control (e.g., illnesses, grief because of the death of a loved one, a break-up). It is the "rawness" of the ache of that particular experience. Resistance is what we add on top of it - it acts as a multiplier.

Resistance shows up in thoughts like:

"This (sh/c)ouldn't be happening."
"Why now?"
"How could (s/h)e do this at my lowest point?"
"I need to fix this."

When my ex left during a fragile period, the pain was unavoidable. What turned it into deep suffering was my resistance: replaying the story, arguing with reality, insisting that things should have gone differently.

Pushing against reality consumes mental/emotional energy and multiplies our pain. We suffer more.

When We Turn Against Ourselves

In times of suffering, we can sometimes notice our own resistance. That's when self-criticism shows its ugly self.

We judge ourselves harshly for struggling:

"I'm better than this. I shouldn't feel this way."
"I suck at being 'okay'."
"I'll just compartmentalize this and deal with this pain later."

This pattern is sometimes called "resisting resistance"⁴. A clearer name is self-criticism.

The equation now looks like this:

\times Resistance \times SelfCriticism

We are not only in pain, we are also attacking ourselves for being human.

What Actually Helps: Acceptance and Self-Compassion

The antidote to resistance is acceptance².

Acceptance doesn’t mean liking the situation or resigning to it. It simply means acknowledging reality without forcing it to be different. Not everything is under our control².

To counter self-criticism, we add self-compassion. If resistance and self-criticism are multipliers, self-compassion is the divisor⁴:

\frac{(Pain \times Resistance)}{SelfCompassion}

Self-compassion is offering yourself the same kindness you would offer a close friend:

"This hurts. My resistance is making it harder. I’m allowed to care for myself here."

Pain remains, but suffering is reduced

A Simple Practice

When life feels heavy, I'm learning how to follow these steps²:

Notice a painful emotion/thought.
Observe thoughts of resistance (e.g., "Why me?") and let them pass.
Re-center by accepting circumstances, even if unpleasant.
Focus on physical sensations, acknowledging their temporary status.
Release judgment.

Finding Peace Under the Baobabs

Standing under the baobabs, I realized I don’t need to eliminate pain to find peace. Meditation and mindfulness don’t remove the ache of heartbreak or depression; they remove the unnecessary suffering we pile on top.

Think of pain as a heavy backpack. Resistance is trying to run uphill while complaining about the weight. Self-compassion is stopping, breathing, and tightening the straps. The load is the same, but the journey becomes manageable.

References

Beneath the Baobab Festival ↩
Buggy, P. Suffering = pain * resistance. Mindful Ambition. https://mindfulambition.net/suffering-pain-resistance/ ↩
Selassie, S. (2023, October 28). Pain x resistance = suffering. Happier Meditation. https://www.happier.com/blog/pain-x-resistance-suffering/ ↩
Saltzman, A. (2025, August 5). The new math: Suffering = (pain x resistance) / self-compassion. Psychology Today. https://www.psychologytoday.com/us/blog/find-your-true-flow/202508/the-new-math-suffering-pain-x-resistance-self-compassion ↩

FizzBuzz using streams in Python

munyoki_kilyungi — Thu, 13 Feb 2020 21:41:47 +0000

So this evening I was fooling around with the concept of using monoids to play around with streams. The idea here is to break a relatively abstract concept into something that a noOb can follow along, and it hit me; why not demo all this stuff using the classic Fizz-buzz algorithm.

Generally, for a fizz-buzz problem, you print out "Fizz" if a number is divisible by 3; and alternatively, you print "Buzz" if it's divisible by 5. Needless to say, you print "FizzBuzz" if it's divisible by both 3 and 5. Now a simple implementation in python would be something like:

def fizz_buzz(n):
    for i in range(1, n+1):
        if (i % 3 == 0 and i % 5 == 0):
            print("{}: FizzBuzz".format(i))
            continue
        if (i % 3 == 0):
            print("{}: Fizz".format(i))
            continue
        if (i % 5 == 0):
            print("{}: Buzz".format(i))


fizz_buzz(100)

Well for one, I don't like that the above function has side-effects. How can we refactor this to use streams? First of all, let's clear up what a stream is. A stream is a sequence of objects which can be accessed in sequential order. Where do monoids come in? Well a monoid allows us to combine things. A monoid has a single associative "structure"(in our case this is the "append" operation that zip provides). In this case, when we have a stream, we can combine several monoids from a stream using zip. Let's look at it in Python:

from itertools import cycle


def fizz_buzz(n):
    """Return an iter list with fizz-buzz"""
    fizz_buzz = zip(cycle(['', '', '', '', 'Fizz']),
                    cycle(['', '', 'Buzz']),
                    [i for i in range(1, n+1)])
    return filter(lambda x: (x[0] != '' or x[1] != ''),
                  fizz_buzz)

for i in fizz_buzz(100):
    print("{}: {}{}".format(i[2], i[0], i[1]))

From the above snippet, we first generate a stream of "Fizzes" and "Buzzes", then we combine them with zip after which we filter any element from the stream that has no "Fizz" or "Buzz". Python's loose typing makes it easy for us to combine and morph things. Notice that the fizz_buzz function returns a generator which has it's own merits.

If you want to functional programming tips, I post interesting reads on a google groups I started a while back here https://groups.google.com/forum/#!forum/nairobi-functional-programming-community