Chapter 13 Flashcards — Microkernel Architecture Style
flashcards fsa microkernel-architecture
What is the microkernel architecture style (plug-in architecture)?
?
An architecture style consisting of a minimal core system that provides only stable, fundamental capabilities, surrounded by independent plug-in components that extend the system with domain-specific behavior — all plug-ins communicate only with the core, never with each other.
What is the primary responsibility of the core system in microkernel architecture?
?
The core system provides the minimal viable functionality: routing/dispatching requests to plug-ins, shared infrastructure services, and the plug-in registry. It defines the contract plug-ins must implement. The core must be stable — it should rarely, ideally never, change after initial release.
What is a plug-in component in microkernel architecture?
?
A plug-in is a standalone, independently deployable unit of domain-specific functionality. Plug-ins implement the core’s contract, communicate only with the core (never directly with other plug-ins), and can be added, updated, or removed without modifying the core or other plug-ins.
What is the single most critical rule about plug-in communication?
?
Plug-ins must communicate only with the core — never directly with other plug-ins. Direct plug-in-to-plug-in communication (via method calls, shared tables, or message queues) creates hidden coupling that defeats the independence guarantee of the microkernel style.
What is the registry in microkernel architecture and what does it do?
?
The registry is the mechanism by which the core discovers, loads, and manages plug-in components. Common implementations include classpath scanning (Spring), service locator (Java SPI/ServiceLoader), configuration files (OSGi bundle.xml), or a database. The registry determines whether plug-ins are loaded statically (at startup) or dynamically (at runtime without restart).
What are four common forms a plug-in contract can take?
?
A contract defines the interface plug-ins must implement. It can take the form of: (1) a Java/C# interface or abstract class, (2) a REST endpoint schema (URL, method, request/response body), (3) an XML or JSON message schema, or (4) a gRPC/Protobuf service definition. Contract stability is critical — changes break all existing plug-ins.
Why is contract stability called the most critical property in microkernel architecture?
?
Because the contract is the shared interface all plug-ins depend on. When the contract changes in a breaking way, every existing plug-in breaks simultaneously. This makes the core contract equivalent to a public API — it requires versioning, deprecation cycles, and careful governance. Unstable contracts destroy the plug-in independence guarantee.
What is the Volatile Core risk in microkernel architecture?
?
Volatile Core occurs when the core system changes frequently, forcing all plug-in teams to constantly update their plug-ins to keep up. This is the most dangerous microkernel antipattern — it collapses the independence of plug-ins and turns the architecture into a high-coordination, tightly coupled system. Mitigation: treat the core as a published API with strict governance and backward compatibility requirements.
What is the Plug-In Dependencies risk and how does it manifest?
?
Plug-In Dependencies is the risk that plug-ins accidentally create hidden dependencies on each other — via direct method calls, importing each other’s classes, reading each other’s database tables, or sharing message queues. This violates the core isolation rule and creates coupling that is hard to detect at code review. Mitigation: architecture fitness functions (e.g., ArchUnit rules) that verify no plug-in imports from another plug-in’s package.
What does the spectrum of “microkern-ality” mean?
?
The spectrum of microkern-ality describes how “pure” a microkernel implementation is. At one end: a thin core with many small plug-ins (pure — maximum extensibility, heavy governance). At the other: a thick core with few large plug-ins (impure — less extensibility, simpler to operate). Most real systems sit in the middle; the right position depends on how frequently plug-ins are added and how many teams contribute to the system.
Compare static plug-in loading vs. dynamic plug-in loading.
?
Static loading: plug-ins are compiled into the deployment artifact (JAR, container image); adding/updating a plug-in requires rebuilding and redeploying; simpler to operate and debug. Dynamic loading: plug-ins are discovered and loaded at runtime via the registry (e.g., OSGi, Java SPI); enables hot-plug, plug-in marketplaces, and runtime extensibility without restart; more complex to implement and debug.
What are the typical data topology options in microkernel architecture?
?
Four patterns: (1) Shared core database — single DB, all plug-ins access via core services (simple, tight coupling); (2) Plug-in-owned tables — plug-ins have dedicated tables in the shared DB; (3) Plug-in-owned schemas — schema-level isolation within one DB instance; (4) Plug-in-owned databases — each plug-in has its own DB instance (maximum isolation, rarely used). Cross-plug-in data access always routes through the core.
Why does microkernel architecture have a ★★★★☆ testability rating?
?
Because the clean contract boundary between core and plug-ins enables testing plug-ins in complete isolation. A plug-in can be tested using a stub or mock core that implements the contract — no need to spin up the full application. The contract acts as a natural seam for unit and integration tests. This is one of the style’s strongest characteristics.
Why does microkernel architecture have a ★★★☆☆ scalability rating?
?
The core system is typically a single deployment unit — to scale the application, you must scale the entire core, not just the parts handling the most load. Plug-ins scale only as part of the core; they cannot be independently scaled to handle higher throughput. This centralized scaling model limits horizontal scalability compared to microservices.
What is the team topology in microkernel architecture?
?
Two primary teams: (1) Core Team — senior engineers/architects who own the core system, the plug-in contract, and the registry; moves slowly with high governance; publishes versioned contracts. (2) Feature Teams — each team owns one or more plug-ins; can move quickly within the contract bounds; do not need to coordinate with other feature teams. This enables parallel plug-in development — a key agility advantage.
When should you choose microkernel architecture?
?
Choose microkernel when: (1) building a product requiring customer/third-party customization (IDEs, browser extensions, insurance platforms, SaaS platforms with marketplace); (2) the system needs runtime extensibility (add capabilities without redeploying the core); (3) there is a stable, well-understood core with highly variable periphery; (4) business rules or domain logic change independently (tax engines, compliance rule sets, pricing engines).
When should you avoid microkernel architecture?
?
Avoid microkernel when: (1) the application is simple and uniform — the plug-in abstraction adds unnecessary complexity; (2) high scalability is required — the centralized core becomes a bottleneck; (3) the core cannot be stabilized — if requirements change the core weekly, the pattern’s fundamental constraint cannot be met; (4) already operating in a microservices environment where service independence already provides extensibility.
How does Eclipse IDE exemplify microkernel architecture?
?
Eclipse’s core platform (Equinox/OSGi) is the kernel — it handles the workbench UI, resource model, and plug-in lifecycle. Every feature (Java tools, Git integration, XML editors, debuggers) is an independently deployable plug-in implementing the Eclipse plug-in contract. Third parties publish thousands of plug-ins to the Eclipse Marketplace without modifying the core. Eclipse is the canonical enterprise example of the style.
How does the Chrome Extensions API follow the microkernel pattern?
?
Chrome’s browser engine is the core; extensions are plug-ins loaded via the Chrome Extensions API (the contract). Extensions implement this contract to intercept network requests, modify DOM, add UI elements, etc. Google manages the Extensions API with careful versioning and deprecation. Extension developers work independently without touching the Chrome core — a textbook microkernel deployment.
What is the governance approach for enforcing plug-in isolation in microkernel?
?
Use architecture fitness functions — automated checks in CI that verify plug-ins only import from core packages (not from other plug-in packages). In Java, ArchUnit rules enforce this. At the database level, strict schema ownership prevents plug-in A from directly querying plug-in B’s tables. For REST-based plug-ins, network policies prevent direct inter-plug-in HTTP calls.
What cloud deployment patterns are common for microkernel architecture?
?
Common cloud patterns: (1) Plug-ins as versioned artifacts stored in artifact registries (Maven Central, npm, NuGet, S3), fetched at deployment time; (2) Serverless plug-ins — each plug-in is a Lambda/Azure Function invoked by the core via the contract; (3) Plugin marketplace — SaaS customers upload their own plug-ins to a multi-tenant registry (Salesforce Apex, Shopify Apps); (4) Container-baked plug-ins — plug-ins included in the container image at build time (static, simple, no hot-plug).
How does the core team vs. feature team split affect development velocity?
?
The split creates an asymmetric velocity model: the core team moves slowly (high governance, backward compatibility requirements, architecture reviews for every change) while feature teams move fast (only need to implement the contract, no cross-team coordination). The net effect is high parallel development throughput across feature teams — all can ship simultaneously — offset by the constraint that features requiring core changes are expensive and slow.
What is Fat Core Creep and why is it dangerous?
?
Fat Core Creep is the gradual accumulation of business logic in the core system, blurring the boundary between “core functionality” (stable, shared) and “plug-in functionality” (variable, extensible). It’s dangerous because it makes the core volatile (triggering the Volatile Core risk), reduces the plug-in independence guarantee, and eventually transforms the architecture into a monolith with a façade. Mitigation: strict definition of what belongs in the core, with architecture review gates on all core changes.
What ratings does microkernel receive for overall agility and ease of deployment, and why?
?
Both receive ★★★☆☆ (moderate). Overall agility: plug-ins can be added/changed independently (high agility for plug-in work), but core changes are slow and risky (drag on overall agility). Ease of deployment: individual plug-ins deploy independently and easily; but core deployments are infrequent, high-risk, and require coordinating all plug-in teams to verify compatibility — lowering the overall deployment rating.
Priority: MEDIUM — Microkernel is a moderately common style, most relevant for product/SaaS platform roles. Master Eclipse/Chrome examples for interviews.