Atharva Pandey Gopherine

I was optimizing a JSON serializer that allocated a buffer for every call. Under profiling, those allocations were 30% of the cost. The fix? A thread-local buffer that gets reused across calls on the same thread. No synchronization needed. No contention. Each thread has its own buffer. Throughput doubled.

Thread-local storage is the ultimate escape hatch from synchronization overhead. If each thread has its own copy, there’s nothing to synchronize.

One of Go’s most practical superpowers is that cross-compilation is a first-class feature, not an afterthought. Two environment variables — GOOS and GOARCH — are all you need to produce a Linux binary from macOS, a Windows executable from Linux, or an ARM binary from an x86 machine. No Docker containers required, no cross-compilation toolchain setup, no linker flags hunting. Just GOOS=linux GOARCH=amd64 go build and you have a production-ready binary for the target platform.

The worst deadlock I ever encountered wasn’t between two mutexes. It was between a mutex and a channel. Thread A held a lock and tried to send on a full bounded channel. Thread B was the consumer for that channel but was waiting to acquire the same lock before it could receive. Clean deadlock. Took me four hours to find because I was looking at mutex ordering and the real problem was a channel.

A client sends a payment request. The network times out. The client does not know if the payment was processed. Should it retry? If it retries and the payment already went through, the customer gets charged twice. If it does not retry and the payment failed, the order never ships. Without idempotency, there is no safe answer to this question.

This is not a theoretical concern. It happens every time a mobile app retries a failed request, every time a message queue delivers a message at least once, every time a load balancer retries on a 503.

A few years ago I was profiling a metrics collection service and found that 60% of the CPU time was spent on mutex contention. Thirty-two threads, one mutex protecting a counter map. The actual “work” — incrementing counters — took nanoseconds. The locking overhead was three orders of magnitude more expensive than the operation it protected.

That’s when lock-free data structures become worth the complexity. When the lock is the bottleneck, remove the lock.

Go is not the most common language for GraphQL tutorials. Most of the ecosystem documentation assumes you’re working in JavaScript or TypeScript, and a lot of the tooling is designed around Node’s event loop model. But Go is an excellent choice for a GraphQL server — statically typed, fast, and with gqlgen you get one of the cleanest schema-first GraphQL implementations I’ve used in any language.

This lesson is about making it work in production: generating a working server from a schema, implementing resolvers correctly, and fixing the N+1 problem with DataLoader before it shows up in your latency graphs.

There is a simple test I apply to any function I’m about to merge: can I name it clearly without using “and”? If the most honest name for a function is validateAndSaveAndNotifyUser, the function is three functions pretending to be one. The naming test doesn’t lie — it’s a direct readout of the function’s responsibility. I’ve seen this test convince engineers who were unmoved by SOLID principles or Uncle Bob quotes, because it’s visceral: if you can’t say what the function does in a few words, you already know something is wrong.

I was building a benchmark suite once — eight threads, each measuring throughput of a different operation. The problem was that threads started at different times depending on OS scheduling. Thread 0 might start 50ms before thread 7, skewing the results. I needed all threads to start their measurement at exactly the same time.

That’s what barriers do. Everyone waits at the barrier until the last thread arrives, then they all proceed together.

Some functions produce output that’s too large or too structured to assert inline. A template renderer, a code generator, a JSON serializer for a deeply nested type, a CLI help text formatter — any of these can produce hundreds of lines of output that you need to verify is correct. Hardcoding that expected output inside the test function creates a wall of string literals. The golden file pattern solves this by storing the expected output in a file, comparing against it at test time, and offering a flag to regenerate it when the output intentionally changes.

Early in my career, I wrote a producer-consumer queue using a mutex and a busy-wait loop. The consumer would lock the mutex, check if there’s data, unlock, sleep for 10 milliseconds, and repeat. It worked, but it burned CPU doing nothing and had up to 10ms of latency on every message. My tech lead pointed me to condition variables, and the latency dropped to microseconds while CPU usage went to near zero.