Explain the case for supporting multiple models behind an abstraction layer.

Skylark Events runs a live-events ticketing marketplace. Four features depend on a model today: support chat, fraud-flagging on new listings, listing-photo moderation, and search-ranking rerank. Zanele Umeh is the platform architect who has to make the case for whether these should sit behind one shared layer or stay wired straight to whichever vendor shipped first.

How to answer this, stage by stage

Nobody is scoring whether you know the phrase "vendor lock-in." They're scoring whether you can put a real number on the thing you're protecting against.

Let's learn

The whiteboard is where Zanele sketches every model call Skylark Events makes in a week.

Before any of this mattered, one feature, support chat, called one model directly. It worked, it shipped fast, and nobody thought twice about wiring it straight to that vendor's exact API.

Three more features followed the same pattern over two years: fraud-flagging on new listings, photo moderation, and search-ranking rerank. Each one, on its own, was a small, sensible choice.

Four features, one shared router. Before the layer existed, each of these was its own separate wire to the same vendor.

Here's the turn: the real problem was never any single feature's integration. It's that nobody had a shared record of how many features had quietly made the same bet on the same vendor, until a deprecation notice forced everyone to add it up at once.

At its worst, that bet costs 40 call sites' worth of emergency rewrites, all competing for the same handful of engineers, during the exact week a vendor's deadline is ticking down.

What I would leave alone: a single feature tied to one model, with no second AI feature on the roadmap, doesn't need this layer at all. The build cost isn't worth paying for a bet nobody plans to make twice.

The lesson: the cost of an architecture decision isn't the cost of the first feature it supports. It's the cost multiplied by every feature that quietly copies the same shortcut afterward.

Now here is the same thing as a story

The short version above is what you'd say in an architecture review. Read this one for what it felt like the year the bet everyone had made separately finally came due at once.

Her name is Zanele. She's been the one architect at Skylark Events who understands every model wired into the ticketing app, for three years.

It wasn't one dramatic outage that changed her mind. It built up slowly, four features over three years, each added by a different engineer, each one a reasonable choice made in isolation, with nobody stepping back to look at the shape of all four together.

Four hardwired plugs looked like four separate decisions. They were really one decision, made four times without anyone noticing the pattern.

Then, in year three, the vendor announced it was sunsetting the exact model version all four features depended on, with a 90-day migration window.

Three years of small, separate decisions became one large bill, due all at once.

Forty call sites, across four features, all needing to be found, tested, and rewritten inside the same 90-day window, by the same small team that also had a roadmap to ship.

The rewrite took six weeks of calendar time, not because the code was hard, but because 40 call sites meant 40 small merge conflicts with whatever else the team was shipping. Two other roadmap items paused entirely.

Five steps, and the second one, every call still hardcoded, is the one this whole estimate turns on.

When each feature was first built, nobody in that planning meeting raised the shared-layer question. "Let's just call the API directly, it's one feature, we'll deal with it later," someone said each time, and each time it was a reasonable thing to say, because in isolation, it was true.

The real question was never whether any single integration was well built. It was whether Skylark had a way to see, before the third or fourth feature shipped, that the same bet was being placed again.

Three things, and a rewrite that skips any one of them isn't really an abstraction layer, it's a wrapper around one vendor.

With the layer built after the deprecation forced the issue, the next vendor change, whenever it comes, becomes a single config update and one round of evals, about 1,300 dollars and an afternoon, instead of six weeks and 50,000 dollars spread across four features.

What I'd tell myself, watching the six-week scramble unfold: four small, sensible decisions had quietly become one large bet, and nobody had ever been asked to approve the bet itself.

BOUND, mapped onto one architecture caseNot a script for building a shared layer around every single API call. BOUND is what tells you when the arithmetic actually favors it.

The case for the layer isn't universal. It's a threshold, and Skylark had already crossed it twice over before anyone noticed.

The recap, one line per letter: break it down is hardwired cost as call sites times features times cost per site times events per year, own the numbers is naming where each figure came from, use a range is 8 to 33 months of payback depending on event frequency, nail the sanity check is comparing 50,000 dollars to three months of an engineer's cost, and direction is event frequency being the one assumption worth double-checking before committing budget.

And if you want to be sure it really works, try it somewhere elseSame five letters, a crop-advisory app instead of a ticketing marketplace. The features change, but the seam sits in the same place.

Farida Ojo builds AgriLoop, a farm-advisory app combining a vision model that identifies crop disease from a photo and a text model that answers a farmer's follow-up question. Mapped onto BOUND: break it down, hardwired cost equals call sites per feature times features times rewrite cost times events per year, same equation, two features instead of four. Own the numbers: 6 call sites per feature, 12 total, at a smaller 60 dollars an hour blended rate since AgriLoop is an earlier-stage team, and roughly 1 vendor-change event a year given it depends on both a vision and a text provider. Use a range: payback runs from 14 to 26 months depending on event frequency, since fewer features means a smaller yearly avoided cost. Nail the sanity check: a single event's cost, about 9,000 dollars, is under two weeks of one engineer's time, a modest but real number for a team this size. Direction: at AgriLoop's smaller scale, the number that swings it most isn't event frequency, it's whether a third feature gets added within the next year, since that's what would make the case clearly worth it now instead of marginal.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "it turns a repeated 50,000-dollar scramble into a 1,300-dollar config change, and it pays for itself in under a year," and stop.
Cost: no engineering budget for a full layer right now. Say so honestly, and commit to at least logging which features call which vendor, the cheapest version of the same insight.
The model got better, for real: if a vendor's new version is a straightforward upgrade with no breaking changes, that's still the moment to route it through the layer's config, not to quietly re-hardwire a call site out of habit.

Where people run it wrong.
They build the layer for its own sake, as an architecture preference, with no real cost estimate behind the case at all.
They wait until the third or fourth feature is already hardwired before ever running this arithmetic.
They present a single confident payback number instead of a range, which falls apart the moment someone asks "what if a vendor doesn't change anything for two years."

How to use it live. The moment an interviewer asks for the case for an abstraction layer, ask yourself: what did the last vendor-change event actually cost, in dollars and weeks, and how many more features are about to make that bet again? Do that arithmetic out loud, and the case makes itself.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0