Stackbook Logo
architecture-descriptionestablished · medium operational burden

Microkernel Architecture

Also known as: plugin-architecture, plug-in-architecture

Intent

Keep a minimal stable core and extend functionality through independently developed plug-ins.

Problem

Products that must support many optional or customer-specific features accumulate conditionals and release risk in a single codebase. Third parties and teams cannot add capabilities without touching the core.

Forces

  • •Core must stay small and stable
  • •Extensions are developed on different schedules, sometimes by third parties
  • •Plug-ins must not destabilize the host
  • •Contracts between core and plug-ins must evolve compatibly

Solution

Overview

Microkernel architecture, also called plug-in architecture, gives the core only what every feature needs and pushes everything else into plug-ins. Eclipse, VS Code, and many CI tools follow this model.

How it works

The core defines extension points, such as an interface for exporters or validators. Plug-ins register implementations and declare metadata, including the API version they target.

          +-------------------+
          |   Core (kernel)   |
          | registry, config, |
          | lifecycle, events |
          +----+----+----+----+
               |    |    |
          [PluginA][PluginB][PluginC]

interface Plugin { id: string; apiVersion: string; init(ctx: Context): void }
registry.load(manifest)  // check apiVersion, then init

At startup the registry scans a directory or manifest, checks compatibility, and initializes plug-ins in a declared order. Calls to plug-ins are wrapped in timeouts and error handlers so a faulty one is disabled rather than crashing the host.

Pitfalls

  • Exposing internal classes as the extension API, locking the core forever.
  • Letting plug-ins depend on each other without declaring it.
  • No version negotiation, so upgrades break plug-ins silently.
  • Running untrusted plug-ins in-process without sandboxing or permission limits.
  • Starting with a plug-in system before two real extensions exist to validate the API.

Key takeaways

  • Keep the core minimal and the extension API deliberately small.
  • Version the API and check compatibility on load.
  • Isolate plug-ins according to how much you trust them.
  • Design the API from real use cases.

✓ When to Use

  • •Products with an extension ecosystem like IDEs or build tools
  • •Customer-specific features without forking the product
  • •Rule engines or workflows with swappable steps

✗ When Not to Use

  • •Stable systems with a fixed feature set
  • •When extension points cannot be predicted
  • •Strict performance paths where indirection is unacceptable

Pros

  • +Extensibility without core changes
  • +Features can be shipped and tested separately
  • +Isolated failures when plug-ins are sandboxed

Cons

  • −Extension API becomes a long-term compatibility commitment
  • −Plug-in discovery and versioning add complexity
  • −Cross-plug-in interactions are hard to reason about

Cost Profile

Infrastructure

Low — in-process; higher if sandboxed per process

Operational

Medium — plug-in lifecycle and compatibility

Cognitive

Medium to high — API design and isolation

Failure Modes

  • Plug-in crash or memory leak taking down the host

  • Breaking changes in the extension API stranding plug-ins

  • Hidden dependencies between plug-ins causing load-order bugs

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      economics evolutionrequirements constraints