Skip to main content

ADR-001: Provider Abstraction Pattern

Status: Accepted Date: December 17, 2025 Deciders: CODITECT Architecture Team

Context​

CODITECT needs to integrate with multiple meeting providers (Google Meet, Zoom, Microsoft Teams, etc.) while maintaining a consistent internal API and avoiding vendor lock-in.

Decision​

We will implement an abstract provider interface pattern where:

  1. A base MeetingProviderInterface defines the contract all providers must implement
  2. Each provider (Google Meet, Zoom) implements this interface concretely
  3. A MeetingServiceOrchestrator manages provider selection and routing
  4. Customer applications interact only with the orchestrator, not providers directly

Consequences​

Positive​

  • Easy to add new providers without changing customer code
  • Consistent API across all providers
  • Unit testing with mock providers is straightforward
  • Provider-specific features accessible via **kwargs

Negative​

  • Some provider-specific features may not map cleanly to abstract interface
  • Additional abstraction layer adds complexity
  • Must maintain interface compatibility across provider updates

Neutral​

  • Requires documentation of provider-specific extensions
  • Each provider implementation has its own version lifecycle

Implementation​

class MeetingProviderInterface(ABC):
    @abstractmethod
    async def create_meeting(...) -> Meeting: pass

    @abstractmethod
    async def get_transcript(...) -> Transcript: pass

class ZoomProvider(MeetingProviderInterface):
    # Zoom-specific implementation

class GoogleMeetProvider(MeetingProviderInterface):
    # Google-specific implementation

class MeetingServiceOrchestrator:
    def __init__(self, providers: dict[str, MeetingProviderInterface]):
        self.providers = providers

    async def create_meeting(self, provider: str, **kwargs) -> Meeting:
        return await self.providers[provider].create_meeting(**kwargs)

References​