Beyond the general isolation-vs-overhead trade-off, what specific production failure modes have you seen or would you expect in mature microkernel/plug-in systems, and when would you actively steer a team away from this pattern?

## The judgment behind a recommendation Recommending or rejecting a microkernel architecture at the principal level means being able to point to specific failure modes observed in production, not just reciting the abstract cost side of the trade-off, and being willing to say 'don't do this' when the system's actual shape doesn't warrant it. ## The illusion of complete isolation The first and most deceptive failure mode is the illusion of complete isolation. Classloader-per-plugin isolation genuinely prevents naming and versioning conflicts between plug-ins, and a well-designed core can catch exceptions a plug-in throws at its call boundary and disable that plug-in without crashing the process. But none of that stops a misbehaving plug-in from exhausting a resource the whole process shares: - **the heap** — an unbounded cache or a memory leak in one plug-in triggers an out-of-memory error for everyone; - **a shared thread pool** — a plug-in that blocks or busy-loops on a shared executor starves every other plug-in's work; - **file descriptors.** Teams that treat 'we run in isolated classloaders' as equivalent to 'a bad plug-in can't hurt the rest of the system' get burned the first time a plug-in leaks memory or hangs a shared thread pool, because in-process plug-in isolation is boundary isolation for code and types, not resource isolation — real resource isolation requires separate processes or containers, which most in-process plug-in systems don't provide. ## Silent version skew The second failure mode is silent version skew across an ecosystem that's grown organically over years. In any long-lived plug-in platform, you eventually have plug-ins built against several different generations of the core's contract coexisting, because not every plug-in author updates promptly, or for third-party plug-ins, ever. Most of the time this works because the core maintains backward compatibility, but it means the actual tested configuration space is enormous — a core version with one plug-in at an older contract's semantics and another at a newer contract's semantics is a combination that may never have been explicitly tested, and the failure, when it happens, tends to be an obscure edge case that's very hard to reproduce because it depends on the exact combination of installed plug-ins and their versions, not just the core's version. Long-lived IDE bug histories include exactly this shape: crashes reproducible only with two specific plug-ins both installed together. ## Cascading startup fragility The third is cascading startup fragility: if the lifecycle machinery doesn't treat each plug-in's discovery, resolution, and activation as independently fault-isolated, one plug-in throwing during activation can abort the startup sequence for plug-ins that would otherwise have loaded fine, turning one broken third-party plug-in into a fully broken application for the user — a well-built platform instead catches per-plug-in activation failures, logs them, marks that one plug-in disabled, and continues bringing up the rest. ## The debuggability tax The fourth is a pure debuggability tax: a stack trace that crosses a plug-in boundary through a registry-mediated dynamic dispatch carries less context than a direct call in a monolith — you often see the core's dispatch frame and the plug-in's entry point, but the intervening 'why was this plug-in even invoked here' context that a direct call chain would preserve is harder to reconstruct, especially when the actual implementation behind an interface is chosen dynamically at runtime rather than being visible from reading the calling code. ## When to steer a team away Given these costs, I would steer a team away from a microkernel architecture in several concrete situations: 1. **When the feature set is small and genuinely stable** — three or four features that always change together gain none of the fault-containment or independent-deployability upside while paying the full indirection and debugging cost. 2. **When a single team owns the entire codebase with a unified release cadence**, since the core reason for independent plug-in lifecycles, decoupled release schedules across teams or vendors, doesn't exist. 3. **And, importantly, when the team reaches for 'plug-in' as a vocabulary word without actually building the isolation and lifecycle machinery behind it** — defining a strategy-pattern interface with a few implementations selected by config is a perfectly good design, but calling it a 'plug-in architecture' without a real registry, versioned contract, and lifecycle model just borrows the pattern's complexity without earning any of its benefits. The tell for that last case, in review, is a 'plug-in system' with no plug-in that's ever shipped, deployed, or versioned independently of the core.