Skip to content

Why Every Integration Sits Behind an Abstraction

· 1 min read · 0 views

API ArchitectureSystem DesignIntegration EngineeringAI Engineering

TimeSense connects to systems such as calendars, messaging platforms, task sources and LLM providers.

The easiest implementation would have been to call each external API directly from the core product logic.

I rejected that approach.

Every integration sits behind a provider interface. The recommendation engine asks for calendar events; it does not need to know whether they came from Google, Microsoft or Apple. The intelligence layer calls an LLM gateway; it does not depend directly on one model vendor.

This adds a small amount of design work at the beginning.

The benefit appears later:

• Providers can be added or replaced
• Testing can use controlled implementations
• Vendor-specific failures stay at the boundary
• Core business logic remains stable

The tradeoff is more interfaces and registry code.

The rejected alternative—tight provider coupling—would be faster for the first integration and increasingly expensive for every one after it.

Why every integration sits behind an abstraction: TimeSense core operations such as getting calendar events and tasks, sending messages, and generating recommendations go through a provider layer of interfaces and adapters to Google, Microsoft, Apple, Slack, Notion, and others. Rejected: direct provider calls inside core logic.

Originally posted on LinkedIn.