Extensible APIs & Plugin Architecture

Designing for the second use case

Extensibility means the first feature ships simple; the second feature adds a class, not an edit cascade. Open/Closed at the API layer: stable facade, pluggable implementations.

Technique	When to use	Example
Strategy injection	One behavior varies	Checkout(PricingStrategy)
Registry / plugin map	Open-ended providers	Map<String, NotificationChannel>
Factory + interface	Construction varies	PaymentMethodFactory.create(type)
DI container	Many dependencies	Spring @Autowired list of handlers

Plugin registry pattern

NotificationService holds List<NotificationChannel> or Map<ChannelType, Channel>. register(Channel) called at startup. Adding Slack = new SlackChannel implements NotificationChannel + registration — zero edits to NotificationService.send().

Dependency direction

Inner domain never imports outer adapters (Clean Architecture dependency rule). PaymentProcessor depends on PaymentGateway interface; StripeGateway implements it in the infrastructure layer. Tests inject FakeGateway.

Senior-level signal

Balance OCP with YAGNI: "With one channel, I'd inject a single EmailChannel. At three channels, I'd introduce a registry." Name the extension point (interface + registration) and the stable surface (facade methods callers use). Avoid speculative config frameworks on the whiteboard.

Versioning awareness

When plugins evolve, interface changes break implementors — prefer adding new methods via default interface methods (Java 8+) or a v2 interface. Mention if interviewer asks about backward compatibility.

Where this goes next

Errors, Invariants & Validation covers how extensible APIs stay safe — fail-fast, invariant enforcement, and where validation lives in the object graph.