Your recursive catalogue walk overflowed the stack in production — do you convert it to an explicit stack?

## Diagnose before you rewrite A stack overflow in a recursive tree walk has two very different causes, and the conversion to an explicit stack helps with exactly one of them. **Cause one: the data really is that deep.** Somebody imported a supplier catalogue nested six hundred levels, or a customer built a category chain by hand. The recursion is structurally unsafe: its depth is a function of input you do not control, and it will fail again on the next big import. **Cause two: the traversal is not terminating.** A category whose parent link points at one of its own descendants makes the walk cyclic; the depth is unbounded not because the data is deep but because it is malformed. The measurement that separates them is cheap: track maximum depth reached and log the path when it exceeds a threshold. If the deepest legitimate path in your domain is on the order of tens and the walk reached thousands, you have cause two, and converting to an explicit stack is actively harmful — it takes a failure that is immediate, loud and attributable to one request and converts it into steadily growing memory, degraded latency for everything sharing the process, and eventually a much less informative death. ## What the conversion actually buys Suppose the depth is legitimate. The rewrite does not reduce asymptotic space: you still hold one entry per level of the current path, plus the unexplored siblings along it. What changes is where that state lives and how it fails. A thread's call stack is typically a contiguous region whose size is fixed when the thread is created, and exceeding it is a hard, immediate failure. Runtimes differ sharply here — some, such as Go and Erlang, give each lightweight task a small stack that grows on demand, while others, such as the JVM and native C-family threads, reserve a fixed size per thread — but in every case it is a smaller and less elastic budget than ordinary allocated memory. An explicit stack lives in that ordinary memory: it grows as needed, it holds compact entries rather than full frames with parameters, locals and a return address, and its size is something you can inspect, cap, and report on. So the honest claim is not "less memory" but "the same order of state, in a place with a far more forgiving limit and observable size". ## The alternatives worth pricing **Raise the stack budget.** The one-line change, and sometimes correct — but it is a per-thread cost multiplied by every thread on every instance in the fleet, it is configuration that travels badly between environments, and it buys a constant factor of headroom against a depth that scales with data. It postpones the incident rather than removing it. **Bound the depth and fail cleanly.** Cap the traversal, and on breach reject the operation with the offending path in the error. This does not process deep catalogues, but it converts a process-killing crash into one failed request with a diagnosis attached. It is usually the fastest thing to ship and it is compatible with every other option. **Fix the data model.** If nesting deeper than some level is meaningless for the business, enforce that at write time and the problem disappears at the source, permanently, for every reader of the catalogue rather than just this one walk. **Chunk the work.** Process the tree in bounded pieces with the frontier persisted between them, which also gets you restartability. More machinery than the incident probably justifies unless the walk is long-running anyway. ## Pricing the rewrite honestly The explicit-stack version costs real maintainability. Sibling order silently reverses unless children are pushed in reverse — a defect no aggregate test catches. Any work the recursion did after its calls needs a resume point encoded by hand. The result is control flow the next reader must simulate mentally instead of reading, in place of a recursion that read like the definition of the problem. That cost is worth paying when depth is unbounded by data you do not control and the traversal must still complete — and not worth paying for a tree whose depth is bounded by a schema constraint you could simply enforce. ## What a good answer sounds like Ship the depth guard today so the crash stops and the offending catalogue is named. Use its telemetry to decide which cause you actually have. If it is malformed data, fix the data and keep the guard as a permanent invariant — the recursion was never the bug. If the depth is legitimate, convert the one walk that matters, push the children in reverse, add a test that asserts visit order rather than a total, and leave the other twelve recursive walks in the codebase alone.