Aurora Composable comes out of a live consumer product and the backend ecosystem behind it — two native mobile clients, a cloud backbone of single-purpose functions, an administrative companion, and the key collections that drive all of them. What follows describes that system generically.
Everything separating one tier from another is a key. That is the claim this platform exists to evidence.
An iOS client and an Android client, each written entirely in its platform's first-party UI toolkit with no third-party dependencies at all. They map one to one at the file level and behave identically, because their behaviour comes from the same key collections rather than from either codebase.
Roughly a hundred small cloud functions, each owning one operation against one data shape, reached over signed endpoints. No application server, no framework runtime, and no shared library that every function must be redeployed to update.
A managed key-value store with partition and sort keys chosen from the access patterns. Configuration, identity, content and telemetry all live in the same primitive, which keeps the number of storage technologies the team must understand at one.
Short-lived credentials issued per identity, with every client call signed. Authorisation is enforced by the cloud platform itself, so there is no bespoke auth layer to audit and no session framework to keep patched.
A separate internal application for authoring key collections, managing identities and reading the transaction log. Its own surface is scoped by privilegekeys, and its vocabulary is built from a registry rather than hard-coded — so extending the system is a data edit, not a rebuild.
Clients fetch the merged key collections on a short interval and cache them locally. This single mechanism is what turns configuration into operation: one write, and the entire installed base is running the new behaviour within a cycle.
Offered as a sense of scale from the reference implementation.
| Third-party dependencies in the iOS client | none |
| Third-party dependencies in the Android client | first-party UI toolkit only |
| Application servers | none |
| Backbone functions | ~100, single-purpose |
| Standard key collections | 5, plus bespoke |
| Time for a configuration change to reach every client | one refresh cycle |
| Releases required for a tier or limit change | none |
Subscription tiers, metered features, messaging, contextual help, notifications, purchasing and a full back office — with no third-party framework anywhere in it.