Problem statement
Design the object model and public APIs for a plugin registry that lets a host application discover, register, and invoke third-party plugins that extend defined extension points — without the host knowing those plugins at compile time.
Operating context. One in-process host. A plugin declares an id, a version, the extension point(s) it implements, and optional dependencies on other plugins. The registry validates declared dependencies, orders activation topologically, activates and deactivates plugins, and lets the host fan a call out to every plugin contributing to a given extension point. Plugins can be enabled or disabled at runtime, and multiple threads may query the registry while activation state changes.
Out of scope. Sandboxing or security isolation of untrusted code, the dynamic class/module-loading mechanics of any runtime, the marketplace download/update flow, inter-process plugins, and versioned wire protocols between host and plugin.
What to produce. The class hierarchy (registry, plugin descriptor/metadata, extension point, activation lifecycle), the public APIs, and the activation-ordering algorithm. Be explicit about: how extension points stay type-safe as new kinds are added, how dependency order is computed and cyclic dependencies rejected, and how the lifecycle (registered → activated → deactivated) is enforced so an inactive plugin is never dispatched to.
Functional requirements
- Register a plugin with its id, version, the extension points it implements, and its declared dependencies.
- Look up all active plugins contributing to a given extension point.
- Activate plugins in dependency order and deactivate them in reverse, respecting declared prerequisites.
- Enable or disable an individual plugin at runtime and reflect that in extension-point lookups.
- Reject registration or activation when a declared dependency is missing or would form a cyclic order.
Non-functional requirements
- Extension-point lookup returns contributors in O(k) for k contributors via an index, not a full scan.
- The registry is safe for concurrent reads while a plugin is being activated or deactivated.
- Adding a new extension-point kind does not require changing the registry core or existing plugins.
- Activation order is deterministic for a given dependency graph and reproducible across runs.
- The lifecycle is testable with fake in-memory plugins — no real module loader or filesystem.
- A plugin can only be invoked while active; an inactive or failed plugin is never dispatched to.
Topics
- System Design LLD
- Oop Solid
- Patterns Registry
- Patterns Observer
- Graph Topological-Sort