Illustrative example: moving a multi-tenant SaaS platform's storefront search off a self-managed engine

Illustrative example. This is a composite scenario written to show how AACSearch can be used. It does not describe a named customer, and the figures are illustrative, not measured results.

The problem

The platform hosts storefronts for a few hundred merchants and had been running one self-managed search engine for all of them. The engine has a single flat namespace, so every collection, synonym set and preset carried a hand-rolled merchant prefix, and one leaked admin key would have exposed every merchant's catalogue. Onboarding a storefront meant a ticket to the search team; one merchant's bulk reindex could slow down everyone else's queries.

The setup

The platform became one AACSearch organisation. On the engine proxy every resource name — collections, aliases, synonym and curation sets, presets, stopwords, analytics rules — is prefixed with the organisation's namespace on the way in and stripped on the way out, and list responses drop other tenants' entries. Isolation from every other AACSearch customer happens in the proxy, not in the platform's code.

Inside the organisation, each storefront is its own collection. The platform's servers hold a full key. Each storefront's browser gets a browser key minted from it through the API: narrowed to the search scope, to that storefront's collection and origins, with its own per-minute rate budget, expiring by itself within at most seven days. Revoking the parent key invalidates every browser key derived from it. Where a storefront shares a collection with others, a scoped key carries a forced filter_by fragment that is ANDed into every search — row-level isolation the client cannot remove.

Usage is metered by a per-organisation quota object: one instance per organisation serialises the monthly request quota, the per-key sliding-minute windows and the credit wallet, so every edge location sees the same counters and a key that exceeds its budget gets a Retry-After instead of degrading its neighbours.

The platform embedded the AACSearch admin console (the Console component from the UI package) in its own back-office, bridged to its existing operator session, so support staff manage collections, synonyms and curation for a merchant without touching the engine.

Onboarding a storefront is now three calls from the platform's provisioning job — createCollection, importDocuments, createBrowserKey — with no ticket in the loop.

What could change (illustrative figures)

• Storefront onboarding: 2 days → 20 minutes (illustrative), the time the provisioning job takes to create the collection, run the first import and hand the storefront its browser key.
• Search-ops engineering hours: −70% (illustrative). Namespacing, key scoping and rate limiting moved from the platform's middleware into the proxy and the key itself.
• Noisy-neighbour incidents: −62% (illustrative), as per-key rate budgets stop one storefront's traffic spike or reindex from consuming the organisation's shared capacity.

Why it matters

The isolation the platform used to enforce by convention — a naming prefix and a promise not to ship the admin key — became a property of the key in the browser: it can only reach one collection, from one origin, for a bounded time. That is what let the search team stop being a gatekeeper for every new merchant.