
Six Stations, Six Ways to Die: A Request's Journey for Survival
Technical notes & reflection — on the road every request must travel, and why it travels that way.

AI answers everything with the same confident tone, whether right or wrong. The only way to catch its errors is to already know the domain. This essay maps six knowledge sources—books, primary documents, vetted updates, courses, people, and practice—and argues that cross-referencing them is the…

Technical notes & reflection — on the road every request must travel, and why it travels that way.

There are technologies you use every single day without ever looking them in the eye. For me, DNS was one of them. I'd been typing domain names for a decade. Buying domains, pointing records, waiting for "propagation," cursing when it didn't come up, rejoicing when it did — without really understanding why it came up. DNS, to me, was like the light switch on the wall: flip it and the room lights up; if it breaks, call an electrician. Until one deploy night, the site went down. ping to the IP was fine. curl straight to the IP returned the page. Only the domain name sat there in silence. I stared at it and realized something a little humiliating: I didn't know where to even start fixing it, because I had never truly understood the thing that was broken. So I did what probably only an engineer would find reasonable: instead of skimming the docs, I sat down and wrote an entire DNS server in Rust. The project is called mini-dns. This post is what a black box told me once I finally opened it up.

There's a funny paradox among developers: we'll happily argue for a week about whether the backend should be written in Rust, Go, or Node.js — but when it's time to ship to production, 90% of us quietly type apt install nginx and stick it out front. Nginx is everyone's go-to gatekeeper — and also the thing that has people debugging until 2 a.m., still unable to figure out why one simple request keeps returning a 404. Here's the interesting part: the bug is almost never in Nginx. It's that we read the config file like a script that runs top to bottom — when that's not how Nginx works at all. This isn't a listicle of "common Nginx errors" for you to copy-paste onto your server. The goal is to hand you a mental model: to understand how Nginx thinks, so the seemingly magical traps below become predictable instead of leaving you staring blankly at the screen.

It’s not that Rust is objectively better than Java. Nor is it that Go will replace C. Rather, the way we think about writing code has silently shifted over the past fifty years — and you are standing right in the middle of that transformation.

Five years ago, I was a mid-level engineer comfortably settled in my tidy, little world of simple repositories. Out of nowhere, the outbound team handed over a massive "anchor" of a Monorepo—powered entirely by Bazel. That initial culture shock, triggered by a tangled web of configuration files, completely shattered my worldview. Yet, looking back, it was the exact trial by fire that transformed me from a local "code-writer" into a true systems engineer. Let’s flip back through the pages of my tech diary to revisit this grueling yet invaluable experience.

SOLID is not a religion, and design principles are not immutable commandments. From the perspective of a battle-tested Tech Lead, sometimes deciding to bend the Liskov Substitution Principle (LSP) is a mature choice to keep the system alive. Let’s analyze 4 classic trade-off scenarios and the art of safely isolating the 'toxic code'.
Receive real-time notification streams for new engineering releases.
No spam. Unsubscribe anytime.