Your Go service needs a blocking C codec — how do you decide between keeping it in-process with a thread cap and moving it out?

## The decision, stated honestly A transcoding service must run a C codec. Two shapes are on the table: call it from Go through cgo, or run it in a separate worker process the Go service talks to. This is not a taste question and it is not a performance micro-benchmark. It is a capacity and blast-radius decision with an owner, and it is normally settled by four numbers and two risks. ## The four numbers **1. Time inside the call.** Measure it, at the percentiles that matter. A call that takes 50 microseconds and a call that takes 8 seconds are different products. While a goroutine is inside C, the operating-system thread carrying it is unavailable to the runtime. **2. Concurrency at peak.** How many of those calls are in flight simultaneously at the traffic you actually plan for, not the average. **3. Thread demand = 1 × 2.** Arrival rate times duration. This is the number of OS threads the runtime will be pushed to create, and it appears nowhere in the source code, which is why it surprises teams in production. **4. Memory per thread.** Kernel bookkeeping plus a system stack; threads created for calls into C get the platform's default thread stack reservation, commonly 8 MB of address space each on Linux, resident as it is touched. Multiply by number 3 and compare against the container's memory limit. Remember that the runtime does not reap idle threads, so the peak is the permanent floor. If those four numbers put you comfortably inside the memory budget with room for a bad day, in-process is a reasonable answer. If they do not, no amount of tuning rescues it, and the argument is over. ## The two risks **Blast radius.** Everything in one process shares one fate. A fault or a runaway allocation inside the C library takes down the API traffic that had nothing to do with transcoding. A separate worker turns that into a failed job and a restarted worker. **Debuggability.** Thread growth caused by C calls is visible from Go only indirectly — a thread count against a flat goroutine count, a threadcreate profile that under-reports, stacks that stop at the boundary. Out of process, the same problem is a worker's resource usage that your existing operating tools already understand. ## What each option actually costs **In-process, bounded.** You pay engineering discipline: exactly one choke point in one package, with a counting semaphore in front of the C call, sized from measurement, with queue depth and wait time exported. You pay a permanent memory floor set by the bound. You gain no serialisation of the payload, no extra hop, and one binary to deploy. The bound is load-bearing — without it the design has no capacity limit at all — so it must be owned, tested and impossible to bypass, not a convention. **Out of process.** You pay latency for the hand-off, a serialisation cost on a large blob, a supervision and restart story, and a second artefact to build, ship and version. You gain isolation, an independent memory limit, the ability to scale codec capacity separately from request capacity, and an out-of-memory kill that lands on a worker rather than on the API. The blob size matters here: passing a large payload across a process boundary is a real cost that a shared-memory or file hand-off can reduce, and it should be measured rather than assumed either way. ## Where the thread ceiling fits `debug.SetMaxThreads` will come up, usually from whoever carries the pager, in the form "cap it at 500 so we find out immediately". Be clear about what a cap is and is not. It is **not** a throttle. Crossing it is a fatal runtime error: the process dies, `recover` cannot intervene, and in-flight requests unrelated to transcoding die too. It **is** an excellent tripwire: an early crash with full stacks, close in time to the cause, is a far better artifact than a slow slide into an out-of-memory kill with nothing to read. So the two positions are both rational. On call wants a fuse because an unbounded leak at 3am with no stacks is the worst outcome for them. The service owner resists because a fuse converts degradation into a crash loop and spends the availability budget. The resolution is not to pick a side but to order the controls: the **concurrency bound** is the control, the **ceiling** is the tripwire set well above it, and the crash is treated as a bug report rather than as the mitigation. Then write the number down, with the reasoning and the name of whoever accepted it, so the next incident does not relitigate it from scratch. ## The policy layer At organisation scale the useful rule is not "cgo is banned" or "cgo is fine". It is: a blocking foreign call is allowed only behind a single owned interface with an enforced concurrency bound, a documented thread and memory budget derived from the four numbers above, an explicit process thread ceiling, and an alert on thread count against goroutine count. A team that cannot produce those four numbers has not finished the design, and that — not the language of the codec — is what a reviewer should push back on. ## What would change your mind later Call duration regressing after a codec upgrade; peak concurrency growing past the bound often enough that queue wait becomes the latency story; a memory limit cut; or a second team wanting the same codec, at which point a shared worker is cheaper than two bounded copies. Name those triggers when you make the call, so the decision has an expiry condition rather than becoming folklore.