Recently, I recalled a useful pattern that’s cropped up a few times at work. API handlers (think http.Handler), include a context.Context tied to the connectivity of the caller. If the client disconnects, the context closes, signaling to the handler that it can fail early and clean itself up. Importantly, the handler function returning also cancels the context. But what if you want to do an out-of-band operation after the request is complete?

Go makes concurrent programming dead simple with the go keyword. And, with its “share memory by communicating” mantra, channels perform as a thread-safe mechanism for IO between threads. These primitives more than meet the demands of most parallel tasks. But sometimes workloads need extra coordination, particularly around error propagation or synchronization. For example, goroutines often need access to a shared yet thread-unsafe resource. Enter the standard library’s sync package with WaitGroup, Once, and Mutex.

In this first X-Files post, I’ll cover the simple yet powerful golang.org/x/time/rate. This package provides a Limiter that controls throughput to an arbitrary resource. There’s a ton of utility in rate, and to show its virtues, I will use it to enforce an SLA on an HTTP service.1 SLAs and Rate Limiting When creating a new service, it is prudent to specify a service level agreement, or SLA. This promises an expected availability given some throughput from consumers.

This post will be the start of The X-Files, a blog series exploring the Go sub-repositories located at golang.org/x/*. Chances are, you may not have heard them called that before or know where they came from. Introductions are in order… A brief origin story Go promises, with reasonable exceptions, that its compiler and standard library will remain forward-compatible for all minor releases of the Go 1 language specification. This is incredibly refreshing, especially if you’ve ever used a framework or language that seems to break the world on every patch release.

I have fallen in love with the flexibility of io.Reader and io.Writer when dealing with any stream of data in Go. And while I am more or less smitten at this point, the reader interface challenged me with something you might think simple: splitting it in two. I’m not even certain “split” is the right word. I would like to receive an io.Reader and read over it multiple times, possibly in parallel.