Microkernel / plug-in architecture
The microkernel style separates minimal core capabilities from replaceable extensions through a stable contract.
- CoreStable minimum capabilities and contracts.
- Plug-inOptional capability behind a contract.
- IsolationCheck failure and permission effects.
Context
Why this is important
Design a stable application core with explicit extension points and assess plug-in costs.
An extension model for systems whose capabilities must be added or replaced through plug-ins.
Core and plug-ins for shipping rules
The shop variant is explicitly hypothetical: a plug-in point for shipping rules extends the existing seven-module application.
This is how you read the picture
- Core Platform core
- Plug-in Extension
- Isolation Runtime boundary
| Criterion | Responsibility | Decision |
|---|---|---|
| Core contract | Provide a stable version. | Check compatibility. |
| Runtime | Load extensions. | Limit failure impact. |
Benefits & limitations
Helps if:
- Several optional extensions follow the same stable contract.
- Capabilities need to be activated or replaced independently.
Boundaries
- Versioning and compatibility costs may exceed the benefit.
- Faulty extensions may share process and permissions with the core.
In practice
- Derive the smallest stable core capabilities from concrete extension cases. Define each plug-in contract, allowed dependencies and lifecycle instead of assuming abstract extensibility.
- Define how plug-ins are discovered, enabled, versioned and rejected when contracts are incompatible. Account for the shared runtime, permissions and possible resource limits.
- Assess failures, permissions and outage impact for each extension. Use stronger process isolation if a plug-in can endanger the core, and compare operational cost with a simpler modular design.
Read the detailed explanation
Contracts, versioning rules, registration and failure modes are part of the design. Plug-ins may run in the same process, so the style does not promise automatic failure or security isolation.
Microkernel describes an extension model that can run within a monolith. It does not require separate microservices.
A microkernel can run within a Modular Monolith; separate Microservices address a different operational question.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What stays in the example’s core?
View the solution with justification
Minimum platform capabilities and the plug-in contract.
ApplyingTransferred to a new situation
How do you handle a plug-in with an incompatible contract version?
View the solution with justification
Check the version and reject or migrate the extension in a controlled way.
EvaluateWeighing an alternative
What must be established before adopting plug-ins?
View the solution with justification
Several real extension cases and manageable compatibility, failure and security costs.
Explore further
These building blocks continue the thoughts of this page.
References
- Microsoft · Microkernel architecture style (opens in new tab)Documents core, plug-in contracts and conditions.
- Carnegie Mellon SEI · Architecture Styles (opens in new tab)Places architecture styles and quality attributes in context.
- Buschmann et al. · Pattern-Oriented Software Architecture (opens in new tab)Reference work on the microkernel style.