Atharva Pandey Gopherine

Uber is one of the most instructive system design problems because it forces you to think about real-time data pipelines, spatial indexing, and latency-sensitive matching algorithms all at once. I spent a significant amount of time studying this problem specifically because the geospatial angle is something most candidates gloss over. They say “use a database with location queries” and move on. But at Uber’s scale — 5 million trips per day, hundreds of thousands of concurrent drivers and riders — the geospatial indexing strategy is the entire problem.

The first time I deployed a service to Kubernetes, I put everything in a single container. Logging, metrics, TLS termination, the actual application — all in one Docker image. It worked, but the image was massive, updating any single concern meant rebuilding and redeploying the whole thing, and the application team had to understand infrastructure concerns they shouldn’t need to care about. The sidecar pattern was the thing that changed how I thought about container composition.

Lifetime annotations are where most people’s Rust learning hits a wall. The syntax looks alien. The error messages talk about “named lifetimes.” Your code compiles fine until you add a second reference parameter, and then suddenly the compiler wants you to annotate things with 'a.

Here’s the thing most tutorials get wrong: lifetime annotations don’t change how long anything lives. They describe relationships that already exist.

Why Lifetimes Exist

Consider this function:

Databases promise durability. When INSERT returns successfully, your data is safe — even if the server loses power a millisecond later. For a long time I accepted this as magic. Then I started reading about what actually happens when Postgres writes data, and the mechanism behind that promise is both elegant and counterintuitive: to make writes safe, you write them twice. The first write goes to a sequential log. The second write goes to the actual data file. And the log is what saves you when things go wrong.

This is the lesson I almost didn’t write. Not because unsafe is hard to explain, but because most Rust developers will never need it — and I don’t want to encourage reaching for it prematurely. I’ve seen codebases riddled with unsafe blocks because the developer didn’t know the safe alternative existed. That’s the worst outcome.

But unsafe exists for a reason. Understanding when it’s appropriate — and more importantly, when it isn’t — is part of being a competent Rust developer.

I’ve been on the wrong end of bad code reviews in both directions. Reviews that were nitpick sessions about variable naming while missing a race condition. Reviews that rubber-stamped everything because the reviewer was busy. And I’ve given both kinds myself. It took a few years, a few incidents, and a few honest retrospectives to develop a framework for reviews that actually improve code quality without burning out reviewers or demoralizing authors.

I used to think the borrow checker was my enemy. It rejected valid programs! It made simple things hard! It was too conservative!

Then I started maintaining a large C++ codebase and found three use-after-free bugs in one week. The borrow checker stopped looking like an enemy real fast.

Borrowing: Using Without Owning

Ownership transfer is clean but inflexible. You can’t always afford to give your data away — sometimes you just want to let another function look at it for a moment. That’s borrowing.

The Rust ecosystem has some of the best documentation I’ve seen in any language. And it’s not an accident — the tooling actively encourages good documentation. Doc comments are first-class citizens. Examples in docs are compiled and tested. The standard library sets an impossibly high bar that crate authors actually try to meet.

If you’re publishing a crate and the docs are an afterthought, you’re doing it wrong. Documentation is the API.

Phil Karlton supposedly said: “There are only two hard things in Computer Science: cache invalidation and naming things.” He was joking, but also completely serious. Caching is the answer to nearly every “make it faster” problem in system design. It’s also the source of some of the most insidious bugs in production: stale data served with confidence, cache stampedes that take down your database, memory explosions from an unbounded cache. The concept is simple. Getting it right is not.

A coworker once asked me: “If Rust moves everything, how do I ever use a value twice?” Fair question. The answer is two traits that look similar but behave very differently — Copy and Clone.

Getting these confused will either tank your performance or confuse the hell out of you. Probably both.

Copy: Implicit, Cheap, and Bitwise

Copy is a marker trait. It tells the compiler: “this type is so cheap to duplicate that you should do it automatically on assignment instead of moving.”