InterviewKata
Software architecture · Level 3: Architecture styles · Module 12 of 46

Microkernel

Some products are the same everywhere except for the parts that differ: tax rules per country, claim rules per state, file formats per customer, features per edition. The microkernel style (also called plug-in architecture) puts what's common in a small, stable core and everything that varies in plug-ins. Your code editor and your browser work this way, and so do many insurance, tax and payment systems.

See it builtThe Architecture styles track builds this style for one bike-share app, with code you can run: 05 Microkernel (plugins).

1. The idea

A games console. The console itself (the core) handles the screen, the controllers, saving and the store. Each game is a cartridge that plugs in through one standard slot. New games arrive every week without anyone opening the console, and a buggy game crashes itself, not the console. The slot's shape, the contract, is what makes it work.

The core system

The minimum needed to run: the main workflow, shared services (logging, security, persistence), and the plug-in registry that knows which plug-ins exist and how to reach them. A good core changes rarely.

Plug-ins

Independent components with the variable behaviour: one per jurisdiction, file format, customer or feature. Each implements a contract the core defines (an interface, or a message format). Plug-ins shouldn't depend on each other.

Plug-ins can be connected in-process (libraries or modules loaded at start-up or runtime: simple and fast) or remotely (separate services called over REST or messaging: isolated and separately scalable, at the cost of distribution). Most microkernel systems are one deployment with in-process plug-ins.

How it rates

CharacteristicMicrokernelModular monolith
Partitioningdomain and technicaldomain
Quanta11
Cost★★★★★★★★★★
Simplicity★★★★★★★★★★
Scalability★★★★★★★★★★
Elasticity★★★★★★★★★★
Fault tolerance★★★★★★★★★★
Evolvability★★★★★★★★★★
Deployability★★★★★★★★★★
Testability★★★★★★★★★★
Performance★★★★★★★★★★

Our qualitative ratings, 1 to 5 stars, more is better (for cost, more stars = cheaper). They compare styles in general; your context can move any of them.

2. How it works

Claims processing with a plug-in per state

An insurer handles car claims in several US states, each with its own rules for what's covered and how settlements are calculated. Watch a claim being routed, a new state being added, and a faulty plug-in being contained.

What the core looks like without plug-ins

The same rules written inside the core turn into a growing chain of conditions. Every new state changes, retests and redeploys the core.

3. Try it yourself

Run the plug-in registry

Install or remove state plug-ins, mark one as faulty, and watch five incoming claims get routed. Note that the core never changes.

4. Trade-offs

Extensibility vs a stable contract

Plug-ins make variation cheap, as long as the contract fits them. A contract that keeps needing new methods forces every plug-in to change. Design it from several real variations, not one.

In-process vs remote plug-ins

In-process plug-ins are fast and simple but share the core's process: a memory leak in one hurts all. Remote plug-ins isolate and scale separately, and bring every fallacy of Module 10.

Generic core vs useful core

A core that does too little pushes duplicate code into every plug-in; one that does too much grows conditionals for each variation. Put in the core exactly what every plug-in needs.

Plug-in data

Plug-ins that need their own reference data (a state's rate tables) should own it, passed through the contract or stored alongside the plug-in, rather than adding tables and columns to the core's database.

5. In real projects

Everyday microkernels: code editors and IDEs (extensions), web browsers (add-ons), build servers (plug-ins for every tool), content management systems (modules and themes), and payment platforms (a connector per payment provider).

Business microkernels: tax software with rules per country, insurance claims per jurisdiction, and products sold to many customers with customer-specific behaviour. The tell-tale sign the style fits is a growing switch or if on country, customer or product type spread through the code.

It combines well. A microkernel can live inside one service of a larger distributed system, and a plug-in can itself be a remote service. Module 17 covers combining styles.

Say it in the interview

Two-sentence answers
  • "What is microkernel architecture?" A minimal core system plus plug-ins that hold the variable behaviour, connected through a contract and a plug-in registry. It fits products with a stable core and many variations.
  • "How do you add a new variation?" Write a plug-in that implements the contract and register it. The core doesn't change, so it doesn't need retesting.
  • "What's the main risk?" A contract that doesn't fit the variations, which pushes special cases back into the core until it becomes a tangle of conditions.
Red flags interviewers notice
  • Plug-ins that call each other directly.
  • "If state == TX" logic still sitting in the core.
  • No plan for a plug-in that throws errors or runs slowly.

6. Remember it

Memory hook: "Console and cartridges"A stable console, a standard slot, and games that come and go without opening the box.
How this hook works: what "console and cartridges" means

What the slogan means, phrase by phrase

"Console"
The core system: small, stable, rarely changed.
"cartridges"
Plug-ins: the variable behaviour, added and removed freely.

Why this picture fits: everyone knows a new game doesn't require a new console, and a bad game doesn't break it. That's exactly the promise, and the slot is the contract that makes it true.

The story → the concept

Games consoleMicrokernel
The consoleCore system
The cartridge slotPlug-in contract
The game library menuPlug-in registry
A game crashing to the menuIsolating a faulty plug-in

The trap it saves you from

Building the variations into the core, so every new customer or country is a core release.

7. Common mistakes

A contract that leaksA contract shaped around the first plug-in. The second one needs something else, and the special case goes into the core.
Plug-ins depending on plug-insOnce the Texas plug-in calls the California one, they can't be released or removed independently.
No isolationOne plug-in's exception or infinite loop takes down every claim. Catch, time out and disable faulty plug-ins.
Using it without variationA plug-in architecture with one plug-in is just indirection.

8. Design exercise (30 minutes)

  1. Find the switch (10 min). Search a codebase you know for conditions on country, customer, product type or edition. Count how many places each appears.
  2. Design the contract (15 min). Write the interface a plug-in for that variation would implement: its methods, inputs and outputs. Check it against three real variations.
  3. Plan for failure (5 min). What should the core do if a plug-in throws, hangs or returns nonsense?

9. Self-check quiz

The insurer starts selling in Ohio. With a microkernel, what changes?

Variation lives in plug-ins; the registry learns about the new one.

What does the plug-in registry do?

The core asks the registry which plug-in handles this claim.

How should plug-ins share information?

Independent plug-ins can be added, removed and released alone.

Which sign suggests a microkernel would fit?

Variation by a dimension is exactly what plug-ins absorb.

Which characteristics is microkernel strongest at?

It's usually one deployment, so scaling is like a monolith; variation is its strength.

10. Go deeper

ResourceTimeWhy
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)bookThe microkernel chapter, with registries, contracts and examples.
VS Code extension manifest15 minA real plug-in contract and registry: how an editor learns what each extension provides.
Software Architecture Patterns, 2nd edition (Mark Richards)short bookA concise overview of microkernel alongside the other styles.