API Management

B — the subscription is the unit of consumer identity, and everything surgical flows from it. Because each partner enrolled in the product with their own keys, one subscription suspends tonight and reactivates after their fix, while the other partners never learn anything happened. Now price the alternatives, because each is a real thing tired teams do. A fights an identity problem with a network tool: IP ranges shift, CDNs and NATs share them, and the block either misses the partner or catches innocents — and the backend should not be reachable except via the gateway anyway. C is the nuclear option that converts one consumer's bug into every consumer's outage — the exact outcome the gateway exists to prevent. D confuses the brochure with the door; documentation access stops nobody's curl. The design habit underneath: any time you cannot act on one consumer, you discover it during an incident — which is why per-consumer credentials are issued on day one, not retrofitted on day ninety.

C — sort changes by whether the promise changed, then use the instrument built for each. Adding an optional field breaks nobody who follows the most basic client discipline, so it rides a revision: tested at the private URL, switched live, invisible. Removing a field partners read changes the contract, so it becomes v2 while v1 keeps answering — and the retirement is a campaign run on the per-subscription traffic data, not a hope. A is the vaccine this drill administers: ship the removal as a revision and it goes live for every caller the moment it becomes current — v1's promise silently broken, three partners' integrations failing in the same hour, and the postmortem writing itself. B taxes everyone for nothing — version proliferation is real, and partners who must migrate for an additive change learn to dread your release notes. D is how integrations worked before gateways: synchronized cutovers fail asynchronously, one partner at a time, over a weekend. The sorting question to carry into every API review: could a well-behaved existing caller notice? No: revision. Yes: version.

Limit, authenticate, cache-and-strip — traffic work, every one. The test all three pass: they concern how requests flow, not what the application means, and they apply uniformly to every operation behind the gateway. The rejects fail it from opposite directions. Discount rules in policy expressions is business logic hidden in XML — outside the debugger, outside the test suite, outside the repo review path most teams wire for application code — and six months later a pricing bug hunt ends in a place no developer thought to look; policy is a poor home for anything a product owner might ask about. And returning raw exception detail inverts on-error's whole purpose: stack traces, connection-string shapes, and library versions are a reconnaissance packet, and "easing partner debugging" is what correlation IDs and the developer portal are for — give callers a reference number, keep the forensics in the Class 28 workspace. The boundary sentence: the gateway decides whether and how a request travels; the backend decides what it means.

Line one — and notice how reasonable it sounds, because that is how this mistake actually ships. "Faster" and "less overhead" are true statements about revisions; they are just answers to the wrong question. A revision has no opt-in: the moment it becomes current, every existing caller gets the new behaviour on their next request — which for a breaking change means every partner's integration fails simultaneously, at the switch, regardless of the two weeks of notice on line three. The notice does not help, because a changelog cannot keep v1 answering; only v1 can do that. Run the tape: switch flipped Tuesday 9am, three partners' syncs fail by 9:05, support lights up, and the rollback is frantic precisely because revisions were also the team's hotfix path. The fix is Drill 02's sorting: breaking means version — v2 beside v1, the portal carrying the migration guide, retirement driven by the traffic data line four correctly plans to watch.

The distractors are the plan working: policy through the pipeline is §3's discipline (B — "configuration" that changes production behaviour is code, the oldest lesson in Phase Three); pre-announcement is exactly right and pairs with versioning rather than replacing it (C); and post-release monitoring is how the v1-retirement campaign gets its evidence (D — it is not too late, it is the feedback loop). The reviewer's reflex to build: whenever a plan justifies a mechanism by its convenience, check what question the mechanism was actually built to answer.

Concede the pain before defending the keys. The PM is reacting to something real — if onboarding feels like paperwork, that is a legitimate bug — so agree to fix the friction before explaining why the fix cannot be key-sharing. Then run the one bad night, because it converts the abstraction into a story: partner B ships a buggy sync that hammers the API at 2am. With per-partner keys, the Class 39 machinery handles it in its sleep — B throttles at B's limit, A and C never notice, the usage chart names B, and Monday's email goes to one inbox. With a shared key, the gateway sees one anonymous consumer: the limit throttles all three partners at once, the chart cannot say who did it, and the Monday conversation is three denials and an argument. Same bug, same night — one design produces a line item, the other produces an incident with diplomacy attached.

Then price the parts the night didn't show. Revocation: keys leak (Class 31's whole curriculum), and a shared key that leaks must be rotated for everyone simultaneously — three coordinated partner deployments for one partner's mistake, which in practice means the leaked key stays valid for weeks. Commercial flexibility: the moment sales wants tiers — the regional chain at 100 calls a minute, the big marketplace paying for 1,000 — per-partner subscriptions make it a product setting; a shared key makes it impossible. And accountability is Class 32's lesson wearing partner clothes: an unattributable call is an unattributable cost, and "which partner is worth what" becomes unanswerable at contract-renewal time.

Close by solving the actual complaint. The paperwork is not the keys' fault — it is the process's. The developer portal exists precisely so onboarding is self-service: partner signs up, requests the product, approval is one click, keys are theirs in minutes — the case file's third partner took eleven minutes and zero meetings. Offer the PM that: "same-day onboarding, and we keep the ability to throttle, bill, and revoke one partner at a time." The sentence that ends the meeting: the keys aren't the paperwork — they're the reason one partner's bad night stays one partner's problem.

Start by naming the case where they win, because it exists and they can smell evasion. One API, one internal consumer, one team owning both sides: the middleware is genuinely enough, and APIM would be ceremony — a hop, a bill, and a second place to look during incidents, purchased for no one. Class 3 taught the shape: every tool has a "when not to," and a gateway's is single consumer, single owner, no external contract. Saying this first is not a concession tactic; it is the credibility that makes the rest of the argument land.

Then name the variable that flips it: consumers you don't control. The middleware argument quietly assumes every caller is family. The moment partners, other teams, or paying customers integrate, the chores multiply per consumer — per-partner limits, revocable credentials, usage attribution, a portal, versioning with deprecation campaigns — and middleware answers none of them without the backend team building a small, bespoke, forever-maintained gateway of their own inside the app. That is the honest comparison: not "APIM versus nothing," but "APIM versus the gateway you will write by accident, one feature request at a time, with no developer portal and no Class 32 line item to warn you what it costs." The hop and the bill are real; so is the engineering payroll spent reinventing subscriptions in Express middleware.

Close with the boundary drawn where it belongs. The token validation and rate limiting in their middleware are not wasted — defence in depth wants the backend suspicious even of the gateway (Class 31's layers). What moves to APIM is the multi-consumer work: the front desk, not the locks on the individual doors. And give them the honest tier answer for the bill: Consumption while the partner count is small, a fixed tier when traffic justifies it, reviewed at the Class 32 monthly like everything else. The sentence that usually settles it: your middleware protects this API; the gateway is for the day this API has customers — and sales already made that day this quarter.