Aurora Composable was not designed on a whiteboard. It was extracted from a live consumer social product and the backend ecosystem behind it — two native mobile clients, a cloud backbone of single-purpose functions, an administrative companion application, and the key collections that drive all of them.
What follows describes that system in generic terms, as a reference implementation rather than a product pitch.
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, 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.
The reference platform carries subscription tiers, metered features, direct and broadcast messaging, contextual in-app help, device notifications, purchasing and a full administrative back office — with no third-party framework in either client and none in the backbone.
Everything that distinguishes one tier from another, one region from another, or one experiment from another is a key. That is the claim the platform exists to evidence.
Indicative figures from the reference implementation, offered as a sense of scale rather than a benchmark.
| 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 |