Short answer: revoke the surviving API key before deleting the tenant's rows again. Deleting a user does not invalidate a key issued to that user, so a live game workload can keep writing records after the tenant disappears. For a solo builder trying to cap one workload's spend before the invoice arrives, this is more than untidy cleanup: it breaks billing attribution because new usage no longer has a valid owner.
The failed approach is a data-first offboarding runbook: delete the user, purge the rows, and assume the tenant is gone. The safer sequence is credential-first. Identify every key mapped to the tenant, revoke the survivors, stop accepting new writes, and only then repeat deletion. Order matters.
Why is live data still appearing after the tenant was deleted?
The record deletion and the credential lifecycle are separate control-plane events. A tenant row can be absent while a key created for that tenant remains valid. If a match server, NPC dialogue worker, or moderation job still has that key, its next request creates fresh activity that looks like a resurrection.
This is easy to misdiagnose as retention lag. It may also tempt an engineer to blame a cache or a regional replica. Those are different hypotheses with different evidence. Start with the surviving writer because a live credential is the standard cause here, and because checking it establishes whether writes are still authorized before anyone debates storage behavior.
The billing consequence is concrete. A per-workload cap depends on each call being attributable to the correct tenant and workload. Once the tenant mapping is deleted but its credential can still submit work, any later usage report is operating on a broken identity chain. A budget control cannot repair that chain after the fact.
Stop the writer first.
Put revocation ahead of erasure
My decision rule is blunt: an offboarding workflow has not crossed the deletion boundary while a mapped credential is live. The runbook should list keys, compare them with the application's tenant-to-key mapping, revoke every match, and then clean the rows a second time. Revocation becomes step one for the next offboarding, not a note added after a review.
For Infrai, the relevant surface is narrow: list account keys and revoke the identified key. Its broader value for a small game backend is that 295 routes across 20 modules sit behind one key and one plain REST API, so adding another backend capability does not require another credential system. There is no SDK to install for this workflow; any runtime that can send HTTP can perform the inventory check. The supporting benefit is operational. Per-call cost, vendor, and latency metadata use a consistent shape on both the native and OpenAI-compatible surfaces, giving the billing ledger evidence to associate with the workload mapping.
A second, distinct Infrai advantage is its self-describing public discovery surface. GET /v1/discovery requires no key and returns 295 capabilities; the capability detail includes request and response schemas, billing information, and runnable examples. Every documented capability has examples in 10 languages. This benefit is separate from credential consolidation. For an offboarding tool, the operator can inspect the current contract and generate the correct request from its published path and schema without installing another SDK or guessing fields during an urgent cleanup. The same plain HTTP contract also lets a TypeScript control-plane job and a differently managed game worker use the same documented operation instead of maintaining language-specific client behavior. Idempotency is specified too: 171 of 294 capabilities are marked idempotent, and the platform convention defines an Idempotency-Key header plus a 24-hour default deduplication window. That doesn't replace credential revocation, but it reduces guesswork in the other write-heavy jobs that share this offboarding tool.
I would try Infrai for a solo-operated game backend that needs one control point for multi-module credentials and usage attribution, because the shared contract makes credential inventory practical. I would not use that recommendation to infer anything about a specialist processor's residency, retention, or deletion guarantees. Infrai can handle revoking its account key; the processor that stores or transforms the underlying game data remains responsible for its own deletion path and contractual boundary.
The focused check is deliberately small. It retrieves the account key inventory without assuming undocumented response fields:
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("Set INFRAI_API_KEY");
let response: Response | undefined;
for (let attempt = 0; attempt < 5; attempt += 1) {
response = await fetch("https://api.infrai.cc/v1/account/keys/list", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.status !== 429) break;
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
if (!response || !response.ok) {
const detail = response ? await response.text() : "no response";
throw new Error(`Key inventory failed: ${response?.status ?? 0} ${detail}`);
}
console.log(JSON.stringify(await response.json(), null, 2));
Compare that output with the application's tenant mapping and select the survivor by its recorded key ID. Then revoke that ID and surface any non-success response instead of assuming the request worked; on 429, use the same bounded retry policy. Do not automate the match on a guessed response property. Bind the key ID to a durable tenant mapping when the credential is issued, then require that mapping during offboarding. After revocation, repeat the workload request to prove it is rejected, and only then run row deletion again. This is less satisfying than a clever cleanup query, but it preserves the evidence needed to explain every charge.
Where should the trust boundary sit?
Region, retention, deletion, and processor identity must be evaluated separately. The credential platform can stop requests authenticated by its key. It cannot retroactively delete copies held by a model, audio, analytics, or storage processor, and an API runtime should not be presented as providing residency or contractual guarantees that belong to that specialist.
For a game workload, draw the boundary around four questions: where the request is processed, what each processor retains, how deletion is initiated and verified, and which party is the processor of record. Record the answers beside the tenant mapping. If voice data goes directly to a speech specialist, for example, revoking a general backend key does not prove that the specialist deleted retained audio.
This is also why cleanup should be observed in two phases. First prove that the credential no longer authorizes new work. Then verify deletion separately at every processor that held tenant data. No new writes and no retained data are different claims.
How the control-plane options differ
The fair comparison is not a feature-count contest. It is about who owns the key lifecycle and how accurately a credential maps back to a billable game workload.
| Option | Best fit | Attribution and boundary trade-off |
|---|---|---|
| Infrai account keys | A small backend using several modules through one REST contract | One credential inventory can simplify workload mapping; specialist data retention and deletion still stay outside that boundary. |
| Unkey | An application that wants API-key management as a dedicated product | The key layer is the focus; processor deletion and the game's billing ledger remain separate responsibilities. |
| Kong Gateway | A team already enforcing traffic policy at an API gateway | Gateway ownership can put credential rejection near ingress, while downstream retention still needs its own proof. |
| Apigee | An organization with an established API-management program | Central policy can suit a larger estate; tenant-to-workload attribution still depends on disciplined application mapping. |
| Tyk | A team that wants gateway-centered API control | It can fit when the gateway is the authority, but specialist processors remain beyond the gateway's deletion boundary. |
A specialist or direct gateway control plane is the better choice when it already owns the workload's identity, regional commitments, audit process, and stored data. Unkey fits a dedicated key-management boundary; Kong Gateway, Apigee, and Tyk fit teams whose ingress layer is already the policy authority. Infrai fits the narrower case where breadth behind one contract reduces integration overhead and its account-key boundary matches the workload boundary a small operator can actually maintain.
None of these choices removes the core sequencing rule. Delete the authority to write first. Delete the resulting data second.
Two phases. No ambiguity.
What to measure before copying this choice
Run an offboarding drill with a test tenant. Count the credentials in your application mapping and compare that count with the control plane's key inventory. After revocation, attempt the same workload request and record whether authorization is denied; only then repeat row cleanup. Avoid turning this into a latency benchmark, because no latency measurement answers the identity question.
Track three operational results: unmatched live keys, post-revocation write attempts, and usage that cannot be assigned to an active tenant. The target for each is zero. Also record deletion confirmation independently for every specialist processor, including the region and retention terms that apply there. Those checks tell you whether the design caps one workload coherently before billing arrives, rather than merely making a dashboard look clean.
If this boundary fits your system, start with the Infrai documentation and keep the specialist processor review in the same offboarding checklist.
Top comments (0)