Peter builds it in the story
The services, Kafka events, Redis caching and idempotency, containers, Kubernetes, CI/CD and observability come together in Peter’s project, chapter by chapter.
A story about learning software12 chapters
Everything senior developers expect you to know, but rarely have time to explain.

A couple of months ago, Peter sat in his first standup meeting as a developer.
He nodded. He understood nothing.
From the languages Peter writes to the tools that keep production running. Click any of them to learn more.
Peter’s first month
These are the lines Peter heard in his first month, word for word from the book. Tap each highlighted term to see what it means and which chapter decodes it.
Pull the latest from main, spin up the Docker containers, and once the services are healthy, we’ll deploy to staging through the Jenkins CI/CD pipeline.Tap a highlighted term in the sentence.
This morning
This morning? Peter reviewed a complex PR covering database indexes, Docker multi-stage builds, distributed tracing, and idempotent message handling. He understood all of it.
What changed wasn’t just what he learned.
It was HOW he learned it.
Pull request review
This is a normal day for a developer. Watch it scroll, then tap any line to see which chapter explains it. Or open the terminal and type yourself.
Tap a line to see which chapter explains it.
How Peter learns
That is the shift at the heart of the book. Peter’s mentor doesn’t hand him commands to copy. He explains what things are and why they exist, until the next step makes sense on its own.
Peter
Junior developer
Five years in marketing, twelve weeks of bootcamp, and a brand new developer job. He can build a React app. The world around the code is new to him.
This is frustrating! It works on my laptop!Senior developer
Peter’s mentor
Reads a stack trace the way you read a newspaper and keeps the whole request path in his head. He doesn’t just hand Peter the fix; he explains why the system works this way.
That’s how this industry works. Knowledge shared is knowledge multiplied.
The moment it clicks
Conversation from The Software Realm, Decoded
Chapter 2 · 2.1 What You're Actually Building · p. 41
But when Peter types user.email, he pauses.
Peter
The IDE shows me email, username, age. How does it know what properties exist? What IS this user thing?
Senior developer
You’ve been using objects for two weeks without understanding what they are. Time to fix that.
Peter asks the questions many new developers carry around but rarely say out loud. You follow him from nodding along in meetings to contributing to architecture discussions.
Peter’s first task
Conversation from The Software Realm, Decoded
Chapter 1 · 1.2 The Terminal: Your Gateway to Everything · p. 23
He opens his laptop. Sees the GitHub link. Clicks "Download ZIP."
Senior developer walks by
What are you doing?
Peter
Downloading the code?
Senior developer
No, no. Open your terminal. Type git clone and paste the URL.
Peter stares at the black screen with blinking cursor. This looks like something from a 1980s movie. Why aren’t they using the normal interface with buttons and windows?
Peter
Why can’t I just download it normally?
Senior developer
You could. But then you’d miss the entire Git history, the branches, the ability to pull updates, and you’d have to manually download every time something changes. The terminal isn’t harder, it’s more powerful once you learn it.
A question everyone has
Conversation from The Software Realm, Decoded
Chapter 3 · 3.2 DNS: The Internet's Phone Book · p. 67
Peter
I never type 54.239.28.85. I type google.com. How does my computer know what IP address that is?
Senior developer
DNS. Domain Name System. It’s like a phone book. You give it a name, it gives you a number.
From nodding along to contributing
Conversation from The Software Realm, Decoded
Chapter 12 · 12.3 Recognition · pp. 255–256
Excerpt
Senior developer
I’m inviting you to the architectural leads meeting next time. We’re discussing the design for our next major system. I want your input.
Peter is speechless
I... really? The architectural leads meeting?
Senior developer
You’ve earned it. You understand distributed systems now. You know what questions to ask. You can contribute meaningfully.
Peter
Thank you. I don’t know what to say.
Senior developer
Say you’ll bring your critical thinking and ask hard questions. That’s what architects do.
Conversations are quoted word for word from the book, with chapter and page.
Mental models
The book gives every technical concept a mental model first. Flip a card to read how it is said in the book, or open the whole conversation.
Commits are snapshots. Branches are parallel timelines. Suddenly changing things and experimenting makes sense.
Senior developer in the book
“Done. You just saved a snapshot of your entire project. Now go ahead and break things while adding profile pictures. If it goes wrong, we can time-travel back to this exact moment.”Chapter 1 · 1.3.1 The Problem Git Solves · pp. 27–28
Messages are kept so you can read them back later. Consumer lag becomes how far you are behind the broadcast.
Senior developer in the book
“Great question. They both deliver messages, but they work fundamentally differently. Think of RabbitMQ as a mailbox. Kafka as a recording.”Chapter 8 · 8.4 Kafka vs. RabbitMQ: Recording vs. Mailbox · p. 189
You set the desired state. Kubernetes keeps checking and adjusting to hold it there.
Senior developer in the book
“Exactly! You declare: “I want 3 copies of my app running”. Kubernetes constantly ensures that’s true.”Chapter 9 · 9.7 Kubernetes: The Desired State Engine · p. 204
The Controller is the waiter, the Service is the chef and the Repository is the pantry.
Each app brings its own kitchen: stove, ingredients, everything. It parks on any server without bothering the others.
Your access is printed on the band itself, so the server reads the token instead of looking you up in a database.
Peter in the book
“Oh! The wristband has all the info printed on it. They don’t need to check a database!”Chapter 5 · 5.7 JWT: The Modern Approach (2010s) · p. 116
A recurring feature of the book
Every chapter translates the sentences Peter hears at work into plain language. Here are three of the book’s 51 boxes, which you’ll also find in the interactive companion.
What They Say vs. What They Mean, from The Software Realm, Decoded
Chapter 1 · 1.2.4 Why Linux Matters (Even on Mac and Windows) · p. 26
What they say
“SSH into the server and check the logs.”
What they mean
Connect to the Linux server using your terminal and use commands to read the log files.
What They Say vs. What They Mean, from The Software Realm, Decoded
Chapter 8 · 8.7.1 The Dead Letter Queue · p. 194
What they say
“Check the DLQ, we have poison messages.”
What they mean
Some messages keep failing and were moved to the Dead Letter Queue. We need to investigate why they’re malformed or causing errors, fix the issue, then manually reprocess or discard them.
What They Say vs. What They Mean, from The Software Realm, Decoded
Chapter 9 · 9.7.3 Services: Stable Addressing · p. 209
What they say
“Pods are cattle, not pets.”
What they mean
Pods are disposable. If one dies, you don’t fix it, you replace it. Services give you the stable identity you need.
Peter’s journey
The topics follow Peter’s story. Every chapter answers the next question he runs into at work.
Stop 1 of 12
Chapter 1 · The Foundation Layer
And many more tools along the way
The system in the book
In chapter 12, Peter projects the architecture he has built: orders, email and inventory as separate services, connected through Kafka, cached with Redis and running on Kubernetes.
The services, Kafka events, Redis caching and idempotency, containers, Kubernetes, CI/CD and observability come together in Peter’s project, chapter by chapter.
The book’s learning tips invite you to practise along the way:
In the interactive companion you browse the book’s conversations and What They Say boxes, chapter by chapter.
Open the interactive companionBefore and after
Tap a row to see what Peter does at the end of the book instead.
Self-check
Twelve questions, one per topic. A wrong answer is fine: it shows you which chapter fills the gap.
Your first step
Learn to think along, see how the pieces connect and ask good questions in your next design review, one conversation at a time.
Meet Peter. Pull up a chair.
