Which quality-attribute drivers point specifically to microkernel (plugin) or space-based architecture, and how do you responsibly combine several architectural styles into one hybrid system?
answer
- Microkernel: stable core + volatile plugins
- Contract + versioning + isolation = the real cost
- Space-based: DB off the hot path, memory grid
- Try replicas/cache/CQRS before space-based
- Hybrid: one style per boundary, ADR + fitness functions
basics
~20 sMicrokernel fits when behavior varies a lot per customer, region, or product and must be extended without touching the core — a small core plus plugins. Space-based fits when huge, unpredictable user spikes make a central database the bottleneck: keep data in replicated memory instead. Combine styles by scope, not by blending them everywhere.
solid answer
~50 s**Microkernel (plugin architecture)** is selected by *domain variability plus extensibility*: a minimal core system holds the invariant workflow, and plugin components supply the varying rules (tax jurisdictions, insurance products, per-tenant customizations, IDE/browser extensions). Its costs are contract design, plugin versioning, discovery/registry, and isolating faulty or hostile plugins. **Space-based architecture** is selected by *extreme, spiky elastic concurrency* where the database has been proven to be the bottleneck. Processing units hold replicated in-memory data, synchronized by a messaging grid, with asynchronous writes to durable storage; you scale by adding identical units. Costs are data-grid operations, cache/replication semantics, a data-loss window, and much harder debugging. Hybrids are the norm, and the discipline is scope: apply each style at the smallest boundary that solves a ranked driver, keep exactly one style governing each boundary, make the seams explicit contracts, and enforce the constraints with automated fitness functions. Document each choice in an ADR with the driver that justified it, so future teams can tell an intentional hybrid from accumulated drift.
go deeper
Recognize the two shapes: microkernel is a small core plus plugins for varying behavior; space-based keeps data in memory across many identical instances to survive traffic spikes.
Give a concrete use case for each (per-jurisdiction tax rules; a ticket on-sale spike) and name the main cost — plugin contract management, and in-memory data grid complexity plus a data-loss window.
Discuss the selecting drivers precisely, plugin versioning and isolation, the components of a space-based system, and the cheaper alternatives you would exhaust first; explain applying styles at the smallest effective scope.
Own the hybrid governance question: one style per boundary, explicit seams and anti-corruption layers, ADRs tying each style to a ranked driver, automated fitness functions to prevent decay, a bounded number of styles for cognitive load, and predefined reversal triggers.
### Microkernel (plugin) architecture **Structure.** A **core system** implements the minimal, general workflow — the parts that never vary. **Plug-in components** implement specialized, volatile behavior. A **plugin contract** (an interface plus data format and lifecycle) and a **registry** (how the core discovers what is installed) connect them. Plugins depend on the core contract; the core does not depend on any specific plugin. **Selecting drivers.** - *Domain variability* — rules differ per jurisdiction, product line, tenant, or device, and the variation set keeps growing. Encoding all of it inside the core produces an unmaintainable thicket of conditionals. - *Extensibility by third parties* — an ecosystem where others ship behavior you did not write (editors, browsers, CI systems, e-commerce platforms). - *Independent evolvability of the volatile part* — a new tax jurisdiction should be an added plugin, not a core release. - *Deployment-time or runtime configurability* — different customers run different capability sets from one codebase. **Costs and edge cases.** - The contract is the hard part; it must be general enough for plugins you have not imagined and stable enough that you do not break the ecosystem. Getting it wrong forces either core changes per plugin (defeating the point) or an over-general contract nobody can implement well. - Versioning: plugins built against v1 must keep working; you need deprecation policy and compatibility testing. - Isolation: an in-process plugin can crash, hang, leak, or exfiltrate. Options range from convention through class-loader/module isolation to separate processes or sandboxes — increasing safety, increasing cost. - Discovery and ordering: when several plugins claim the same extension point, precedence must be defined. - Microkernel is an *internal structure* style; it says nothing about deployment, so it composes freely with monolith or service topologies (a service can be internally a microkernel). ### Space-based architecture **The problem it targets.** In most systems, scaling out application instances eventually hits the shared database: connections, locks, contention, and I/O impose a ceiling that more app servers do not raise. Under a sudden spike (ticket on-sale, flash sale, viral event) the database saturates and latency collapses. **Structure.** Named after tuple spaces. Components: - **Processing unit** — an application instance that also holds the working data set *in memory*. - **Messaging grid** — routes requests to available units. - **Data replication engine** — propagates in-memory changes between units so any unit can serve any request. - **Data pump / data writer / data reader** — asynchronously persist changes to the durable store and hydrate a starting unit. - **Deployment manager** — starts/stops units in response to load. The database is removed from the synchronous request path, so throughput scales roughly with the number of units. **Selecting drivers.** Extreme and *unpredictable* concurrent user spikes; variable, burst-shaped load; the durable store demonstrably being the bottleneck; and a business tolerance for a small window of unpersisted data. **Costs.** Deep expertise in caching and replication; replication lag and conflict semantics; a data-loss window if units die before the pump persists; painful debugging of distributed in-memory state; hard local development and testing; expensive infrastructure. This is a specialist style — reach for it only after simpler measures (read replicas, caching, sharding, CQRS read models, queue-based buffering) have been measured and found insufficient. ### Combining styles into a hybrid Real systems are almost always hybrids. What separates a designed hybrid from a mess: 1. **Assign one governing style per boundary.** Within a module or service, exactly one style rules its internal structure. Overlapping styles in the same code produce arguments, not architecture. 2. **Apply expensive styles at the smallest effective scope.** CQRS in the one context with a brutal read/write asymmetry; event-driven only on the edges where elasticity or fan-out is needed; microkernel only around the genuinely volatile rule set. 3. **Make the seams explicit.** Where two styles meet — a synchronous API in front of an event-driven interior, an anti-corruption layer between a legacy layered system and a new context — the boundary needs a named contract, an owner, and a translation strategy. 4. **Keep the mental model small.** Every additional style is a new set of failure modes, tooling, and onboarding material. Three styles in one system is usually the practical ceiling. 5. **Record and enforce.** ADRs capture *which driver bought which style at which scope*. Fitness functions in CI enforce the constraints — dependency direction, no cross-service database access, module boundaries, latency budgets, event-schema compatibility. Without enforcement, hybrids decay into an accidental architecture within a couple of years. 6. **Define reversal triggers.** State up front what would make you drop or extend a style ("if projection lag exceeds X and cannot be fixed, we collapse the read model back"), so re-evaluation is planned rather than political. **A typical mature hybrid:** microservices at the deployment level for team autonomy; hexagonal inside each service; a modular monolith retained for the low-change back office; an event-driven backbone for cross-context facts; CQRS in the reporting and catalog contexts; and a microkernel plugin core inside the pricing service where per-market rules churn. Each choice traceable to one ranked driver. ### How to answer Don't just recite the two styles — name the driver that selects each, the cost that disqualifies it elsewhere, the simpler alternatives you'd exhaust first (especially before space-based), and then articulate hybrid discipline: scope, seams, enforcement, and documented reversal triggers.
- What would you try before adopting space-based architecture for a traffic-spike problem?In order: measure to confirm the database really is the bottleneck; add read replicas and caching; introduce CQRS read models for the hot queries; buffer writes through a queue for elasticity; shard or partition; use autoscaling with connection pooling limits. Space-based is justified only when these are measured and still insufficient, because its operational cost is permanent.
- How do you keep a plugin contract stable while the core evolves?Version the contract explicitly and support at least one prior version; make changes additive (new optional extension points rather than altered signatures); publish deprecation windows; run a compatibility test suite against reference plugins in CI; and expose capability negotiation so a plugin can declare what it supports rather than the core assuming.
- How can you tell an intentional hybrid architecture from accidental drift?Traceability and enforcement. In an intentional hybrid, each style maps to a documented ranked driver at a named scope (ADRs), boundaries have owners and contracts, and constraints are checked automatically in CI. Drift shows up as styles that nobody can justify, boundaries that are violated without anyone noticing, and no record of why anything was chosen.
Microkernel is a power-tool base with interchangeable heads: the motor never changes, the attachments do all the varying work. Space-based is a pop-up market with many identical stalls each carrying its own stock, instead of one warehouse counter everyone queues at — throughput scales with stalls, but stock has to be kept in sync and a stall that burns down loses what it hadn't yet booked in.