Most things worth doing fail the first time. Systems, ideas, the grasp of a hard problem, they all iterate toward something that works, or they don’t. This blog is about the iteration, mostly as it shows up in distributed systems.

What This Is

This is where I write down the craft of building distributed systems: the concurrency primitives, the failure modes, and the data and reliability patterns that decide whether a system holds under load or falls over at 3am.

The approach is implementation-grounded. Concepts get explained by building them in code you can actually run, not by drawing boxes and arrows. When a post claims something is true, there is usually code you can compile to see why.

What You’ll Find Here

Posts stay in three lanes:

  • Distributed systems and concurrency: the primitives, the failure modes, and the patterns that survive real load.
  • Distributed data systems: how data engines and lakehouses actually work underneath the abstractions.
  • Reliability patterns: retries, idempotency, backoff, the “retry until success” core this site is named for.

I write for senior backend, infra, and platform engineers, and the people who lead them. The assumption is that you can already code and have shipped real systems, so posts skip the basics and go straight for the part that bites.

The Name

Retry is a pattern in distributed systems that improves resilience: a loop that keeps trying until something works, on the assumption that failure is expected and temporary.

Retry until success is more than a systems pattern. It is a posture: if you keep iterating, learning, and improving, success becomes a matter of when, not if.

The Stack

Built with Hugo . Posts in Markdown. Diagrams in Mermaid . No personal tracking, no ads, no newsletter popups, no noise, just privacy-respecting anonymous analytics so I can see which posts land.