PATTERN Cited by 1 source
Plugin-based extensibility¶
Intent¶
Allow a platform to grow its capabilities through contributed plugins without modifying the core system — separating platform stability from capability expansion.
Problem¶
A platform that requires core changes for every new capability creates a bottleneck: the platform team becomes the gating factor for every new feature. Core instability increases with each change. Product teams wait in a queue.
Solution¶
Design the platform with a plugin interface — a well-defined contract that new capabilities must satisfy. Product teams (or the platform team itself) add plugins that: - Implement the interface contract - Run in isolation from other plugins and from the core - Are independently deployable and scalable - Can be contributed by teams outside the platform team
The core owns: routing, scheduling, caching, monitoring, lifecycle management. Plugins own: the actual transformation/processing logic.
Consequences¶
Benefits: - Core stays stable while capabilities expand. - Product teams can self-serve without waiting for the platform team. - Each plugin has a single failure domain. - Platform team focuses on infrastructure quality rather than domain logic.
Costs: - Plugin interface becomes a long-lived contract that is hard to evolve. - Plugin quality varies when contributed by many teams (requires governance). - Cross-plugin dependencies must be managed carefully. - Debugging spans plugin boundaries.
Known instances¶
- systems/dropbox-riviera — >100 plugins, each owning one transformation type; product teams contribute plugins while the Riviera team maintains core infrastructure (Source: sources/2026-07-20-dropbox-riviera-universal-content-processing-platform).