Signal Hub

Go news and articles

Ctrl K

Date

Source

3 articles

Dev.to (Rust/Go)

~10 min readSep 19, 2026

Used a cheap old android mobile(1gb ram) to include a load balancer, cached web server as a fun way to learn system design

I am a CS student and have been preparing for the system design interviews. I liked the concepts very much and I wanted to test the concepts without any burden of subscriptions. I got the question of "Well what if I just use the resources that I have at hand", so I did that. I used an old Samsung Galaxy J1 mobile with 1GB RAM and 16GB storage (didn't use the storage here). I was immediately faced with an issue: the phone bootloader was locked as it is a Verizon variant (my plan of using a Linux-based operating system failed here). So I did the next best thing: removed the bloatware to free up RAM using the adb program. Note for people who don't know what ADB is: Android Debug Bridge is a small program that runs in Android-based mobiles and can be accessed by enabling USB debugging in the mobile. So once we are done with this, I started to question how can I run the server. I was suggested the idea of creating a cross-compiled executable that can run in the specific mobile that I use. In Go, I did this by: GOOS=linux GOARCH=arm GOARM=7 go build -o server . Part 1: Hello from a Phone Part 2: A Load Balancer, in 60 Lines Part 3: A Cache, with Numbers Part 4: Fixing What the Numbers Showed The CPU That Was Never Ours Making It Public, from the Phone What I Actually Learned So let's start to write the code. A server is just a program that listens on the network and answers. The machine does not matter. The J1 has a Linux kernel and Wi-Fi, which is enough. The trick is that you do not install anything on the phone. Go cross-compiles a single static binary on my Mac that runs on the phone's chip. Then adb, the Android Debug Bridge, copies it over and runs it. func hello(w http.ResponseWriter, r *http.Request) { host, _ := os.Hostname() fmt.Fprintf(w, "hello from %s, you asked for %s\n", host, r.URL.Path) } func main() { http.HandleFunc("/", hello) log.Fatal(http.ListenAndServe(":8080", nil)) } GOOS=linux GOARCH=arm GOARM=7 go build -o server . adb push server /data/local/tmp/ adb shell "chmod 755 /data/local/tmp/server" adb shell "trap '' HUP; /data/local/tmp/server > /data/local/tmp/server.log 2>&1 &" Port 8080 because a non-root user cannot open ports below 1024. /data/local/tmp is the one folder on an unrooted phone where you may execute files. trap '' HUP makes the server ignore the hang-up signal the phone sends when adb disconnects, so I can unplug the cable. Things that went wrong, in order: adb push failed with device unauthorized. The phone was waiting for me to tap "Allow USB debugging" on its screen. ip addr prints 192.168.0.142/24. I pasted the /24 into curl. It is the subnet mask, not part of the address. nohup server & inside adb shell was a race. adb closes the session milliseconds after the &, and if the hang-up signal arrives before nohup is ready, the server dies with an empty log. Half my deploys silently failed until I understood that. Android 5.1 has no pkill, pgrep, awk, cut, tail or tr. My "kill the old server" line was silently doing nothing. I rewrote it as ps | grep tmp/ | while read user pid rest; do kill $pid; done. ps shows a process by the exact path it was started with. I started servers as ./server, then grepped for tmp/server. Nothing matched, and I accumulated orphaned servers holding every port. $ curl http://192.168.0.142:8080/test hello from localhost, you asked for /test A phone from 2015 answering HTTP on my desk, unplugged, on Wi-Fi and a charger. One server can only do so much, and if it dies everything is down. So I ran two copies on ports 8081 and 8082 and wrote a balancer for port 8080. Go's standard library does the forwarding (httputil.ReverseProxy), so the balancer is only two ideas: Round robin. Request 1 goes to A, request 2 to B, request 3 to A. Health checks. A goroutine asks each backend /stats every two seconds. If it fails, stop routing there. When it recovers, resume. The first thing the balancer did was mark backend 8082 dead. The backend was fine. I had typed http//127.0.0.1:8082 in the config, no colon. The system stayed up on one backend and the only way I found out was reading the log line the health checker printed when the state changed. Lesson: log state changes, not steady state. Then I killed a backend on purpose. The next one or two requests failed, the health check noticed, and everything flowed to the survivor. That gap is a real design parameter. A shorter check interval catches failures faster and burns more CPU on checking. That trade-off is the whole job. A cache only makes sense when something is slow, and you only believe it when you measure. So I added /user/<id>, which "looks up" a user in a fake database that takes 50 ms, and an in-memory cache in front of it: a Go map behind a read-write lock. I load tested from the Mac with hey. Test through the balancer Requests/sec 99% latency / trivial, 50 concurrent 280 481 ms /user/42 cache off, 50 concurrent 251 403 ms /user/42 cache off, 5 concurrent 67 190 ms /user/42 cache on, 5 concurrent 223 96 ms /user/42 cache on, 50 concurrent 290 510 ms / direct to one backend, 50 concurrent 1930 64 ms Four things I did not expect: Concurrency hides latency. With 50 requests in flight, the 50 ms database barely mattered. The cache only showed its 3x gain at 5 concurrent. Throughput and latency are different problems. The balancer was the bottleneck, by 7x. One backend alone did 1930 requests/sec. Through the balancer, 280. Cache stampede. Each backend showed 2 or 3 misses for one user, not 1. Several concurrent first requests all missed before the first had filled the cache. Scale that to a hot key expiring under real traffic and it is the burst that takes down a database. Two caches, not one. Each backend missed independently. Ten backends would mean ten misses per user. That is the argument for a shared cache node. Bounded cache with LRU eviction. The map grew forever. I replaced it with a map plus a doubly linked list (container/list): every get or set moves the entry to the front, and when the count exceeds the limit the back entry, the least recently used, is removed. I set the limit to 200 and requested 1000 distinct users: each backend ended at 200/200 with exactly 300 evictions. One consequence I had not appreciated: an LRU turns reads into writes, because every hit mutates the list, so the read-write lock had to become a plain mutex. TTL. Nothing in my fake database changes, but the cache does not know that. The day I add a write path, every server would serve the old value until eviction. Every entry now expires after a configurable time. Single-flight. The first request to miss on a key does the lookup. Everyone else arriving for the same key meanwhile waits for that result. Forty simultaneous first requests for a new user: 1 database call, 39 waited. Connection pooling in the balancer. Go's default transport keeps 2 idle connections per host, so under 50 concurrent requests the balancer was opening and closing TCP connections constantly. One shared transport with 100 idle connections per backend, plus removing a per-request log write to flash: Through the balancer, 50 concurrent Before After / 280 rps 396 rps /user/42 cached 290 rps 404 rps A 40% gain, not the 7x I hoped for. top on the phone explained it: 99% CPU, the balancer alone taking 39% and the kernel 34% moving packets. Every request through the balancer is handled twice on the same four slow cores. The rest of the gap is not a code problem. It is the balancer living on the same box as the things it balances. The fix is a second machine, which is the next post. While building the dashboard I added a phone CPU tile, and it read 96% with nothing running. top on the phone showed Google Play Services at 29%, the Play Store at 27% and system_server at 26%. The logcat was a loop of authentication errors: a wiped phone with no Google account, and Play Services trying anyway, forever. pm disable-user is refused for the adb shell user on Android 5.1. am force-stop is not. One force-stop each and the phone went from 98% CPU to 3%. Play Services restarted itself a minute later, calm this time, so I put the force-stop in the deploy script. Then I re-ran the same load tests: 50 concurrent Before After / through balancer 396 rps 1073 rps /user/42 cached, through balancer 404 rps 1182 rps / direct to one backend 1930 rps 3920 rps Everything nearly tripled and I had not changed a line of my code. That is the most important lesson of the day: when you measure, measure the whole machine. I had spent an hour tuning connection pools while two thirds of the CPU was being eaten by something I had never looked at. Real servers have their equivalent, a log shipper, a backup agent, a cron job someone forgot. The dashboard tile is there so nobody has to rediscover it. The phone serves a live dashboard at /dashboard: request flow, per-backend routing counts, cache hits, misses, shared lookups, evictions and expiries, refreshed every second, with a button that fires 100 requests so you can watch the counters move. First attempt at a public URL was a Cloudflare quick tunnel from my Mac pointed at the phone. One command, worked in a minute. Then I asked myself the question this whole lab exists for: what if the Mac is down? The link dies. The Mac was a single point of failure. So the tunnel had to run on the phone. Cloudflare ships a 32-bit ARM build, it ran, and it failed on the first DNS lookup. Go programs on Linux read /etc/resolv.conf to find a DNS server. Android has no such file, so Go falls back to asking localhost:53, where nothing listens. Go's own source has a comment: "DNS requests don't work on Android". Our server never noticed because it never resolves a name. I could not run a forwarder on port 53 either, that needs root. Cloudflare's anonymous quick tunnel has no way around that. ngrok's agent does: dns_resolver_ips tells it which DNS server to use by IP, and crl_noverify skips one side request that still used the broken resolver. With those two lines in its config and a free account, the phone registered its own tunnel and got a fixed hostname: THE SERVER IS LIVE HERE: https://wispy-uplifted-recycler.ngrok-free.dev/dashboard Nothing but the phone, a charger and Wi-Fi. Tailscale, my first thought, needs Android 8 and builds a private network rather than a public link. Everything above is in every system design book. The difference is that I now have a number attached to each concept, a failure I caused with my own hands, and a phone on my desk that still answers. When someone asks me about health check intervals, I remember the two failed requests. Next up: The CPU load is only throttling around an average of 5% as of now, we can push this even further! Will be testing more concepts as well. If anyone has any good suggestions or ideas, do share it. Code repository: github.com/g-charan/go-j1

Dev.to (Rust/Go)

~7 min readSep 19, 2026

Goroutine Ownership and Cancellation Contracts: Preventing Leaks in Long-Running Go Services

Goroutine Ownership and Cancellation Contracts: Preventing Leaks in Long-Running Go Services Goroutine leaks are not a beginner mistake. They are an architectural failure mode that compounds quietly over days, manifests as heap growth and latency spikes under load, and resists obvious reproduction in staging. A service handling ten thousand concurrent webhook deliveries or streaming AI tool-call results over SSE will leak goroutines whenever the caller abandons a request that the spawned goroutine never observes. The fix is not defer wg.Done(). It is a coherent ownership model: every goroutine has exactly one owner, that owner is responsible for both launching and terminating it, and termination is driven by a cancellation signal the goroutine actively polls or selects on. In Go, goroutines are cheap to create and invisible at runtime without explicit instrumentation. There is no parent-child relationship the scheduler tracks. That asymmetry creates a false sense of safety: the function that calls go f() moves on, but f may block indefinitely on a channel, a network call, or a mutex it will never acquire because the upstream request is already gone. In practice, ownership breaks down in three patterns: Fan-out without a shared context. A request handler spawns N worker goroutines using bare goroutines, collects results, then returns. If the handler returns early—due to a downstream timeout or a client disconnect—the goroutines have no signal. They continue running, hold references to closures that pin heap allocations, and potentially write to channels nobody is reading. Fire-and-forget background work. A service queues background jobs for cache warming, audit logging, or metric flushing using go func(). The goroutine blocks on a Redis write that is slow because the connection pool is saturated. The service restarts. The goroutine never exits. Goroutines as event loop proxies. A gRPC streaming handler or WebSocket server creates a per-connection goroutine that reads from a channel fed by an upstream subscription. If the subscription's producer exits without closing the channel, the reader blocks forever. context.Context is the canonical cancellation primitive in Go, but using it correctly requires treating it as a contract, not a parameter. The contract has three obligations: Every function that may block must accept a context.Context and respect its Done channel. The goroutine owner—not the goroutine itself—controls the context's lifetime. Cancellation must propagate structurally: child contexts cancel when parents cancel. Consider a bounded fan-out pattern that enforces this: func dispatchBatch( ctx context.Context, items []WorkItem, process func(context.Context, WorkItem) error, maxConcurrency int, ) error { sem := make(chan struct{}, maxConcurrency) g, gctx := errgroup.WithContext(ctx) for _, item := range items { item := item // capture loop var sem <- struct{}{} g.Go(func() error { defer func() { <-sem }() return process(gctx, item) }) } return g.Wait() } errgroup.WithContext derives a child context that is cancelled the moment any goroutine returns a non-nil error. The semaphore channel enforces bounded parallelism. Critically, process receives gctx, not the original ctx. If the caller's context is cancelled, gctx is also cancelled because it is a child. The goroutines observe cancellation through whatever blocking call they are inside—a database query, an HTTP round-trip, a Redis command—provided those calls accept and honor a context. The failure mode to avoid here is passing context.Background() inside the goroutine because "I don't want one failure to cancel the others." That severs the cancellation chain. If the parent request times out, the goroutines continue executing. The correct approach when you want independent goroutine lifetimes is to give each goroutine its own derived context with an explicit timeout, and still wire it to the parent via a select on both Done channels. Two instrumentation strategies surface leaks without requiring a production incident. runtime.NumGoroutine() as a health signal. Expose goroutine count in your /healthz or custom metrics endpoint. In a stable service under constant load, goroutine count should be bounded. A monotonically increasing count over a one-hour window under steady traffic is a reliable leak indicator. Wire this to an alert with a threshold relative to your expected concurrency ceiling—not an absolute number, since initialization goroutines, connection pool managers, and background flushers are legitimate. goleak in integration tests. The go.uber.org/goleak package captures the goroutine stack snapshot at test start, then diffs it at test end. Integrating it into table-driven tests that exercise each handler or worker lifecycle catches leaks during CI rather than post-deploy. func TestWebhookDispatch(t *testing.T) { defer goleak.VerifyNone(t) ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() err := dispatchBatch(ctx, testItems(), processItem, 4) require.NoError(t, err) } This test will fail if dispatchItem spawns goroutines that survive past g.Wait(). The stack trace in the failure output identifies the goroutine's creation site. A goroutine blocked on a full channel is not technically leaked, but it is stranded. The distinction matters operationally: a stranded goroutine still consumes stack memory (starting at 2–8 KB, growing on demand), holds closures and their referenced heap objects, and contributes to scheduler overhead. Under write-heavy load—say, a MongoDB change stream fan-out to downstream consumers—stranded goroutines accumulate faster than they drain. The production pattern is to never block a producer goroutine unconditionally on a downstream channel. Instead, apply backpressure with a timeout or drop semantics: func forwardEvent(ctx context.Context, ch chan<- Event, ev Event) error { select { case ch <- ev: return nil case <-ctx.Done(): return ctx.Err() case <-time.After(50 * time.Millisecond): // Emit a metric for backpressure drop. metrics.BackpressureDropsTotal.Inc() return ErrBackpressure } } The 50ms timeout is a design decision that belongs in your SLO tradeoff space. Dropping events is preferable to stranding the producer goroutine, provided the consumer is instrumented to surface the drop rate. If the drop rate is nonzero under normal load, the channel buffer is undersized or the consumer is too slow—both are capacity problems, not concurrency bugs. The most common source of goroutine leaks in long-running services is not request handling—it is graceful shutdown. A service that receives SIGTERM must signal every background goroutine, wait for them to exit, drain in-flight work, then exit. Without this, Kubernetes will SIGKILL the process after the termination grace period, losing in-flight writes to MongoDB, uncommitted offsets in a Kafka consumer, or partially streamed AI responses. The ownership model makes structured shutdown straightforward: if every goroutine is owned and cancellable, shutdown is a matter of cancelling the root context and waiting on a sync.WaitGroup. func main() { rootCtx, rootCancel := context.WithCancel(context.Background()) var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() runChangeStreamRelay(rootCtx) }() wg.Add(1) go func() { defer wg.Done() runWebhookDispatcher(rootCtx) }() sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT) <-sigCh rootCancel() // Signal all goroutines. wg.Wait() // Wait for clean exit. } Each subsystem—change stream relay, webhook dispatcher, cache warmer—is a named, owned goroutine. rootCancel() propagates through every derived context in the call tree. wg.Wait() gives in-flight operations time to observe the cancellation and return. If a subsystem's shutdown takes longer than the Kubernetes termination grace period, that is an operational signal to either increase the grace period or instrument why the goroutine is slow to exit. Apply this checklist when reviewing any goroutine-spawning code for production readiness: Ownership. Is there exactly one function responsible for this goroutine's lifecycle? Is it the same function that spawned it? Cancellation. Does the goroutine accept a context.Context? Does every blocking call inside it propagate that context? Are there any time.Sleep calls that should be select { case <-ctx.Done(): ... case <-time.After(...): ... }? Bounded parallelism. Is the number of concurrently running goroutines capped? Is the cap derived from a measured resource constraint (CPU, memory, downstream connection pool size) rather than an arbitrary constant? Backpressure. Does the goroutine block on channel sends? Are those sends guarded by a ctx.Done() select arm? Is the drop or timeout behavior instrumented? Shutdown. Is the goroutine registered with a WaitGroup that the main shutdown path waits on? Does the owning subsystem handle ctx.Err() returns by flushing state before exiting? Leak tests. Does the test suite include a goleak.VerifyNone assertion in at least the integration-level tests for this component? Goroutine ownership is not a concurrency nicety. It is the mechanism by which a Go service remains predictably bounded under production load, restarts cleanly, and surfaces resource problems as metrics rather than as out-of-memory events at 3 AM.

Golang Weekly

~4 min readSep 18, 2026

A native IDE written in Go goes open source

#618 — September 18, 2026 Read the Web Version Go Weekly Size-Specialized Memory Allocation in Go 1.27 — Small allocations (under 80 bytes) are now up to 30% faster, and you can get the benefits just by rebuilding. Learn where the speedup comes from and why 80 bytes was the "sweet spot". Allocation-heavy programs could see a ~1% gain overall. Michael Matloob (The Go Blog) Stay Sharp in the Age of AI — Master.dev instructors build at Anthropic, OpenAI, Netflix, Google, and Stripe. Learn from them with hundreds of courses, live workshops, and expanded AI learning paths. New members get $100 off a yearly membership. Master.dev sponsor Data Races and the Limits of ThreadSanitizer in C and Go — A tour of how ThreadSanitizer (the engine behind race detection in Go) works, and the easily reachable limits where it stops catching real races. Two objects in unrelated sync.Pools colliding in Go's 128-slot table is enough to hide a race. Phil Eaton IN BRIEF: The proposal for cgo without a C toolchain from last week's issue is progressing, with a CL adding a GOEXPERIMENT to trial it ahead of any approval. The first bare-bones draft Go 1.28 release notes are available to skim, ahead of the expected February 2027 release. 🔒 The Rust team has put out an alert to maintainers of popular libraries saying there's an 'ongoing campaign' targeting them in order to compromise their systems. Go is not immune to this, so stay alert. 🇪🇺 GopherCon Europe 2027 has been announced for Berlin next June 14–17. 🇮🇹 GoLab 2026 takes place in Bologna, Italy on November 1–3. A 40ms Go GC Pause Caused by Swap — “I’m writing this so you don’t slap your forehead like I almost did when I decided to run swap in production to absorb memory spikes.” Fernando Simões Scaling Go in CI by Replacing actions/setup-go — How GitHub's official actions/setup-go lets parallel jobs interfere with each other's caches, and why its cache goes stale until you touch go.mod. CloudX's alternative gives each CI job its own isolated cache. Schwab and Downs (CloudX) CodeAF: A New Open-Source Software Factory, Written in Go — You direct the work from one window for every project. It splits, runs, tests and merges, and asks only when it must. AgentField.ai sponsor 📄 A Million Go Map Entries Take 38MB, Not 16MB – A look at where the extra bytes go in Go’s Swiss table map implementation and why map[T]struct{} no longer saves memory over map[T]bool. Nazar Boyko ▶️ Numbers: The Long History Behind Go's Untyped Constants – A history-heavy talk on how 1960s word sizes gave C its integer literal mess, and why you’ll never see 0x80ULL in Go code. Dave Cheney ▶️ Building a Web App with Go and HTMX Haseeb Majid 🛠 Code & Tools Rune: A Fast, Native, Open Source IDE Built in Go — A GPU-accelerated IDE (shown off here) that’s now GPLv3 licensed. This post has interesting details on how they got their integrated terminal almost as fast as Alacritty and Ghostty without using cgo for the hot path. GitHub repo. Ernest Romero Climent 💡 Rune is also an interesting case study for using (a fork of) Ebitengine for its GPU-powered rendering. golang-set 3.0: A Simple, Well-Tested, Generic Set Type — While a future Go release might be adding a generic set type, this is a mature option for now. v3.0 improves performance, adds Filter and AppendFrom methods, and removes Mongo BSON support. Ralph Caraveo wasm2go: Translate WebAssembly Binaries into Go Code — A compiler to translate WASM binaries into a standalone Go package, so you can ship, say, a C library built with the WASI SDK inside a Go app without the added weight of a WASM engine. Masaaki Goshima 💡 If 'wasm2go' sounds familiar, there's also ncruces/wasm2go which powers the cgo-free go-sqlite3. The key difference is ncruces/wasm2go emits pure Go, while goccy's also generates amd64 and arm64 assembly. GoHT: Haml, Slim and EGO Template Engine for Go — Write templates alongside normal Go code. Use @haml, @slim, or @ego blocks in a .goht file, then run the generator to produce HTML-rendering Go functions. Michael Stack 📰 Classifieds Software Engineer - Join our "kick ass" team! Our software team operates from 17 countries and we're looking for more exceptional engineers to join our team. 🐘 Since many Go backends end up talking to Postgres, you may also like our sibling newsletter: Postgres Weekly. str2duration 2.2 – Get a time.Duration from a string like 1h or 1w2d3s. html2text 1.5 – Convert HTML to plain text with no dependencies. Goldmark 2.1 – Popular Markdown parser and rendering library. ✉️ enmime 2.5 – MIME mail encoding and decoding package. gRPC-Go 1.84.0 – High perf gRPC framework. go-diff 0.9 – diff parser and printing library.

LoadingCurating your feedFetching the latest articles from your sources…