a microkernel
/ MY-kroh-ker-nel /
If a monolithic kernel is one workshop where everyone shares the bench, a microkernel is a design that says: keep only the bare essentials inside the trusted core, and push everything else out into ordinary, unprivileged programs called servers. The microkernel itself does as little as possible - typically just managing address spaces, scheduling threads, and passing messages between them. The filesystem, the network stack, even most device drivers become separate user-mode server processes that talk to each other and to your application by sending messages through the tiny kernel.
Here is how a file read works in this world. Your program does not call filesystem code directly; instead it sends a message ('read these bytes of this file') that the microkernel routes to the filesystem server, a normal process running in user mode. That server may in turn message a disk-driver server, which messages back, until the answer travels home to you. Each arrow is a message and a controlled hand-off through the kernel, not a plain function call. Mach (pronounced 'mock') was an influential early research microkernel; L4 is a famous family designed to make the message passing extremely fast; the seL4 microkernel has even been formally verified, meaning its core has a mathematical proof of correctness.
The appeal is isolation as a trust boundary: if the network driver crashes, it is just one user process dying, which can be restarted, while the kernel and the rest of the system keep running - a bug in one server cannot freely scribble on another server's memory. The classic cost is performance: replacing a direct function call with a message that crosses the user/kernel boundary (and often a context switch) adds overhead, which historically made microkernels slower. Modern designs like L4 narrowed that gap dramatically, and the idea lives on in many systems even where a pure microkernel did not win outright.
app --msg--> [microkernel routes] --> filesystem server (user mode) --msg--> disk driver server (user mode) -- each hop is a message through the kernel, not a direct call; a crashed server can be restarted.
In a microkernel the filesystem and drivers are ordinary user-mode servers; work happens by message passing, so a crash is isolated.
A common myth is that microkernels are 'always too slow to be practical.' That was true of early designs (Mach added heavy IPC overhead), but L4-family kernels showed message passing can be made very fast, and seL4 is both fast and formally verified - so the real trade is more about engineering effort and where you draw the trust boundary than raw impossibility.