API Platforms For Scale

The episode contains a handful of genuinely useful ideas - accidental APIs, the impossibility of endless backwards compatibility, bulk vs. single-operation design mismatches - but they are buried in significant throat-clearing, host affirmations, and generic statements about 'business capabilities' that never fully land. Insight rate is moderate rather than dense.

“an accidental API is an API which was just built without knowing enough... The definition thus extends to. We never changed and improved that because of many reasons. And usually the reason is that too many people already depended on this old version”

“our use case is transferring 400,000 items and this API offers single operations. So it's just impossible to do a loop over 400,000 items”

There are a couple of fresh framings - the 'accidental API' coinage and the linguistic observation that the German word for interface means 'place of cutting' - but the bulk of the episode recycles well-worn practitioner wisdom (start with the business, know your consumers, backwards compatibility is hard) without genuinely contrarian or first-principles arguments.

“In German we have another word which actually means it's a place of cutting”

“If you look at online banking today, at least in Europe, in Germany we now pay with euros and we have these international bank account numbers, which is completely different than let's say the online banking in 1999 we had German marks”

Daniel is a legitimate practitioner - PhD in SOA, co-author of a recognised API patterns book, and real large-scale project experience integrating 700 systems across Switzerland. However he runs a small consultancy and the conversation stays at a level of workshop anecdotes rather than hard-won scale-company decisions.

“my second project actually was a very large scale platform in Switzerland where We integrated around 700 systems throughout Switzerland. So land registries, notaries, banks”

“I'm Daniel Lucca... a software architect who probably call me a solution architect, software developer”

A few concrete data points appear - 700 systems, 400,000 items, the German marks-to-euros analogy, a 10-to-1 client ratio, and a 2-hour debate on API visibility - but most examples are anonymised, no company names or revenue figures are cited, and large stretches of the conversation remain at the level of vague principle.

“we integrated around 700 systems throughout Switzerland. So land registries, notaries, banks”

“our use case is transferring 400,000 items and this API offers single operations”

The host's questions are consistently long, meandering, and often embed the answer, and there is no meaningful pushback or follow-up challenge anywhere in the 43-minute conversation. Repeated affirmations ('Yeah, yeah, absolutely') replace productive probing, and several promising threads - such as the data-ownership encapsulation conflict - are dropped before they are fully drawn out.

“Yeah, yeah, absolutely. Yeah. That's quite interesting knowing who your consumers are, you know, who your interacting parties are and just those governance, those principles”

“Yeah, absolutely. It's uh, understanding making sure they understand not just the technical but the business processes”