Atharva Pandey Gopherine

There’s a pattern that comes up constantly in backend services: make N concurrent calls, collect all their results, and if any one of them fails, cancel the rest and return the error. This is the “all succeed or all cancel” pattern — and before errgroup, implementing it correctly required a non-trivial amount of boilerplate involving WaitGroup, error channels, and manual context cancellation. People got it wrong often enough that errgroup was created specifically to handle it.

I have a strongly held opinion about timeouts: if you’re making a network call, a database query, or waiting on any external resource without a timeout, you’ve written a production bug. It just hasn’t fired yet. The network will eventually hang. The database will eventually have a slow query. The external API will eventually stop responding. And when it does, your goroutine will wait. And wait. And wait — holding a connection, a file descriptor, a slot in your worker pool — until the process runs out of resources or someone restarts it.

In Java or C#, you declare that a class implements an interface. You write implements Runnable, and the compiler ties that class to that interface forever. Go doesn’t work that way. A type satisfies an interface the moment it has the right methods — no declaration, no explicit relationship. This sounds like a minor syntactic difference, but it changes how you design systems in ways that compound over time.

The Problem

When interfaces are declared by the implementor (the Java way), you end up with a few recurring problems.

Tree DP is the pattern that catches people by surprise. You’ve been thinking of DP as filling a 1D or 2D table from left to right — a sequential, iterative process. Trees are recursive by nature. The “table” is implicit in the call stack.

The key insight: tree DP is just post-order traversal where each node computes its answer from its children’s answers. There’s no explicit table. The memoization (if you need it) is keyed by node pointer. The bottom-up order is inherently satisfied because post-order visits children before parents.

Goroutine leaks are the memory leaks of concurrent Go. They’re slow, invisible, and tend to surface only under load — or worse, only after days of continuous running when the service has accumulated tens of thousands of stuck goroutines. I’ve debugged two production incidents that traced back to leaks in code that had been in production for months, completely unnoticed during normal load.

The root cause is almost always the same: someone started a goroutine and didn’t give it a way to exit. Not a way to exit eventually — a way to exit in every possible code path.

“Goroutines are cheap” is something you read in every Go introduction. It’s true. A goroutine starts with a 2KB stack and the runtime handles scheduling. Spinning up a thousand of them is trivial. The part the introductions leave out is that “cheap” is not “free,” and goroutines that you start and never stop are a leak — one that doesn’t crash your program, just slowly eats your memory and degrades your scheduler until something gives.

String DP has its own flavor that’s distinct from the two-string comparison problems of the last lesson. Here, the state is typically a single string, but the subproblem is about a range within that string: “what’s the answer for the substring s[i..j]?” That’s interval DP applied to strings, and palindromes are its most natural setting.

The tricky part with palindrome problems is that you can approach them from the outside in (is s[i..j] a palindrome?) or the inside out (expand from a center). DP works from the outside in: small intervals first, then build up to larger ones. The expansion approach is often faster in practice but DP is more general and extends to partition problems naturally.

Here’s a scenario that played out for me once: service is running fine for weeks, then we double traffic, and suddenly requests start timing out. Not all of them — maybe 10%. The logs show pq: sorry, too many clients already. Postgres is refusing connections. But we have a connection pool — that’s the whole point, right? Why is Postgres seeing more connections than it can handle?

Because database/sql’s default pool settings are almost certainly wrong for production, and most people never change them.

Most Go services handle startup carefully and shutdown carelessly. The startup code has retries, health checks, dependency validation. The shutdown code is os.Exit(0) or — if the developer was feeling generous — nothing at all, just letting the process get killed. That’s how you get dropped HTTP connections, half-written database records, uncommitted Kafka offsets, and on-call alerts at 3am.

Graceful shutdown has one principle: stop accepting new work, finish what you already started. That’s it. But implementing it correctly requires knowing the shutdown order, wiring up OS signals properly, and draining workers before pulling the plug.

In most languages, errors are events — they get thrown, they propagate up the call stack, and you catch them somewhere above. Go rejects this model entirely. In Go, an error is a value, just like an integer or a string. You pass it around, inspect it, wrap it with context, and check it right where it happens. Ignore it and your code doesn’t crash loudly; it quietly does the wrong thing, and you’ll find out at the worst possible moment.