One question, after four guides of mechanism
By now you have followed a kernel through its whole life. You watched it come alive from firmware and the bootloader, you traced a system call crossing the user/kernel boundary through the trap instruction and the system-call table, you saw interrupts steered and memory handed out by the buddy and slab allocators, and you watched it stay correct under preemption with locks. Every one of those pieces — the scheduler, the memory manager, the file systems, the device drivers, the network stack — has to live somewhere. This last guide is about that one architectural decision: where do we put all that code, and how much of it do we trust at the highest privilege?
Recall the one fact the whole rung rests on: in kernel mode the CPU will execute any privileged instruction, touch any physical address, and command any device, while in user mode it cannot. Code running in kernel mode has no guardrails. So the architectural question is really a question about trust: how big do we let the trusted, all-powerful part of the system be? Monolithic and microkernel are the two famous answers, and they pull in opposite directions.
The monolith: everyone in one room
A monolithic kernel puts essentially all the operating-system services — scheduler, virtual memory, file systems, drivers, the network stack — into one large program that runs entirely in kernel mode, in a single shared address space. Picture the building manager not just sitting at the front desk but personally being the electrician, the plumber, the security guard, and the mail sorter, all in one room with one set of keys. When the file system wants the disk driver, it does not send a message and wait; it simply calls a function, the way one part of any ordinary program calls another. That is the monolith's whole appeal: services talk by direct function call, which is about as cheap as communication gets.
Linux is the towering example, and it is worth being honest about a misconception here: 'monolithic' does not mean 'one frozen blob you cannot change'. Through the loadable kernel modules you met in the previous guide, a monolith can load a new driver or file system into the running kernel on demand. But — and this is the crucial point — a module loaded into a monolithic kernel runs inside that same trusted address space at full privilege. It is still everyone in one room; you have just let a new person in through the side door with a full set of keys.
The microkernel: tiny core, servers outside
A microkernel makes the opposite bet. It shrinks the part running in kernel mode down to the bare minimum that absolutely needs full privilege — typically just three things: managing address spaces, scheduling threads, and passing messages between them. Everything else — the file system, the drivers, the network stack, even much of virtual memory policy — is evicted from the kernel and rewritten as ordinary user-mode programs called servers, each in its own protected address space, each just another process to the tiny core. The building manager now does almost nothing but route messages; the electrician and plumber are separate contractors in their own locked offices down the hall.
The payoff is robustness through isolation. If the file-system server has a bug and crashes, it is just a user process dying — the kernel survives, and a supervisor can often restart the failed server while the rest of the system keeps running. A faulty driver can no longer scribble over the scheduler's data, because it literally has no access to the scheduler's memory; it lives behind the same hardware wall that protects one app from another. This is the deep reason microkernels are favored where failure is unacceptable: avionics, medical devices, secure enclaves.
But there is no free lunch, and the bill arrives at communication. In a monolith, the file system reaching the disk driver is a function call. In a microkernel, the file-system server reaching the disk-driver server is inter-process communication — message passing that must travel through the kernel. And a trip through the kernel means a context switch: trap into the kernel, copy or map the message, switch address spaces, schedule and run the other server, then make the whole journey back. Where the monolith pays one cheap call, the microkernel pays the cost of crossing the protection boundary several times. The microkernel trades IPC cost for robustness — that single sentence is the entire debate in miniature.
Worked trace: one read(), two architectures
Nothing makes the trade concrete like watching the same operation happen both ways. Take a program asking for a chunk of a file with the system call you know well, read(fd, buf, n), where the data is not yet cached and must come from the disk. The user side is identical in both worlds — the wrapper traps into the kernel exactly as the second guide of this rung described. What differs is everything that happens after control lands inside.
MONOLITHIC (one address space, function calls):
read() trap --> VFS layer --> ext4 code --> block layer --> disk driver
(all just function calls inside the kernel)
--> driver issues I/O, data lands in kernel buffer, copied to user buf
Boundary crossings: 1 (the syscall trap in and the return out)
MICROKERNEL (separate servers, messages):
read() trap --> microkernel
-> IPC msg to File-System server (switch + run FS server)
-> IPC msg to Disk-Driver server (switch + run driver server)
-> driver does I/O, replies with data (switch back)
-> FS server replies with data (switch back)
-> microkernel returns data to the app (switch back)
Boundary crossings: many (one pair per server hop)Stare at the two pictures and the whole argument is visible. The monolith's path is a straight line of cheap calls inside one room — fast, but if the ext4 code or the driver corrupts memory, the line runs straight through the scheduler and everything else. The microkernel's path zig-zags across protected walls, each hop a small toll of switching and copying — slower, but a bug in the driver server stops at the wall of its own address space and cannot reach the file-system server, let alone the core. Speed lives on the left; resilience lives on the right; and the tolls on the right are exactly the IPC cost we named.
How the debate actually played out
This was not a polite theoretical disagreement. In the early 1990s it became a famous public argument, and for years the practical verdict seemed to favor the monolith: early microkernels like Mach were slow, because IPC on the hardware of the day was genuinely expensive, and Mach ended up bundling so much back inside the kernel to recover speed that it blurred the very line it was supposed to draw. Meanwhile a plain monolith — Linux — quietly ate the world by being fast, pragmatic, and easy to extend with modules. To a casual observer it looked like the monolith simply won.
But the story did not end there, and the honest conclusion is more interesting than 'one side won'. The L4 family of microkernels showed that the slowness was largely an engineering failure, not a fundamental law: by ruthlessly optimizing IPC, L4 cut the cost of a message by more than an order of magnitude, making the microkernel idea genuinely practical. Its descendant seL4 went further and became the first general-purpose kernel with a machine-checked formal proof of correctness — a mathematical guarantee, given its assumptions, that the kernel has no bugs of certain whole classes. You cannot make a comparable proof about millions of lines of monolithic kernel; the microkernel's small trusted core is what makes such a proof possible at all. So the microkernel's robustness was real after all — it just took decades of work on the IPC bill to afford it.
What most real systems actually do is refuse to pick a pure side. The kernel underneath macOS and iOS, XNU, grew from a Mach microkernel but runs its services in the kernel for speed; Windows NT has a layered design with microkernel ancestry yet pulls graphics and more inside for performance. We call these hybrid kernels: they keep some microkernel structure and ideals while moving the hottest paths back in-kernel to dodge the IPC toll. The label 'hybrid' is a little slippery — purists argue most hybrids are really optimized monoliths — but it names a genuine middle of the road that the industry mostly walks.
What to carry away from the whole rung
Step all the way back. Every guide in this rung — the boot sequence, the system-call path, interrupts and kernel allocation, synchronization and modules — was really exploring one tension: a kernel must be powerful enough to drive the hardware and trustworthy enough not to wreck the machine, and those two pulls fight. Monolithic and microkernel are two principled ways of resolving that fight. The monolith trusts a big core and is rewarded with raw speed and simplicity; the microkernel trusts only a tiny core and is rewarded with isolation, restartability, and even provable correctness — paid for in IPC.
And notice how this debate quietly echoes the very last guide of the rung you climbed before this one. The container-versus-VM choice was the same shape: share more for lightness, or duplicate and isolate more for safety. The kernel question is that same balance drawn at the deepest level of the machine — how much do we share inside the trusted core, versus how much do we wall off. Once you can see that one balance running underneath every layer, from a single kernel up to whole fleets of machines, you are no longer memorizing operating systems. You are reading them.