Website
Conceptual walkthrough of the end-to-end model.
In this section: Learning Path
- UMA Learning Path
- The Book. Pre-order
- End-to-End UMA Example: Feature Flag Service
- Ch.1: Introduction to UMA
- Ch.2: Device Independence
- Ch.3: What Is UMA?
- Ch.4: From SOA to Metadata
- Ch.5: Building UMA Services
- Ch.6: The UMA Runtime Layer
- Ch.7: WebAssembly and WASM Runtimes
- Ch.8: Contracts and Orchestration
- Ch.9: From Services to Systems
- Ch.10: Security and Trust in UMA
- Ch.11: UMA Patterns and Tradeoffs
- Ch.12: Evolving UMA Systems
- Ch.13: Agents, MCP, and Reasoning
- Ch.14: The Reference Experience
End-to-end UMA example: feature flag service
A feature flag service is a useful end-to-end UMA example because the business behavior is small, testable, and easy to duplicate badly. The same decision often appears in frontend checks, backend authority, edge routing, and workflow logic. UMA turns that repeated rule into one governed capability.
1. Requirement
The product needs to decide whether a feature is enabled for a user. The decision may depend on country, account, rollout percentage, or a fallback rule. The important part is that every runtime should agree on the same outcome.
2. Capability
The capability is feature flag evaluation. It is narrow enough to test and important enough to keep coherent. That makes it a good first Universal Microservice candidate.
3. Contract
The contract defines the input context, flag rules, and decision output. A reader should be able to inspect the contract without needing to understand a specific UI framework or cloud provider.
The contract is where the service becomes understandable before it becomes deployable.
4. Build
The portable core implements deterministic evaluation. In the repository, the Rust-first path is the authoritative implementation, with TypeScript parity where present to make comparison visible.
5. Browser execution
A browser can use the capability when low-latency local decisions are appropriate. The runtime still has to decide which data is safe and which decisions require backend authority.
6. Cloud execution
Cloud execution can provide authority, auditability, and integration with backend systems. UMA does not force the choice. It makes the runtime decision explicit.
7. AI-assisted execution
An AI-assisted flow may propose a flag change, request an evaluation, or summarize rollout behavior. The runtime remains authoritative over validation and execution. The agent participates, but it does not become the system of record.
GitHub
Runnable examples and validation scripts.
Book
Methodology, tradeoffs, governance, and production guidance.
Runtime
The authority that decides where execution belongs.
This walkthrough tells the complete story at a high level. The Chapter 4 example lets you run the evaluator, and the book connects the same pattern to contracts, runtime governance, and later production concerns.