Atharva Pandey Gopherine

My first real FFI project was binding to SQLite. I thought “how hard can it be — it’s just calling C functions.” Three days later I was debugging a segfault caused by a string lifetime issue where Rust freed a CString while SQLite was still reading from the pointer. That experience taught me more about unsafe Rust than any tutorial ever could.

Calling C from Rust is the most common FFI scenario. Every operating system API is C. Most high-performance libraries — OpenSSL, zlib, SQLite, libcurl — are C. If you’re writing systems software in Rust, you’ll need this skill.

The standard library’s Vec<T> contains over 50 unsafe blocks. HashMap has even more. Yet you use both every day without thinking about safety — because their public APIs are entirely safe. The unsafe is invisible, encapsulated behind type system boundaries that make misuse impossible.

This is the most important pattern in Rust: unsafe internals, safe surface. Master it, and you can build anything.

The Core Principle

An unsafe block means “I’ve verified the invariants.” A safe API means “the type system prevents invariant violations.” The goal is to push all the verification into the implementation so that users of your code can’t break the invariants no matter what they do.

Every lesson in this series has been a piece of a puzzle. HTTP routing, middleware, validation, error responses, pagination, idempotency, timeouts, rate limiting, config management — each one addresses a specific concern in isolation. This final lesson puts them together into a single, production-shaped service that you can actually use as a starting point.

The goal is not a complete application. It is a skeleton that demonstrates how all the pieces wire together in main.go and what a well-structured Go service looks like before you add your business logic.

I once watched a senior engineer transmute a Vec<u8> into a Vec<u32> and couldn’t figure out why it segfaulted on ARM but worked fine on x86. Spoiler: alignment. The allocator returned 1-byte-aligned memory for the u8 vec, and u32 needs 4-byte alignment. On x86 you pay a performance penalty; on ARM you get a bus error.

transmute is Rust’s most powerful unsafe tool. It reinterprets the bits of one type as another type. No conversion, no transformation — just “these bytes are now a different type.” That power makes it incredibly useful and incredibly dangerous.

The first time I connected a mobile frontend directly to 11 microservices, I created 11 places for the mobile team to integrate, 11 different auth schemes to understand, 11 different error formats to handle, and a situation where a single product screen required 6 parallel API calls because the data was spread across 6 services. An API gateway solves all of this: one URL, one auth scheme, one error format, and the ability to aggregate multiple service responses into a single response the client actually needs.

I’m going to tell you something that might sound weird after seven lessons about microservices patterns: don’t start with microservices. Start with a monolith. A well-structured, modular monolith that’s designed to be split later.

This isn’t contrarianism for its own sake. I’ve seen three teams build microservices from day one. All three regretted it. One team spent more time debugging distributed system issues than building features. Another had seven services that each handled about 50 requests per day — the infrastructure cost was absurd. The third discovered six months in that they’d drawn their service boundaries wrong and had to do a painful re-architecture.

A colleague once showed me a bug that took them three days to find. Their unsafe code dereferenced a pointer that was valid when created but dangling by the time it was used — a classic lifetime mismatch. The fix was two lines. The debugging was seventy-two hours. That ratio is why this lesson exists.

Dereferencing raw pointers is the most common unsafe operation you’ll encounter, and getting it right means following specific patterns. Not guidelines — patterns. Repeatable, auditable approaches that make your unsafe code reviewable.

Without context.Context, a function that makes a database call, fires an HTTP request, or runs a long computation has no way to be told to stop. The caller times out, the user closes the browser tab, the load balancer kills the connection — and your function keeps running, consuming CPU and holding database connections, doing work that nobody will ever see. context.Context is how Go solves this.

The Problem

A function with no context cannot be cancelled. It runs until it finishes, or until the process dies. In an HTTP server handling hundreds of requests per second, this accumulates fast:

The first rolling deployment I did without graceful shutdown handling produced about 200 errors for in-flight requests. Kubernetes sent SIGTERM to the old pods, the Go process exited immediately, and every active request was terminated mid-flight. The users got 502s. The monitoring dashboard lit up red for about 30 seconds per deploy, every time.

Kubernetes’s rolling update strategy replaces pods one at a time and can achieve zero request drops — but only if your application cooperates. The contract is: Kubernetes sends SIGTERM, your application finishes in-flight requests, then exits. If you ignore SIGTERM and exit immediately, Kubernetes kills you with SIGKILL after the grace period anyway, and you drop the requests. The work is in your application code, not in the Kubernetes config.

The first time I used raw pointers in Rust, I was porting a ring buffer from C. I’d written ring buffers in C a dozen times — head pointer, tail pointer, wrap around, done. In Rust, the borrow checker wanted nothing to do with my two mutable pointers into the same buffer. That’s when I learned what raw pointers are actually for.

References vs Raw Pointers

Rust references (&T and &mut T) come with guarantees enforced by the compiler: