Difficulty: Intermediate
Compare monolithic kernels and microkernels. Which is used by Linux, Windows and macOS, and why?
Kernel architecture questions are popular at companies like Microsoft, Intel and Qualcomm because they probe whether you can reason about design trade-offs rather than memorize definitions. The big picture is a question of how much code you want running with full hardware privilege.
A monolithic kernel puts almost all OS services in one big program running in kernel mode: the scheduler, memory manager, file systems, network stack and device drivers all share one address space. Functions inside the kernel call each other directly, like ordinary function calls. Linux, traditional Unix and BSD variants are the classic examples. The big advantage is performance: no message passing or address-space switching is needed between subsystems, so, for example, a file read can go from the VFS layer to the disk driver with a plain function call. The downside is fragility and a large trusted computing base. A bug in a single driver, say a buggy graphics driver, can corrupt kernel memory and crash the whole system, and a security hole in any driver gives an attacker full control.
A microkernel takes the opposite philosophy: keep in the kernel only the bare minimum that truly requires privilege, typically low-level address space management, basic scheduling and inter-process communication (IPC). Everything else, file systems, device drivers, network stacks, runs as ordinary user-space server processes. When an application wants to read a file, it sends an IPC message to the file server, which may in turn message the disk driver. Examples include Mach, MINIX 3, QNX, L4 and seL4. The benefits are strong isolation and reliability (a crashed driver can be restarted without rebooting), a smaller attack surface, easier formal verification (seL4 has a mathematical proof of correctness), and flexibility. The drawback is overhead: each service request involves several context switches and message copies, which historically made early microkernels noticeably slower.
In practice most modern systems land in between. Windows NT and macOS (XNU, which combines the Mach microkernel with a BSD layer) are called hybrid kernels: they have a microkernel-like structure but keep many services in kernel space for speed. Linux is monolithic but loadable kernel modules let you add drivers at runtime without rebuilding the kernel, which recovers some modularity. QNX, a microkernel, is widely used in automotive and embedded systems where reliability matters more than raw throughput, which is why Samsung and Qualcomm interviewers sometimes ask about it.
To summarize the trade-off crisply: monolithic gives speed and simplicity of implementation at the cost of robustness and a large privileged code base; microkernel gives robustness, security and modularity at the cost of IPC overhead. Modern L4-family microkernels reduced IPC cost dramatically by making messages extremely fast, which narrowed the performance gap.
If asked why Linux did not adopt a microkernel, you can recall the famous Torvalds versus Tanenbaum debate: Linux prioritized pragmatism and performance on 1990s hardware, and the monolithic design was simpler to get working.
monolithic kernel, microkernel, hybrid kernel, IPC, kernel design