When people write books about distributed systems, one of the first temptations is:
“I want to start with the coolest algorithm.”
A new consensus protocol.
A scalable queueing strategy.
A clean event schema.
But this book did almost the opposite.
Again and again, before we talked about what to use, we asked:
Which world are we operating in?
That question came first—every time.
1) What it means to have a “worldview”
I put Worlds in the title because the real goal wasn’t just technical knowledge.
I wanted to install a worldview for distributed systems.
When you:
- write code,
- design an API,
- set alerts,
- change Terms of Service,
- respond to an incident,
…if, for just one second, you pause and ask:
“Which world am I touching right now?”
Then this book has already done half its job.
2) Not “the right answer,” but “the right question”
RML-1/2/3 labels,
Runbooks vs Playbooks,
Effect Ledgers, case-file templates—
None of these are “do it this way.”
Because the best approach changes completely depending on:
- the company,
- the domain,
- the legal system,
- and the team’s skill set.
What this book can realistically offer is closer to:
A shape of questions worth asking at least once.
Questions like:
- “Is this feature really safe to keep at RML-2?”
- “Is this incident OK to leave out of the History World?”
- “Does the engineering team understand what this ToS clause implies for design?”
If those questions casually show up in reviews or hallway conversations, that alone is enough.
3) Real life still needs “make it work for now”
Of course, real teams live in reality:
- you need a PoC before anyone will listen,
- you need revenue for the org to survive,
- and sometimes you need a patch more than a perfect design.
RML isn’t here to deny that.
It’s a small proposal:
If you’re going to “make it work for now,”
at least be conscious of which world you’re sacrificing.
- Are you still contained in RML-1?
- Have you spread into RML-2?
- Have you already stepped into RML-3?
That single awareness changes both:
- how much damage you take when things go wrong, and
- how well you learn afterwards.
4) I want you to create your version of RML
In the book, for convenience, we used:
- RML-1 / RML-2 / RML-3
- Closed World / Dialog World / History World
But the names don’t matter.
- Level A / B / C is fine.
- World α / β / γ is fine.
- Domain-specific labels are often better (“Internal World / Customer World / Society World,” etc.).
What matters is this:
Build a vocabulary that fits your product and organization perfectly.
You don’t need to import the book as-is.
- Delete concepts.
- Add worlds.
- Take only the chapters you need.
The real goal is:
Create your own “Worlds of Distributed Systems.”
5) The chapters you’ll write next
The book ends at Chapter 11.
But the real work begins after that:
- in someone’s design doc,
- in the corner of an incident report,
- on a workshop whiteboard—
where RML, History World, or Runbook/Playbook tables reappear in new forms.
Each time that happens in your environment:
that becomes your Chapter 12, Chapter 13, and beyond.
6) Final words
If you read this far, you’re probably the kind of person who can’t help but care about:
- not just distributed system behavior,
- but also responsibility, history, and organization.
In a good way.
Teams with more people like that tend to grow systems with a real worldview—systems that age well.
If this book helped you put even a small amount of language around that “I can’t stop thinking about responsibility” instinct, then that’s exactly what I hoped for.
Wishing your own Worlds of Distributed Systems grows into something solid and trustworthy.
Top comments (0)