Atharva Pandey Gopherine

We deployed a new checkout flow on a Friday afternoon. It had passed code review, passed testing, passed staging load tests. By Friday evening, the error rate was climbing. The new flow had a race condition that only manifested under specific mobile browser timing that we hadn’t tested. Without a feature flag, the fix would have required an emergency deployment — 25 minutes of build time, deployment, and validation. With a feature flag, the rollback was turning off a switch. Thirty seconds.

I was reviewing a PR last year where someone had written twelve match arms for an enum — four groups of three variants that all did the same thing. Each group was identical code, copy-pasted three times. I left a one-line comment: “or patterns.” The whole match collapsed from 36 lines to 12.

Most Rust developers learn the basics of match early and never dig into the full pattern syntax. That’s a shame, because there are three features that eliminate a ton of redundancy: or patterns, @ bindings, and rest patterns.

A Postgres connection is not cheap. When I first scaled a service from a single server to 20 replicas — each running a Go application with database/sql’s default pool settings — the database became the bottleneck almost immediately. Not because the queries were slow. Because we had 20 × 100 = 2,000 open connections, each consuming RAM on the Postgres server, and Postgres was spending more time managing connections than executing queries. This is the problem PgBouncer solves, and understanding how it works makes you a much better architect of backend systems.

When I first tried to understand Paxos — the original distributed consensus algorithm — I read the paper three times and still felt like I was missing something. I could follow each step individually, but I couldn’t build a mental model of why it worked or what the invariants were. Raft was designed specifically to fix that. Its paper is literally titled “In Search of an Understandability: The Raft Consensus Algorithm.” After reading it, I could explain it to someone else. That’s the bar Raft was designed to clear, and it does.

A few months back I was writing a rate limiter. The logic was simple: if the request is from an internal IP and the rate is under the limit, allow it. If it’s external and under a different limit, allow it. Otherwise, reject. I started with nested if statements inside match arms and ended up with something that looked like a plate of spaghetti. Then I rewrote it with match guards and the whole function collapsed to six clean lines.

I inherited a Go service where the primary domain object was a struct with 47 fields. Some were database columns, some were computed from other fields, some were HTTP response projections, some were used only during a specific workflow stage, and a handful were there because someone once needed a flag and adding a field to the God struct was the path of least resistance. The struct was everywhere — passed between functions, serialized to JSON, written to the database, and used as a GraphQL response type. Every change to it rippled through the entire codebase.

The lexer gave us tokens. The tokens are still flat — a sequence with no hierarchy. The expression 1 + 2 * 3 produces six tokens, but it does not yet say that 2 * 3 should be computed before adding 1. That grouping, that hierarchy, is what the parser builds. By the time the parser is done, we have a tree. A specific kind of tree: an Abstract Syntax Tree, or AST. Everything after the parser works on this tree: evaluation, type checking, code generation, optimization. The tree is the program.

There’s a pervasive myth in the Rust community that unwrap() is always bad. I’ve seen code reviews where people mechanically replace every unwrap() with a match or .expect(), even when the unwrap() was perfectly correct. The truth is more nuanced: panic! is a tool, and like any tool, the question isn’t “should I ever use it?” but “when is it the right choice?”

What panic! Actually Does

When you call panic!(), Rust does one of two things depending on your configuration:

There’s a version of Go code I see in almost every codebase that’s been touched by developers who came from Java or C# — it’s covered in interfaces, repositories, factories, and service layers that all wrap exactly one concrete implementation. No tests mock these interfaces. No second implementation exists. The abstraction is doing nothing except adding indirection. I’ve written code like this myself, and the tell is always the same: when something breaks, I have to jump through five files to understand what happens when I call CreateUser.

The first time I shipped a breaking change to a production API without a version, I got an incident at 2am because a partner integration stopped working. They’d been calling /api/orders for six months. I changed the response shape. Their code broke. That was when “API versioning” moved from “thing to do eventually” to “thing to do before you ship anything external.”

There’s no universally right answer to how you version APIs. There are tradeoffs, and the choice you make will shape your codebase for years. Here’s how I think about it.