“Design a high-performance URL blacklist aggregator in Go that uses parallel bloom filters for sub-millisecond lookups.”
The brief was small enough to misread. "Make it fast" reads like an engineering task. What it actually meant was: a system that has to say no, thousands of times per second, to URLs that look almost legitimate, without ever becoming the bottleneck itself. I treated it, at first, like a benchmark. I should have treated it like a discipline.
Blacked is not a learning artifact. It is a working tool that happens to also be a teaching object. The Go is small. The bloom filters are textbook. The interesting part is the refusal -- the code that says no, in constant time, to the long tail of the internet.
CHOSEN — Go 1.22
Static binaries, goroutines that cost almost nothing, a stdlib that already knows what a sync.WaitGroup is. No web framework. No ORM. The compiler is the framework.
REJECTED — Redis, with reservations
A remote cache would have made the read path trivial and the failure modes loud. Blacked is a leaf node; it cannot depend on the network and still be honest about its latency.
REJECTED — a single bloom filter
One filter is fast but cannot admit new entries without rebuilding the world. The whole point of the project is to accept new URL intelligence continuously. Two filters -- old, new, swap on rotation -- was the smallest unit that preserved both speed and continuity.
The first measurement that mattered
The benchmark was not P99. It was the tail. A P99 of 0.4ms looked fine in the report. The shape of the tail told me that once in a few thousand requests, the system would pause for forty milliseconds -- exactly the request that mattered most.
Concurrency on a map that did not want it
The first concurrent writer panicked the runtime before any test could catch it. Blacked held a Go map across goroutines because the path "looked" safe. It was not. Replacing the map with a sync.Map was two lines. The reasoning took longer.
The decision to stay small
I almost added a feature for tracking per-entry lookups, popularity, time-since-seen. It would have been easy. It would also have made Blacked slower, larger, and more confident than it had any right to be. I cut the feature and added it to a separate project instead. Blacked stayed small on purpose.
The first 200 lines of the production binary. Not the README. Not a tutorial. The actual file, the one that runs in production.
package main
import (
"sync"
"context"
"log"
"net/http"
"flag"
"blacked/internal/filter"
"blacked/internal/source"
)Blacked is not finished. It is small because it can be small, and it should stay that way. The next decision -- whatever it is -- should respect the rule that made the project work: this is the part of the system that says no, and saying no is a privilege that speed earns.