Atharva Pandey Gopherine

A service I maintained once passed all its health checks while silently dropping 30% of incoming requests. The health endpoint returned 200 OK every time Kubernetes asked. The database connection pool was exhausted, the service couldn’t process anything, but that little /health endpoint — which didn’t touch the database — happily reported everything was fine.

That’s when I learned the difference between a health check that checks health and one that just says “the process is running.” They’re very different things, and getting this wrong means your orchestrator keeps sending traffic to a broken instance instead of replacing it.

Union Find is one of those data structures that most people never implement until they need it in an interview, and then they discover it is both elegant and surprisingly short. The core idea is deceptively simple: maintain a “parent” array where each element points to its group’s representative. Two operations — Find (who is the root of this group?) and Union (merge two groups) — are all you need.

I once spent six hours debugging a production issue where requests were randomly timing out. No errors in the logs. CPU and memory looked fine. Response times were normal — except for the 2% that took 30 seconds. Without distributed tracing, I was blind. I ended up bisecting the problem by adding println! statements, deploying them one at a time, and watching CloudWatch. It was miserable.

That experience permanently changed how I build services. Observability isn’t something you bolt on when things break. It’s something you build in from day one, or you pay for it later — with your time, your sleep, and your sanity.

At some point, you’re going to close a channel twice and the runtime is going to panic with close of closed channel. Or you’re going to close a channel from the wrong goroutine and send a value into it right after, and the runtime is going to panic with send on closed channel. These aren’t subtle race conditions that only show up under load — they’re logic errors that exist because nobody in the codebase agreed on who owns the channel. That agreement is the whole game.

My first Rust CI pipeline took 45 minutes. Forty-five. Every push triggered a full dependency build, tests ran sequentially, and clippy ran as a separate job that also built everything from scratch. I was burning through GitHub Actions minutes like they were free — which they are for open source, but my patience certainly wasn’t.

Getting Rust CI right is mostly about caching. The compilation model means a clean build downloads and compiles hundreds of crates, and without caching, every single CI run pays that cost. Let me show you the pipeline I’ve landed on after iterating through dozens of projects.

I found this in a production codebase:

fn get_or_insert(&mut self, key: &str) -> &mut Value {
    if !self.map.contains_key(key) {
        self.map.insert(key.to_string(), Value::default());
    }
    // "The borrow checker is being stupid, we know the key exists"
    unsafe { &mut *(self.map.get_mut(key).unwrap() as *mut Value) }
}

The comment says it all. The developer hit a borrow checker error — a legitimate one about borrowing self.map mutably twice — and instead of restructuring the code, they cast through a raw pointer to silence the compiler. This is undefined behavior. The compiler is allowed to assume the mutable references don’t alias, and it will optimize based on that assumption. When it does, your program does something you didn’t write.

Last year I had to deploy a Rust service to a hardened environment — no package manager, no shared libraries, no internet access. Just a bare Linux kernel and my binary. If my binary depended on libc, libssl, or anything else in /usr/lib, it simply wouldn’t start. That constraint forced me to learn static linking properly, and it turned out to be one of the best deployment patterns I’ve ever used.

I spent an entire afternoon debugging a test failure that turned out to be caused by a macro expanding variable names in a way I didn’t expect. The macro was called make_handler! and it generated HTTP handler functions from a declarative DSL that someone on the team had invented. The “DSL” saved maybe ten lines of boilerplate per handler. The macro definition was 200 lines of nested macro_rules! with five recursion levels, three tt munchers, and hygiene workarounds that I’m still not convinced were correct. When a new developer asked how to add a query parameter to a handler, nobody could explain it without first teaching them how the macro worked.

There’s a one-line fix that will make your hot paths faster, use less memory, and reduce GC pressure. It costs you nothing in readability. Most Go programmers know about it. Far fewer actually do it consistently. The fix is telling Go how big a slice is going to be before you start filling it.

The Problem

This is the pattern you reach for by reflex, especially if you’ve come from languages where dynamic arrays just grow as needed:

The first time I shipped a Rust service in Docker, my image was 2.1 GB. Two. Point. One. Gigabytes. For a binary that was 8 MB. I’d used rust:latest as my base, ran cargo build --release inside it, and called it a day. The image had GCC, LLVM, every system library known to humanity, and my tiny HTTP server somewhere in the corner.

That was the day I learned about multi-stage builds. And honestly, getting Docker right for Rust is one of those things that separates “I deployed it” from “I deployed it well.”