200 Integrations with 5 Developers
summary
Describes building a single unified interface to manage hundreds of external integrations (payments, fuel stations, hotel sales) using a small engineering team (five developers). Focuses on the architecture and processes that let a tiny team maintain ~200 integrations—standardizing adapters, automation and tooling to onboard and operate many third-party providers under one API.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:54What integrations are for
- 3:09200 suppliers integration challenges
- 4:12Integration approaches and roles
- 5:40Developing integrations process
- 8:59Microservices vs monolith architecture
- 11:05Modular monolith benefits
- 12:32Framework vs library vs module
- 13:57Go integrations implementation
- 15:23Integration service evolution
- 17:30Library layer separation
- 18:52Standardized logging and errors
- 20:18Observer error and metrics package
- 22:07Generics and Cartesian product
- 25:19Responsibility split and templating
- 26:21Q&A: Integration degradation
- 27:49Q&A: Caching and peak season
- 29:59Q&A: Go migration economics
- 31:52Q&A: Logging and data storage
- 33:15Q&A: Module isolation and load
- 35:19Q&A: Data consistency
- 37:08Q&A: Protocol unification
- 38:33Q&A: Integration timelines
- 41:02Summary
related talks
20mBest practices for API Integration
24mThe Future of API Integration
51mWho's Afraid of the Big Bad Third Party Integration?
37mBuilding Developer-Centric APIs in a Multi-Product SaaS Org
25m5 ways to make your integration more resilient
54mThe Evolution of API Drive Integration
16mRevolutionizing API Integration: Fiserv's Developer Studio Journey
29mEnhancing Governance, Cost Efficiency, and Developer Productivity.